Cassandra 資料模型設計總結
結合前段時間使用Cassandra使用過程，團隊簡單總結了Cassandra 資料模型設計，請大家斧正。
1、相關概念
- Column：Cassandra中的最基本的儲存單元，用於儲存某一行的資訊；
- primary key：決定每行資料的唯一性；
- Row key：又稱partition key，也即我們經常說的K-V中的key，是primary key中的第一列或者組合起來的複合列，partition key決定了每行資料在叢集節點間的資料分佈；
- 複合key：又稱compound key，是由多列組成的row-key；
- Column key：column name。
Cassandra的模型結構可以理解為巢狀的map:
Map<RowKey,SortedMap<ColumnKey, ColumnValue>>
等同於下圖：
更具體設計如下圖所示：
3.設計原則（重點，值得大家反思，nosql ！=sql）
1、需要結合業務特點和Cassandra的模型結構，圍繞查詢模式進行ColumnFamily建模設計；
2、在設計表的時候，儘量減免表關聯查詢，按照實體物件，進行必要的反正規化設計；
3、由於Cassandra的巢狀排序map資料結構，在模型設計時應考慮如何組織資料到這種型別的map中，以滿足快速查詢/排序/分組/過濾/聚合的要求；
4、不支援複雜sql的查詢，比如，joins, group by，order by（因為order by是在設計時決策，Cassandra不支援Order By，排序是需要設計時考慮，而不是像在關係型資料庫查詢時刻使用Order By）；
5、選擇合適的rowkey，以實現資料分佈，儘量保證rowkey唯一；
例如：primary key((date, type, hashcode), vendor) --加入hashcode能將資料儘可能的分佈到多個節點中，以避免單點和熱點的壓力；
6、在第五點的基礎上，儘量避免大key小value的出現，這樣會導致很差的效能效果；
7、根據業務特徵，將多讀資料的表和多寫資料的表實現分離；
8、保持column簡短，因為它將和每個column value一起被重複儲存（根據資料副本數）。當column value的大小比column name小很多時，記憶體和儲存的開銷可能會是個問題，除了用column name儲存資料（即value為空時）外；
例如：'fname' 優於 'firstname'，'lname' 優於 'lastname'。
9、設計合適的TTL
需要根據不同表的特徵和column的資料保留策略，設計合適的TTL，以保留適當時間視窗的資料。
最後寫一句話吧：不要把Cassandra當做傳統資料庫！