Cassandra 中的查詢性能改進

我的 Cassandra 數據庫中有一張桌子。

CREATE TABLE table (
   pk uuid,
   status int,
   location text,
   type text,
   id  text,
updatedtimestamp timestamp, 
       PRIMARY KEY (pk)
);

CREATE INDEX  tablelocation ON table (location);
CREATE INDEX  tabletype ON table (type);
CREATE INDEX  tableid ON table (id);
CREATE INDEX  tableupdatedtimestamp ON table (updatedtimestamp);

我執行的查詢是：

Select * from table 
where location='A1' 
and type='T1' 
and status=001 
and id='NA' 
allow filtering;

Cassandra 需要超過 5 秒的時間來為該查詢返回 4000 條記錄。我已經在所有這些列上都有二級索引。根據 DBA，問題是id='NA'有條件的。此條件為真的行太多。

但是，這種情況是由於業務案例而存在的，如果沒有其他機制來過濾該值，就無法刪除該條件。

我正在考慮創建一個包含所有 4 列的新索引。但是，我擔心它會妨礙寫入性能。狀態欄會非常頻繁地更新。

我們可以做些什麼來調整這個查詢的性能嗎？

使用 Cassandra 進行索引永遠不會高效，因為它不是設計的。Cassandra 的 4000 行並不是什麼大問題。但是查詢集群中所有節點的 4000 行，現在您已將網路時間添加到等式中。

如果您希望執行此操作，您需要做的是建構一個表來支持此查詢。具體來說，這意味著設計一個主鍵結構，以便查詢可以由單個節點提供服務。

根據位置和類型的基數，您可以嘗試以下操作：

CREATE TABLE table_by_location_type (
   pk uuid,
   status int,
   location text,
   type text,
   id  text,
   updatedtimestamp timestamp, 
   PRIMARY KEY ((location,type),id,pk)
);

CREATE INDEX  tablestatus ON table_by_location_type (status);

location這將按和對您的數據進行分區type，確保該列組合上的數據將儲存在一起。接下來，這會將您的數據（在每個分區內id）分群，並pk在末尾添加 以確保唯一性。只要與and一起使用，索引就status可以了***。***location``type

專業提示：

• 建構您的表格以適應您的查詢。不是反過來。
• 如果您需要支持多種查詢模式，請建構第二個表並將數據複製到其中。
• 二級索引是為了方便而不是性能而設計的。避免使用它們，除非您提供完整的分區鍵。
• 永遠不要在生產中使用該ALLOW FILTERING指令。

引用自：https://dba.stackexchange.com/questions/302462