共計 3531 個字符，預計需要花費 9 分鐘才能閱讀完成。
如何進行 Cassandra 模型以及架構的分析，相信很多沒有經驗的人對此束手無策，為此本文總結了問題出現的原因和解決方法，通過這篇文章希望你能解決這個問題。
NoSql 的世界紛繁復雜，出去掉 Redis 等內存型的數據庫之外，在整個 NoSQl 領域比較認可的是 Cassandra，Hbase，以及 MongoDB。
對于 Mongo，目前本 ID 的系列博文已經有部分，而 Hbase 有關的部分還未補充，待補。
高可靠性 協議
1：Cassandra 采用了 gossip 作為集群中節點的通信協議，該協議整個節點都處于同等的地位，沒有主從
之分，這就使得任一節點的推出都不會導致整個集群的失效。
2:Cassandra 和 Hbase 在底層的架構設計都是借鑒了 Google Big Table 的思想來構建自己的系統，而
Cassandra 的創新就是將原本用在文件共享架構的 P2P（Peer to Peer）引入到了 NoSql
P2P 的一大特點就是去中心化，集群之中的所有節點都有著同等的地位，這極大的避免了單個節點退出，
而使整個集群不能工作的可能，與之形成對比的是 Hbase 采用了 Master/Slave 的方式，這就存在了單點失效的可能。
1.2：高擴展性
隨著時間的推移，集群中原有的規模不足以存儲新增加的數據，目前 NoSql 的數據都已經實現了
級聯的擴展，非常容易實現添加新的節點到已有集群，操作簡單。
1.3：最終一致性
在這里再次強調一下最終一致性：Cassandra 采用了最終的一致性：
最終的一致性是指分布式系統之中的一個數據對象的多個副本盡管在短時間內可能出現不一致，但是經過
一段時間以后，這些副本最終會達到一致。
Cassandra 是優先保證了 AP，也就是我們經常說到的可用性，和分區容錯性。
通常而言，大部分的 NoSQL key-value 的模式都是寫入非常的高效，畢竟是為了大量數據的插入所涉及，
可是在數據的讀取方面那就依據不同的情況而不同。
1：如果是單個讀取指定了的 key，那就回很快的返回結果。-》指定 key 查詢。
2 : 如果是范圍查詢，由于查詢的目標可能存儲在多個節點之上，這就需要要對多個節點
來進行查詢，速度會比較慢。
3：全表掃。毫無疑問，全表掃描數據，會非常的低效。
數據模型
由于 Cassandra 采用了類似與 BigTable 的數據結構組織，Cassandra 和 Hbase 比較類似。所以 Cassandra 和 Hbase 相比也存在著許多相同的概念。
如果抽象來看 Cassandra。整個 Cassandra 都是一個五維的空間
1：column
column：列，在 Cassandra 之中是最小的一個數據單元，它包含了一個三元的數據類型：
1: { // 這是一個 column
2: name: 美麗新世界 ,
3: value: gpcuster@gmali.com ,
4: timestamp: 123456789
5: }
upercolumn：超級列
我們可以將 SuperColumn 想象成 Column 的數組，他包含一個 name。以及一系列的 Column
將一個 SuperColumn 用 JSON 的形式表示如下
{ // 這是一個 SuperColumn
2: name: “美麗的新世界 ,
3: // 包含一系列的 Columns
4: value: { 5: street: {name: street , value: 1234 x street , timestamp: 123456789},
6: city: {name: city , value: san francisco , timestamp: 123456789},
7: zip: {name: zip , value: 94107 , timestamp: 123456789},
8: }
9: }
Columns 和 SuperColumns 都是一個 Key Value，一個 name 和一個 String 的組合，最大的不同在于 Column 的 Value 是一個“String”，而 SuperColumn 的 value 是一個 Cloumns 的 Map
1：Column family
Column family 是一個包含了一個許多行 [Row] 的結構，你可以將它想象成 RDBMS 中的 Table，每一個行都包含有 Clinet 提供的 Key 和該 KEY 關聯的的一系列的 Column，我們可以看到如下的結構：
1: UserProfile = { // 這是一個 ColumnFamily
2: phatduckk: { // 這是對應 ColumnFamily 的 key
3: // 這是 Key 下對應的 Column
4: username: gpcuster ,
5: email: gpcuster@gmail.com ,
6: phone: 6666
7: }, // 第一個 row 結束
8: ieure: { // 這是 ColumnFamily 的另一個 key
9: // 這是另一個 Key 對應的 column
10: username: pengguo ,
11: email: pengguo@live.com ,
12: phone: 888
13: age: 66
14: },
15: } 1: UserProfile = { // 這是一個 ColumnFamily
2: phatduckk: { // 這是對應 ColumnFamily 的 key
3: // 這是 Key 下對應的 Column
4: username: gpcuster ,
5: email: gpcuster@gmail.com ,
6: phone: 6666
7: }, // 第一個 row 結束
8: ieure: { // 這是 ColumnFamily 的另一個 key
9: // 這是另一個 Key 對應的 column
10: username: pengguo ,
11: email: pengguo@live.com ,
12: phone: 888
13: age: 66
14: },
15: }ColumnFamily 的類型可以是 Standard，也可以是 Super 的類型，我們剛剛看到的例子是一個 Stand 類型的 ColumnFamily。除此之外，還有另外的一種形式，也就是不每一行不僅僅只是一個列，還可能是一個 CF
如下所示：
1: AddressBook = { // 這是一個 Super 類型的 ColumnFamily
2: phatduckk: { // key
3: friend1: {street: 8th street , zip: 90210 , city: Beverley Hills , state: CA},
4: John: {street: Howard street , zip: 94404 , city: FC , state: CA},
5: Kim: {street: X street , zip: 87876 , city: Balls , state: VA},
6: Tod: {street: Jerry street , zip: 54556 , city: Cartoon , state: CO},
7: Bob: {street: Q Blvd , zip: 24252 , city: Nowhere , state: MN},
8: ...
9: }, // row 結束
10: ieure: { // key
11: joey: {street: A ave , zip: 55485 , city: Hell , state: NV},
12: William: {street: Armpit Dr , zip: 93301 , city: Bakersfield , state: CA},
13: },
14: }注意，在 Hbase 之中也有一個 CL 的概念。
3：keySpace
KeySpace 是我們最外層的數據結構，通常的情況，我們的應用程序只有一個 KeySpace，簡單點來講，keySpace，可以把 keySpace 想象成為 RDBMS 之中的 database。
相對與關系型的數據庫的三層結構：
database – table – colum 而言。
cassandra 的結構層次如下：
keyspace- column family【column|super column】
看完上述內容，你們掌握如何進行 Cassandra 模型以及架構的分析的方法了嗎？如果還想學到更多技能或想了解更多相關內容，歡迎關注丸趣 TV 行業資訊頻道，感謝各位的閱讀！
