Cassandra數據模型

提起NoSQL這個話題，彷彿不該該是DBA要關注的事，而是架構師應該關心的。可是做爲一名DBA，在使用傳統的關係型思想建模時，應該有必要了解NoSQL的建模方法。

各類NoSQL數據庫有不少，我最關注的仍是BigTable類型，由於它是一個高可用可擴展的分佈式計算平臺，用來處理海量的結構化數據，而數據庫一樣也是處理結構化數據，因此除了沒有SQL，在數據模型方面有類似之處。Cassandra是facebook開源出來的一個版本，能夠認爲是BigTable的一個開源版本，目前twitter和digg.com在使用。咱們嘗試從DBA的角度出發去理解Cassandra的數據模型。

NoSQL並不能簡單的理解爲No SQL，其本質應該是No Relational， 也就是說它不是基於關係型的理論基礎，而咱們全部傳統的數據庫都是基於這套理論而發展起來的，因此SQL並非問題的關鍵所在，好比有些NoSQL數據庫 能夠提供SQL類型的接口，容許你經過類SQL的語法去訪問數據。而Friendfeed則是反其道而行之，利用關係型數據庫MySQL，採用了去關係化 的設計方法，去實現本身的KeyValue存儲。因此NoSQL的本質是No Relational.

Cassandra特色：

1.靈活的schema，不須要象數據庫同樣預先設計schema，增長或者刪除字段很是方便（on the fly）。

2.支持range查詢：能夠對Key進行範圍查詢。

3.高可用，可擴展：單點故障不影響集羣服務，可線性擴展。

Keyspace

Cassandra中的最大組織單元，裏面包含了一系列Column family，Keyspace通常是應用程序的名稱。你能夠把它理解爲Oracle裏面的一個schema，包含了一系列的對象。

Column family（CF）

CF是某個特定Key的數據集合，每一個CF物理上被存放在單獨的文件中。從概念上看，CF有點象數據庫中的Table.

Key

數據必須經過Key來訪問，Cassandra容許範圍查詢，例如：start => '10050', :finish => '10070'

Column

在Cassandra中字段是最小的數據單元，column和value構成一個對，好比：name:「jacky」，column是name，value是jacky，每一個column:value後都有一個時間戳：timestamp。

和數據庫不一樣的是，Cassandra的一行中能夠有任意多個column，並且每行的column能夠是不一樣的。從數據庫設計的角度，你能夠理解 爲表上有兩個字段，第一個是Key，第二個是長文本類型，用來存放不少的column。這也是爲何說Cassandra具有很是靈活schema的原 因。

Super column

Super column是一種特殊的column，裏面能夠存聽任意多個普通的column。並且一個CF中一樣能夠有任意多個Super column，一個CF只能定義使用Column或者Super column，不能混用。下面是Super column的一個例子，homeAddress這個Super column有三個字段：分別是street，city和zip：

homeAddress: {street: "binjiang road",city: "hangzhou",zip: "310052",}

Sorting

不一樣於數據庫能夠經過Order by定義排序規則，Cassandra取出的數據順序是老是必定的，數據保存時已經按照定義的規則存放，因此取出來的順序已經肯定了，這是一個巨大的性能優點。有意思的是，Cassandra按照column name而不是column value來進行排序，它 定義瞭如下幾種選項：BytesType, UTF8Type, LexicalUUIDType, TimeUUIDType, AsciiType,  和LongType，用來定義如何按照column name來排序。實際上，就是把column name識別成爲不一樣的類型，以此來達到靈活排序的目的。UTF8Type是把column name轉換爲UTF8編碼來進行排序，LongType轉換成爲64位long型，TimeUUIDType是按照基於時間的UUID來排序。例如：

Column name按照LongType排序：

{name: 3, value: "jacky"},
{name: 123, value: "hellodba"},
{name: 976, value: "Cassandra"},
{name: 832416, value: "bigtable"}

Column name按照UTF8Type排序：

{name: 123, value: "hellodba"},
{name: 3, value: "jacky"},
{name: 832416, value: "bigtable"}
{name: 976, value: "Cassandra"}

下面咱們看twitter的Schema：

咱們看到一個叫Twitter的keyspace，包含若干個CF，其中StatusRelationships和 UserRelationships被定義爲包含Super column的CF，CompareWith定義了column的排序規則，CompareSubcolumnsWith定義了subcolumn的排序 規則，這裏使用了兩種：TimeUUIDType和UTF8Type。咱們沒有看到任何有關column的定義，這意味着column是能夠靈活變動的。

爲了方便你們理解，我會嘗試着用關係型數據庫的建模方法去描述Twitter的Schema，但千萬不要誤解爲這就是Cassandra的數據模型，對於Cassandra來講，每一行的colunn均可以是任意的，而不是象數據庫同樣須要在建表時就建立好。

Users CF記錄用戶的信息，Statuses CF記錄tweets的內容，StatusRelationships CF記錄用戶看到的tweets，UserRelationships CF記錄用戶看到的followers。咱們注意到排序方式是TimeUUIDType，這個類型是按照時間進行排序的UUID字段，column name是用UUID函數產生（這個函數返回了一個UUID，這個UUID反映了當前的時間，能夠根據這個UUID來排序，有點相似於timestamp 同樣），因此獲得結果是按照時間來排序的。使用過twitter的人都知道，你老是能夠看到本身最新的tweets或者最新的friends.

存儲

Cassandra是基於列存儲的(Bigtable也是同樣)，這個和基於列的數據庫是一個道理。

API

下面是數據庫，Bigtable和Cassandra API的對比：

Relational			SELECT `column` FROM `database`.`table` WHERE `id` = key;
BigTable			table.get(key, "column_family:column")
Cassandra: standard model	keyspace.get("column_family", key, "column")
Cassandra: super column model	keyspace.get("column_family", key, "super_column", "column")

我對Cassandra數據模型的理解：

1.column name存放真正的值，而value是空。由於Cassandra是按照column name排序，並且是按列存儲的，因此每每利用column name存放真正的值，而value部分則是空。例如：「jacky」:「null」，「fenng」:」null」

2.Super column能夠看做是一個索引，有點象關係型數據庫中的外鍵，利用super column能夠實現快速定位，由於它能夠返回一堆column，並且是排好序的。

3.排序在定義時就肯定了，取出的數據確定是按照肯定的順序排列的，這是一個巨大的性能優點。

4. 很是靈活的schema，column能夠靈活定義。實際上，colume name在不少狀況下，就是value（是否是有點繞）。

5.每一個column後面的timestamp，我並無找到明確的說明，我猜想多是數據多版本，或者是底層清理數據時須要的信息。

最後說說架構，我認爲架構的核心就是有所取捨，不論是CAP仍是BASE，講的都是這個原則。架構之美在於沒有任何一種架構能夠完美的解決各類問題，數據庫和NoSQL都有其應用場景，咱們要作的就是爲本身找到合適的架構。

–EOF–

這篇文章，我參考了up and running with cassandra，除此之外，我還參考了twitter提供的API，它幫助我理解twitter的schema設計。這篇文章，確定有不少理解不正確的地方，但願朋友們指正。

做者簡介：Jacky，七十年代生人 愛好：旅行，體育，正在學攝影 性格：一半是海水 一半是火焰 職業：Oracle DBA/Database Architect @ Alibaba 當前流竄地：杭州 Ask Jacky：freezr@gmail.com Twitter：hellodba My google profile：Jacky