cassandra查詢效率探討

cassandra查詢效率探討

cassandra目前提倡的建表與查詢方式爲CQL方式，傳統的cassandra-cli相關的api因爲性能問題將逐步淘汰，而cassandra-cli也將在2.2版本以後被淘汰。

在CQL中，能夠利用相似SQL的方式創建數據表，例如：

CREATE TABLE monitor (
    id bigint,
    value text,
    num int,
    timestamp timestamp,
    PRIMARY KEY (id, timestamp ));

其中id與timestamp共同構成了primary key。primary key能夠不止一個字段，大於一個字段的能夠構成clustering key。其中在primary key中第一個字段爲partition key，用來決定row在整個ring中的分佈。後面的字段爲clustering key，對於同一個partition key所表明的行，是根據clustering key以必定順序在物理上相鄰存儲的。因此根據partition key以及clustering key進行聯合查詢速度會比較快。cassandra對於以下查詢效率比較高

select * from monitor WHERE id = 1;
select * from monitor WHERE id = 2 AND timestamp = '2015-12-01 12:00:00+0800';
select * from monitor WHERE id = 2 AND timestamp > '2015-12-01 12:00:00+0800' AND timestamp < '2015-12-01 23:00:00+0800';

可是對於下面的查詢，cassandra會返回InvalidRequest: code=2200 [Invalid query] message="Cannot execute this query as it might involve data filtering and thus may have unpredictable performance. If you want to execute this query despite the performance unpredictability, use ALLOW FILTERING"

select * from monitor WHERE timestamp = '2015-12-01 12:00:00+0800';

其緣由爲是cassandra認爲這查詢效率比較低下，須要用戶顯式地增長ALLOW FILTERING修飾。這種查詢過程是先獲取全部行，而後在根據timestamp = '2015-12-01 12:00:00+0800'進行過濾，效率天然比較低。

解決的辦法一般有在timestamp字段上創建因此。但不能簡單地將cassandra創建索引的機制與普通的關係型數據庫如mysql劃等號。經過primary key查詢，能夠經過ring的信息很快的定位到具體的節點。可是經過index查詢字段的話，cassandra會每一個節點進行查詢。雖然節點內部也會對本地數據進行索引，可是效率仍是遠不如直接查詢primary key快。此外cassandra並不可以對於timestamp >'2015-12-01 12:00:00+0800'這種範圍條件進行查詢。因此更好的方式是另外創建一個表，將須要查詢的字段做爲主鍵，並存儲對應關係。

參考資料

1. ALLOW FILTERING explained

2. A deep look at the CQL WHERE clause

3. When to use an index