Cassandra 數據模型 （基於CQL,解決胖列數量限制及靈活性問題）（1.1及以上版本）

文中主要交代Cassandra的編程模型及數據結構。

因爲Cassandra版本數次更新，網上中文的資料已經有點過期，比較有表明性的好比ebuy那篇文章都已通過時了，因而本身找資料，結合官方博客寫一篇Cassandra模型的文章。

一些名詞的介紹：因爲技術名詞衝突，BigTable裏的表對應的是Cassandra裏的列族，而BigTable裏面列族的概念更相似Cassandra早期實現裏的超級列（該功能在Cassandra裏已被關閉）。

Cassandra介紹

首先介紹一下Cassandra。

Cassandra是Apache的開源項目，是NoSQL的一種，普遍意義上的列族數據庫，分佈式，無中心機。其早期實現主要參考了Google的Big Table論文及亞馬遜的Dynamo論文中的介紹，能夠參考兩篇論文來得到Cassandra的設計思想，關於更詳細的資料，能夠參見wiki及官方文檔。

早期實現及最佳實踐

前文提到早期實現，那麼如今固然與早期區別已經極大了，從數據模型設計到實際使用，基本上已經自成體系了。其中之一最大的改變，就是1.1版本里對數據庫操做的改變。

Cassandra的早期實現裏，使用的徹底是BigTable的數據模型，即列及列族及主鍵等概念。在ebuy的最佳實踐的文中，對該模型的使用作了詳細解釋，我無心在此引用他人文章，只是簡單說一下概念。

最佳實踐文章總共分兩部分，上部分主要說的是列族數據庫中該如何設計數據模型，其中主要討論的是對關係及部分相關數據的重複儲存來減小對數據庫的分佈式讀取，其中對列族數據庫數據結構的有個挺有意思的式子，以下：

Map<RowKey, SortedMap<ColumnKey, ColumnValue>>

下部分交代的則是Cassandra中的具體實現方式，好比當時Cassandra實現了一個與BigTable列族相似的東西，或者說只是名字不一樣的東西，就是超級列，把相似的列聚 合在一塊兒提取。

再好比說推薦使用胖列（使用列鍵查詢）而不是瘦列（使用主鍵查詢）。胖列指的是以大量的列儲存關係，好比用戶表users有三列user_k,p1,p2，第一列user_k是主鍵，第二列p1是用戶購買的產品1，第三列p2是用戶購買的產品2，pn能夠擴展到極大的數量.

注：上文只是簡單解釋，實際全文中對各類應用場景的討論不只限於該範圍。

磁盤儲存方式

Cassandra使用的方式是：把一級主鍵當作分區主鍵，列名做爲列鍵儲存。光說不清楚，上圖：（圖片來自Cassandra 1.1）

CREATE TABLE timeline ( user_id varchar, tweet_id uuid, author varchar, body varchar, PRIMARY KEY (user_id, tweet_id) );

上圖是傳統數據庫的儲存方式。

上圖是Cassandra的儲存方式，注意{1787，author}是列鍵名而不僅是數據。

如今的實現

隨着Cassandra的成長，原先徹底按照BigTable實現的數據模型開始產生一些問題，其中之一就是沒法無限擴大的列的數量，雖然已經設計了一個足夠大的列數量，但對於大數據分佈式數據庫，仍然是不夠用的，並且超級列的方式靈活性受限制，因而開發者開始走本身的道路，因而隨着CQL（Cassandra本身的相似SQL的操做語言）的發佈及發展，首先清除了超級列（BigTable裏的列族）的概念：在CQL中，沒有超級列的概念，在列上一級就是表，也就是原先概念上的超級列是不存在的，那針對原先的胖列的應用場景，該如何處理呢？

CQL中有主鍵及二級主鍵的概念，主鍵就是原先的主鍵，這個概念沒有變化，而對於原先的超級列聚合，CQL經過 把二級主鍵的值加上列名做爲列鍵名解決了這個問題。

也就是說，把原先由數據字典（請容許我使用這個關係數據庫詞彙）儲存的數據儲存到了數據表中，減輕了對數據字典的訪問及數據字典數據結構的維持開銷，把壓力下發到數據表。

參考：

Schema in Cassandra 1.1

Cassandra Wiki

Cassandra Data Modeling Best Practices, Part 1

Cassandra Data Modeling Best Practices, Part 2