即使在10秒超時後查詢擁有超過10,000行的密鑰時，Cassandra也會超時

Question

使用具有預安裝默認設置的DataStax Community 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）。 即使在此特定表上一致性設置爲1，我仍然面臨超時問題。

1. 我堆空間增加到3GB [8GB的RAM大小]
   
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]

您正在運行到一個問題，即墓碑（刪除值）的數量是通過閾值，然後超時。

你可以看到這一點，如果你開啓跟蹤，然後嘗試你的SELECT語句，例如：

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天更頻繁，但根據您的應用程序可能會或不適合。閱讀刪除的含義，您可以根據需要調整您的應用程序。