Cassandra cql 選擇查詢總是拋出讀取超時異常

Question

當我嘗試執行以下查詢時，我總是收到 QueryTimeOutException，

Exception is,
    com.datastax.driver.core.exceptions.ReadTimeoutException: Cassandra timeout during read query at consistency QUORUM (2 responses were required but only 0 replica responded)

Query is,
    SELECT * FROM my_test.my_table WHERE key_1 = 101 ORDER BY key_2 ASC LIMIT 25;

我正在使用帶有 3 個節點的 cassandra 版本 2.1.0，復制為 3 的單個 DC，cassandra.yaml 具有所有默認值，並且我將以下鍵空間和表作為模式，

CREATE KEYSPACE my_test
  WITH REPLICATION = { 
    'class' : 'SimpleStrategy', 
    'replication_factor' : 3
};

CREATE TABLE my_test.my_table (
    key_1 bigint,
    key_2 bigint,
    key_3 text,
    key_4 text,
    key_5 text,
    key_6 text,
    key_7 text,
    key_8 text,
    key_9 text,
    key_10 text,
    key_11 timestamp,
    PRIMARY KEY (key_1, key_2)
);

目前該表有大約 39000 條記錄，但最初它有 50000 條記錄，由於某些業務邏輯已刪除 11000 條記錄。

to avoid such exception is to increase query read time out的解決方案之一to avoid such exception is to increase query read time out ，但我的架構和查詢more direct why should I increase my read time out ？ 由於在我的查詢中我已經給出了分區鍵（key_1），所以它應該准確地到達目的地，之后我指定了分區鍵的開始范圍，所以它應該以 2 秒的最長時間檢索，但事實並非如此。 但下面的查詢工作正常，檢索結果不到 1 秒（ Difference is, ASC is not working and DESC is working ）

SELECT * FROM my_test.my_table WHERE key_1 = 101 ORDER BY key_2 DESC LIMIT 25;

再次根據架構，集群鍵默認順序是 ASC，因此根據 cassandra 文檔，在 ASC 中檢索數據應該比 DESC 順序更快。 但在我的情況下是相反的。

---

又是一些線索，以下是通過CQLSH嘗試過的查詢。

以下查詢正在運行並在不到 1 秒的時間內檢索到結果

SELECT * FROM my_test.my_table WHERE key_1 = 101 AND key_2 > 1 AND key_2 < 132645 LIMIT 1;

但是，以下查詢不起作用並拋出超時異常，

SELECT * FROM my_test.my_table WHERE key_1 = 101 AND key_2 > 1 AND key_2 < 132646 LIMIT 1;

但是，以下查詢正在運行，並且檢索結果不到 1 秒

SELECT * FROM my_test.my_table WHERE key_1 = 101 AND key_2 = 132644;
SELECT * FROM my_test.my_table WHERE key_1 = 101 AND key_2 = 132645;
SELECT * FROM my_test.my_table WHERE key_1 = 101 AND key_2 = 132646;
SELECT * FROM my_test.my_table WHERE key_1 = 101 AND key_2 = 132647;

任何幫助的奇怪行為將不勝感激。

Answer 1

對於每個 key_1，大約有 1000000 個 key_2。

這就是當您將每個分區限制為 20 億個單元並嘗試使用所有單元時會發生的情況。 我知道我之前在這里回答了很多帖子，承認每個分區有 20 億個單元格的硬限制，您的（非常）寬的行將變得笨拙並且可能在此之前很久就會超時。 這就是我相信你看到的。

這里的解決方案是一種稱為“bucketing”的技術。 基本上，您必須找到一個額外的鍵來分區您的數據。 太多的 CQL 行被寫入同一個數據分區，分桶將有助於將分區與集群鍵的比率恢復到一個合理的水平。

進行分桶的邏輯方法是使用時間元素。 我看到你的最后一個鍵是一個時間戳。 我不知道每個key_1一天有多少行，但假設你每個月只有幾千行。 在這種情況下，我會創建一個額外的分區鍵month_bucket ：

CREATE TABLE my_test.my_table (
    key_1 bigint,
    key_2 bigint,
    ...
    key_11 timestamp,
    month_bucket text,
    PRIMARY KEY ((key_1,month_bucket) key_2)
);

這將允許您支持這樣的查詢：

SELECT * FROM my_test.my_table 
WHERE key_1 = 101 AND month_bucket = '201603'
  AND key_2 > 1 AND key_2 < 132646 LIMIT 1;

同樣，按月分桶只是一個例子。 但基本上，您需要找到一個額外的列來對您的數據進行分區。

Answer 2

after restarting all the 3 cassandra servers問題得到解決。 我不知道到底是什么惹了麻煩.. 因為它是在生產服務器無法得到確切的根本原因。