Cassandra是一個高可靠的大規模分散式儲存系統。高度可伸縮的、一致的、分散式的結構化key-value儲存方案，集Google BigTable的資料模型與Amazon Dynamo的完全分散式的架構於一身。Cassandra使用了Google BigTable的資料模型，與面向行的傳統的關係型資料庫不同，這是一種面向列的資料庫，列被組織成為列族（Column Family），在資料庫中增加一列非常方便。Cassandra的系統架構與Dynamo一脈相承，是基於O(1)DHT（分散式雜湊表）的完全P2P架構，與傳統的基於Sharding的資料庫叢集相比，Cassandra可以無縫地加入或刪除節點，非常適於對於節點規模變化比較快的應用場景。

Cassandra的資料會寫入多個節點，來保證資料的可靠性，在一致性、可用性和網路分割槽耐受能力（CAP）的折衷問題上，Cassandra比較靈活，使用者在讀取時可以指定要求所有副本一致（高一致性）、讀到一個副本即可（高可用性）或是通過選舉來確認多數副本一致即可（折衷）。這樣，Cassandra可以適用於有節點、網路失效，以及多資料中心的場景。Cassandra是一套開源分散式NoSQL資料庫系統，設計思想採用了google的BigTable的資料模型和Amazon的Dynamo的完全分散式架構，因而它具有很好的擴充套件性且不存在單點故障。

Hadoop HBase
Hadoop HBase是Apache Hadoop專案的一個子專案，是Google BigTable的一個克隆，與Cassandra一樣，它們都使用了BigTable的列族式的資料模型，兩者的主要不同在於：
(1) Cassandra只有一種節點，而HBase有多種不同角色，又架構在Hadoop底層平臺之上，部署上Cassandra更簡單；
(2) Cassandra的資料一致性策略是可配置的；
(3) HBase提供了Cassandra沒有的行鎖機制，Cassandra要想使用鎖需要配合其他系統，如Hadoop Zookeeper；
(4) HBase提供更好的MapReduce平行計算支援，Cassandra在0.6版本也提供了這個功能；
(5) Cassandra的讀寫效能和可擴充套件性更好，但不擅長區間掃描。

NoSQL資料庫是為高擴充套件性系統設計的，採用了key/value模型，但它的缺點，正如NoSQL這個名字表明地那樣，不支援SQL操作。這聽起來像是一個很嚴重的缺陷。下面介紹一些在SQL中常見的操作怎樣在cassandra中自然而又有效的實現。

0.示例column family

表1：

CREATE TABLE example (
    id int,
    name ascii,
    age bigint,
    gender bigint,
    high varint,
    PRIMARY KEY (id, name, age)
) WITH CLUSTERING ORDER
 
 BY (name ASC, age ASC)
    AND bloom_filter_fp_chance = 0.1
    AND caching = '{"keys":"ALL", "rows_per_partition":"NONE"}'
    AND comment = ''
    AND compaction = {'class': 'org.apache.cassandra.db.compaction.LeveledCompactionStrategy'}
    AND compression = {'sstable_compression': 'org.apache.cassandra.io.compress.LZ4Compressor'}
    AND dclocal_read_repair_chance = 0.1
    AND default_time_to_live = 86400
    AND gc_grace_seconds = 86400
    AND max_index_interval = 2048
    AND memtable_flush_period_in_ms = 0
    AND min_index_interval = 128
    AND read_repair_chance = 0.0
    AND speculative_retry = '99.0PERCENTILE';

表1內容：

 id | name | age | gender | high
----+------+-----+--------+------
  5 |   ee |  25 |      1 |  168
  1 |   aa |  10 |      1 |  165
  2 |   bb |  20 |      0 |  170
  4 |   dd |  40 |      0 |  190
  6 |   ff |  30 |      0 |  168
  3 |   cc |  30 |      1 |  180

表2：

CREATE TABLE test (
    id int,
    name ascii,
    age bigint,
    gender bigint,
    high varint,
    PRIMARY KEY ((id, name), age)
) WITH CLUSTERING ORDER BY (age ASC)
    AND bloom_filter_fp_chance = 0.1
    AND caching = '{"keys":"ALL", "rows_per_partition":"NONE"}'
    AND comment = ''
    AND compaction = {'class': 'org.apache.cassandra.db.compaction.LeveledCompactionStrategy'}
    AND compression = {'sstable_compression': 'org.apache.cassandra.io.compress.LZ4Compressor'}
    AND dclocal_read_repair_chance = 0.1
    AND default_time_to_live = 86400
    AND gc_grace_seconds = 86400
    AND max_index_interval = 2048
    AND memtable_flush_period_in_ms = 0
    AND min_index_interval = 128
    AND read_repair_chance = 0.0
    AND speculative_retry = '99.0PERCENTILE';

表2內容：

 id | name | age | gender | high
----+------+-----+--------+------
  1 |   aa |  10 |      1 |  165
  6 |   ff |  30 |      0 |  168
  4 |   dd |  40 |      0 |  190
  3 |   cc |  30 |      1 |  180
  5 |   ee |  25 |      1 |  168
  2 |   bb |  20 |      0 |  170

