Cassandra тайм-аут при запросе ключа, который имеет более 10 000 строк, даже после предоставления таймаута 10 секунд

Question

Im с использованием сообщества DataStax v 2.1.2-1 (AMI v 2.5) с предустановленными настройками по умолчанию. И я есть таблица:

CREATE TABLE notificationstore.note (
    user_id text, 
    real_time timestamp, 
    insert_time timeuuid, 
    read boolean, 
    PRIMARY KEY (user_id, real_time, insert_time)) 
WITH CLUSTERING ORDER BY (real_time DESC, insert_time ASC) 
AND bloom_filter_fp_chance = 0.01 
AND caching = '{"keys":"ALL", "rows_per_partition":"NONE"} 
AND **default_time_to_live** = 20160 

Другие конфигурации являются:

У меня 2 узлов. на m3.large с 1 x 32 (SSD). Я сталкиваюсь с проблемой тайм-аутов, даже если согласованность установлена ​​на ONE в этой конкретной таблице.

1. Я увеличил пространство кучи до 3ГБА [объем оперативной памяти 8gb]
   
2. Я увеличил таймаут чтения до 10 секунд.
   select count (*) from note where user_id = 'xxx' limit 2; // errors={}, last_host=127.0.0.1.

мне интересно, если эта проблема может быть со временем, чтобы жить? или есть какая-либо другая конфигурация, какая-либо настройка, которая имеет значение для этого.

Данные в базе данных довольно маленькие.
Также эта проблема возникает не сразу после вставки. Это происходит через некоторое время (более 6 часов)

Спасибо.

Answer 1

[Копирование моего ответа здесь, потому что это та же среда/проблема:. amazon ec2 - Cassandra Timing out because of TTL expiration]

Вы бежите в проблему, где число надгробий (удаленные значения) проходит порог, а затем таймаут ,

Вы можете увидеть это, если вы включите трассировку и затем попробуйте отборное заявление, например:

cqlsh> tracing on; 
cqlsh> select count(*) from test.simple; 

activity                  | timestamp | source  | source_elapsed 
---------------------------------------------------------------------------------+--------------+--------------+---------------- 
...snip... 
Scanned over 100000 tombstones; query aborted (see tombstone_failure_threshold) | 23:36:59,324 | 172.31.0.85 |   123932 
                Scanned 1 rows and matched 1 | 23:36:59,325 | 172.31.0.85 |   124575 
          Timed out; received 0 of 1 responses for range 2 of 4 | 23:37:09,200 | 172.31.13.33 |  10002216 

Вы вид, впадающей в анти-шаблон для Кассандры, где хранятся данные для всего короткое время перед удалением. Есть несколько вариантов для этого лучше, включая пересмотр вашей модели данных, если это необходимо. Вот некоторые ресурсы:

• The cassandra.yaml configuration file - Смотрите раздел о настройках надгробных
• Cassandra anti-patterns: Queues and queue-like datasets
• About deletes

Для вашей проблемы образца, я попытался понижая gc_grace_seconds установку на 300 (5 минут). Это приводит к тому, что надгробные плиты будут очищаться чаще, чем 10 дней по умолчанию, но это может быть или не быть подходящим на основе вашей заявки. Прочтите о последствиях удалений, и вы можете настроить их по мере необходимости для своего приложения.