目前spark、storm都支援cassandra儲存，cassandra重返nosql舞臺，本文分享一些Cassandra 表設計的通用原則，我們團隊的實戰經驗，希望對大家有用。 

    每個資料庫中有成百上千的表，將其抽象分類起來無非以下幾種：擁有較少資料量的小型表、主要起參考作用的大中型表、管理具體業務行為的大中型表、儲存用的大型表。一般而言Cassandra的寫是優於讀的，因此需要結合表的型別，以及其讀寫方面的要求，合理設計每個CF的屬性，將每個CF的設計達到最優。表型別可以按照下圖分類：

      

1. 較少資料量的小型表

    此類表一般都是編碼表，比如列舉型別表，狀態資訊表等。一般情況只有幾行，幾十行，最多幾千行資料。他們的體積都非常的小，列都不多，一次IO基本都將全部的資料讀取完畢，裡面的資料也基本是靜止的，平時基本保持不變。但是此類表引用的非常的頻繁，幾乎每個查詢都要使用，對於此類表一般而言可以考慮將其設計caching屬性設計為：

    

1)    rows_only，即將全表放到記憶體中；

2)    如果該表的update

資料比較多，將gc_grace_seconds調小，建議值（1800-3600）。

   

2.起參考作用的大中型表

此類表一般都是主題資訊方面的表，比如員工表，供應商表，商品表等。一般情況存有幾千，幾萬，最多幾百萬的資料。他們的體積偏小，一般幾M，幾十M，最多幾百M，裡面的資料會變化，但不是非常頻繁的變，一般是定時變化一次。但是此類表的列一般比較多，因此設計列的順序非常的重要，特別是key內的欄位順序的設計。需要考慮到將key經過hash後值的分佈，將值型別比較多、同時查詢比較多的列作為key較好。需要考慮幾個問題：

1)   

是否需要keycache，即將key放到記憶體中，方便快速查詢；

2)    相同的key值是否過多，出現數據單點問題，如果出現使用複合key設計；

3)    如果該表的update資料比較多，將gc_grace_seconds調小，建議值（1800-3600）；

4)    過期資料使用default_time_to_live設定自動刪除；

5)    寫多的表compaction使用SizeTieredCompactionStrategy；

6)    讀較多的表compaction使用LeveledCompactionStrategy；

7)    自動做compaction，提高讀效率；

3.管理具體業務行為的大中型表

此種表的資料量比較大，讀寫都很頻繁，也是整個資料庫中最複雜，最繁忙的表，比如訂單表。

1)    是否需要keycache，即將key放到記憶體中，方便快速查詢；

2)    相同的key值是否過多，出現數據單點問題，如果出現使用複合key設計；

3)    如果該表的update資料比較多，將gc_grace_seconds調小，建議值（1800-3600）；

4)    過期資料使用default_time_to_live設定自動刪除；

5)    寫多的表compaction使用SizeTieredCompactionStrategy；

6)    讀較多的表compaction使用LeveledCompactionStrategy;

7)    自動做compaction，提高讀效率。

4.儲存用的大型表

   此種類型的表一般都是巨大的，裡面的資料都是幾億，幾十億的，同時對資料的安全性，一致性要求不是很高，比如日誌資訊表。它們的擁有非常頻繁的插入速度，但是實時查詢的比較少，因此此類表的設計就是儘量滿足資料的快速插入。具體到Cassandra中，可以降低CF的一致性策略，此類表上不要建二級索引。
1)    不需要 cache 機制；

2)    相同的key值是否過多，出現數據單點問題，如果出現使用複合key設計；

3)    過期資料使用default_time_to_live設定自動刪除；

4)    寫多的表compaction使用SizeTieredCompactionStrategy

定時做compaction，減少不必要的資料儲存；

5.AB表實現方式

     如果需要truncate  A表資料後立即寫入資料，建議採用AB表的實現方式。及重新建立Ｂ表寫入資料，定時delete Ａ表即可。原因是：Cassandra truncate 表不會立即刪除資料，只會標記每條記錄的刪除時間。會對後期資料讀寫效能造成影響。