1.查詢

在example表，id是分割槽主鍵，(name, age)是排序主鍵
在test表，(id, name)是分割槽主鍵，age是排序主鍵
在example表，查詢可以如下

select * from example where id = 1;
select * from example where id = 1 and name = ''aa";
select * from example name = ''aa" allow filtering;
select * from example name > ''aa" allow filtering;
select * from example age = 30 allow filtering; ----X
select * from test where id = 3;  ---X
select * from test where age > 20 allow filtering;  

如果使用分割槽主鍵查詢的話，需要指定全部的分割槽主鍵，不能使用部分分割槽主鍵查詢。
對於排序主鍵，可以使用>,<,>=,<=來查詢，如果前面有分割槽主鍵，可以直接用。如果只使用排序主鍵來查詢的話，只能使用排序主鍵的第一個來查詢，並且使用allow filtering;或者使用排序主鍵的第一個、第二個一起來查詢，就是說要排序主鍵要有第一個才能使用第二個，有第二個才能使用第三個。但是這樣會全表掃描，嚴重影響效能。

2.建立二級索引

如果我們想直接查example表的age和test表的name了麼？
方法是有的，那就是建索引：

CREATE INDEX ON example(age);
CREATE INDEX ON test(name);

我們就能在desc example和desc test的時候看到下面的語句了：

desc example:
CREATE INDEX example_age_idx ON ad.example (age);
desc test:
CREATE INDEX test_name_idx ON ad.test (name);

但是建的二級索引只能支援=查詢，不支援範圍查詢。

3.分頁查詢

1，2.x的api裡面有支援分頁查詢。
2，手動分頁查詢可以使用token,下面的例子使用預設排序。

cqlsh:> select * from example limit 2;

 id | name | age | gender | high
----+------+-----+--------+------
  5 |   ee |  25 |      1 |  168
  1 |   aa |  10 |      1 |  165

(2 rows)
cqlsh:> select * from example where token(id) > token(1) limit 2;

 id | name | age | gender | high
----+------+-----+--------+------
  2 |   bb |  20 |      0 |  170
  4 |   dd |  40 |      0 |  190

(2 rows)
cqlsh:> select * from example where token(id) > token(4) limit 2;

 id | name | age | gender | high
----+------+-----+--------+------
  6 |   ff |  30 |      0 |  168
  3 |   cc |  30 |      1 |  180

4.複雜Select

從現在起考慮一個基本的例子：存在一對多關係的department和employee。我們需要兩個Column Family（簡稱“CF”）：Emps和Deps。在Emps中，employee ID作為key，employee的name，birthday和city作為column；在Deps中，department ID作為key，department name作為column。

如果查詢：select * from Emps where Birthdate = ’25/04/1975′為了支援該查詢，我們需要新增一個Birthdate_Emps的CF，其中date為key， name為出生在該天的employee的ID，value可以是一個空的byte陣列（用“-”代替）。每當從/向 Emps中插入 /刪除employee資訊時，我們需要同時更新Birthdate_Emps。為了執行該查詢，我們只需從Birthdate_Emps中檢索出key ’25/04/1975′對應的所有column。

注意，Birthdate_Emps實際上是一個幫助我們快速執行查詢的索引，且這個索引有很強的可擴充套件性，因為它是分佈到各個cassandra節點上的。你可以通過在Birthdate_Emps中新增employee冗餘資訊的方法進一步加速查詢速度，這時，employee的ID變成了super column的名字，employee的所有column變成了該super column的column。

5.Join

查詢：select * from Emps e, Deps d where e.dep_id = d.dep_id
Join實際上是要建立不同實體之間的聯絡。這種聯絡可以很容易地通過迭代表示出來。為了實現該查詢，可以新增一個叫Dep_Emps的CF，其中department ID作為key，與之對應的employee的ID為name。

6.Group By

例如查詢：select count(*) from Emps group by City
從實現角度看，Group By類似於上面描述的select/indexing，你只需要新增一個叫City_Emps的CF，其中，city作為key，employee的ID作為column name。當執行查詢的時候，你只需計算需檢索的city對應的employee數目或者專門新增一個column記錄該數目。

7.Order By

為了支援4-7的這些操作，我們針對查詢儲存了冗餘資料，這樣做意味著：
（1） 必須事先知道系統中需要哪些query（不支援即時查詢）。幸運的是，典型的web應用和企業OLTP應用的查詢均是事先知道的，且數目不多，不經常改動，具體可閱讀這篇論文：The End of an Architectural Era
（2） 我們將壓力從查詢轉移到更新，這是為了支援物化檢視（提前計算出查詢結果）。這樣做，對於Cassandra是非常有意義的，因為Cassandra的更新操作是經過優化的（多虧了最終一致性和從google的BigTable借鑑的“log-structured”儲存理念），並且相比於pull-on-demand模型，cassandra的使用場景更適合push-on-change 模型。關於pull-on-demand和push-on-change模型，可參考文章Why are Facebook, Digg, and Twitter so hard to scale?

參考文章