Cassandra Secondary Index 介紹

摘要

本文主要介紹cassandra中的索引，物化視圖，有些知識點需要對cassandra有基本的認識才能理解。比如資料在cassandra節點中如何分布。如果有不明白的地方可以看本專欄之前文章。或者發送郵件和我探討 cnstonefang@gmail.com。 為什麼叫secondary index

CREATE TABLE user(    id bigint,    name text,    email text,    PRIMARY KEY(id));

在很多文檔中可以看到cassandra index又被稱為secondary index.這是相對primary index的概念。在建立上述user table 時，會根據primary key 預設建立 primary index，基於id 列。可以根據id來查詢使用者的資訊。但是不同於關係型資料庫。你沒法根據email反向查id.為了實現這樣的查詢，可以基於email建立secondary index.

CREATE INDEX email_index ON user(email);

當你建立索引的時候，cassandra 會建立一個隱藏table來儲存資料

CREATE TABLE email_index(   email text,   id  bigint,   PARMARY KEY(text,id));

secondary index 的這張表的資訊是local aware的。和節點的資料存放在一起。而primary index是global.所以當你根據primary index columns 來查詢的時候，cassandra ring 環上的每個節點都是知道資料是儲存在哪些節點上的。但是如果根據secondary index columns 來查詢。cassandra ring 環上的所有節點都是不知道資料放在哪些節點上的。必須要查詢所有的節點。這也是為什麼很多人說cassandra secondary index的效率很低的原因。但是實際上cassandra是不是會這麼去查詢呢，當然不會這麼簡單粗暴。一個1000節點的cluster，如果都去查的話，查詢的coordinator肯定撐不住了。 secondary index 查詢

cassandra 首先要查詢所有節點，對於每個節點，要進行本地查詢。沒有secondary index時，不指定partition key，因為既要掃描所有的partition，每個patition裡面還得全掃描，因此cassandra不允許這樣的操作。建立了對應欄位的secondary index後，如果不指定partition key,必須帶上 ALLOW FILTERING,才能進行查詢，但是不建議在生產環境中使用。

本地查詢：對於每個節點的本地查詢，是比較簡單明了的。根據secondary index columns值查詢隱藏的index table,得到primary key，然後查詢原表。

cluster 查詢：對於所有節點查詢，cassandra 基於partition keys實現了一套複雜的演算法來最佳化範圍掃描查詢。當然這套演算法不止針對於secondary index.適用於所有的範圍掃描。
這套演算法的基本點在於，迴圈查詢。每一輪會根據CONCURRENCY_FACTOR 來決定有多少個節點會被查詢，如果返回的資料不夠。CONCURRENCT_FACTOR +1，直到返回的結果集夠了。

注意cassandra是根據token range 來查詢這些節點的，所以返回的結果集沒有特定的順序。

Notes
儘管cassandra對範圍查詢進行了最佳化，但是不可否認的是基於secondary index查詢的效率還是比較低。最好的實踐是在對secondary index查詢時，能夠帶上primary index 條件。比如partition =xxx,partition in(xx,yy)或者token(partition)>= xxx AND token(partition)<=yyy 使用場合

適用於有很多行都有的某個列(cassandra不要求每一行都必須存所有的列)，並且這列的值範圍比較大。
另一方面，這些列不適合

1.經常更新，刪除的列

cassandra 儲存index 的墓碑有100K cells的限制，超過這個限制，基於index的column查詢就會失敗。
另外index的資料也是存在隱藏表裡面的。如果經常更新刪除這列資料，不僅要寫主表，還要寫隱藏表。

2.取值範圍很低(low-cardinality)比如bool型

對這樣的列做索引，沒什麼意義。index 表中只有兩個partition了。如果主表資料很多的話，就會
每個partition就會很大。

3.取值範圍很高(high-cardinality)比如上面的例子，一個id對應一個email.

如果對email做索引。那麼當我們根據email查詢時，就只有至多一個值了。最理想的情況，當我們
查詢一個節點時，就恰好查到了。最糟糕的情況，得查詢完所有的節點，才能查到。

看了2，3可能有些人很困惑，取值範圍很低不適合index，取值範圍很高也不適合index，有沒有給出一個標準，什麼
樣的叫取值範圍高，什麼樣的叫取值範圍低。讓我怎麼去判斷。其實在cassandra的很多地方都存在這樣的問題，沒有一個
非常嚴謹，準確的定義。需要使用者自己去平衡，根據實際的的表設計，資料分布去做效能分析，得出適合自己應用的表設計。 與物化視圖，新表的區別

為了滿足查詢，cassandra經常需要建立新表，物化視圖，索引來實現特點的查詢。
索引的特點在上面已經提到了。新建立一張表會有資料冗餘，但是在分布式儲存系統中，這是完全可以接受的，相比較視圖新表多了資料維護。但是有些情況視圖和索引都解決不了，比如上面提的low-cardinality 情況，視圖也沒法解決。因為視圖是global的，會造成hot-spot情況，及視圖資料都只存在某些固定的節點。

另外視圖的更新是非同步更新的
對cassandra感興趣的童鞋可以參入群(104822562)一起學習探討
參考

http://www.planetcassandra.org/blog/cassandra-native-secondary-index-deep-dive/

https://docs.datastax.com/en/cql/3.3/cql/cql_using/useWhenIndex.html

http://www.datastax.com/dev/blog/materialized-view-performance-in-cassandra-3-x

https://wiki.apache.org/cassandra/WritePathForUsers