如何進行Cassandra模型以及架構(gòu)的分析，相信很多沒有經(jīng)驗的人對此束手無策，為此本文總結(jié)了問題出現(xiàn)的原因和解決方法，通過這篇文章希望你能解決這個問題。

創(chuàng)新互聯(lián)-專業(yè)網(wǎng)站定制、快速模板網(wǎng)站建設(shè)、高性價比渭濱網(wǎng)站開發(fā)、企業(yè)建站全套包干低至880元,成熟完善的模板庫,直接使用。一站式渭濱網(wǎng)站制作公司更省心,省錢,快速模板網(wǎng)站建設(shè)找我們，業(yè)務(wù)覆蓋渭濱地區(qū)。費用合理售后完善，十載實體公司更值得信賴。

 NOSQL的世界紛繁復(fù)雜，出去掉redis等內(nèi)存型的數(shù)據(jù)庫之外，在整個NoSQl領(lǐng)域比較認可的是  Cassandra，Hbase，以及MongoDB。

對于Mongo，目前本ID的系列博文已經(jīng)有部分，而Hbase有關(guān)的部分還未補充，待補。

高可靠性

    協(xié)議

1：Cassandra采用了gossip作為集群中節(jié)點的通信協(xié)議，該協(xié)議整個節(jié)點都處于同等的地位，沒有主從

之分，這就使得任一節(jié)點的推出都不會導(dǎo)致整個集群的失效。

2:Cassandra 和Hbase在底層的架構(gòu)設(shè)計都是借鑒了 Google Big Table的思想來構(gòu)建自己的系統(tǒng)，而

Cassandra的創(chuàng)新就是將原本用在文件共享架構(gòu)的P2P （Peer to Peer）引入到了NoSql

P2P的一大特點就是去中心化，集群之中的所有節(jié)點都有著同等的地位，這極大的避免了單個節(jié)點退出，

而使整個集群不能工作的可能，與之形成對比的是Hbase采用了Master/Slave的方式，這就存在了單點失效的可能。

1.2：高擴展性

隨著時間的推移，集群中原有的規(guī)模不足以存儲新增加的數(shù)據(jù)，目前NoSql的數(shù)據(jù)都已經(jīng)實現(xiàn)了

級聯(lián)的擴展，非常容易實現(xiàn)添加新的節(jié)點到已有集群，操作簡單。

1.3：最終一致性

        在這里再次強調(diào)一下最終一致性：Cassandra采用了最終的一致性：

         最終的一致性是指分布式系統(tǒng)之中的一個數(shù)據(jù)對象的多個副本盡管在短時間內(nèi)可能出現(xiàn)不一致，但是經(jīng)過

一段時間以后，這些副本最終會達到一致。

Cassandra是優(yōu)先保證了AP，也就是我們經(jīng)常說到的可用性，和分區(qū)容錯性。

通常而言，大部分的NoSQL key-value的模式都是寫入非常的高效，畢竟是為了大量數(shù)據(jù)的插入所涉及，

可是在數(shù)據(jù)的讀取方面那就依據(jù)不同的情況而不同。

1 ：如果是單個讀取指定了的key，那就回很快的返回結(jié)果。 -》指定key查詢。

2  :  如果是范圍查詢，由于查詢的目標可能存儲在多個節(jié)點之上，這就需要要對多個節(jié)點

       來進行查詢，速度會比較慢。

3 ：全表掃。毫無疑問，全表掃描數(shù)據(jù)，會非常的低效。

數(shù)據(jù)模型

       由于 Cassandra采用了類似與BigTable的數(shù)據(jù)結(jié)構(gòu)組織，Cassandra和Hbase比較類似。所以Cassandra和Hbase相比也存在著許多相同的概念。

        

                如果抽象來看Cassandra。整個Cassandra都是一個五維的空間

      

            1：column        

                    column：列，在Cassandra之中是最小的一個數(shù)據(jù)單元，它包含了一個三元的數(shù)據(jù)類型：

   1: {  // 這是一個column
   2:     name: "美麗新世界",
   3:     value: "gpcuster@gmali.com",
   4:     timestamp: 123456789
   5: }

upercolumn：超級列

            我們可以將SuperColumn想象成Column的數(shù)組，他包含一個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]的結(jié)構(gòu)，你可以將它想象成RDBMS中的Table，每一個行都包含有Clinet提供的Key和該KEY關(guān)聯(lián)的的一系列的Column，我們可以看到如下的結(jié)構(gòu)：

   1: UserProfile = { // 這是一個ColumnFamily
   2:     phatduckk: {   // 這是對應(yīng)ColumnFamily的key
   3:         // 這是Key下對應(yīng)的Column
   4:         username: "gpcuster",
   5:         email: "gpcuster@gmail.com",
   6:         phone: "6666"
   7:     }, // 第一個row結(jié)束
   8:     ieure: {   // 這是ColumnFamily的另一個key
   9:         //這是另一個Key對應(yīng)的column
  10:         username: "pengguo",
  11:         email: "pengguo@live.com",
  12:         phone: "888"
  13:         age: "66"
  14:     },
  15: }

    1: UserProfile = { // 這是一個ColumnFamily
   2:     phatduckk: {   // 這是對應(yīng)ColumnFamily的key
   3:         // 這是Key下對應(yīng)的Column
   4:         username: "gpcuster",
   5:         email: "gpcuster@gmail.com",
   6:         phone: "6666"
   7:     }, // 第一個row結(jié)束
   8:     ieure: {   // 這是ColumnFamily的另一個key
   9:         //這是另一個Key對應(yīng)的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結(jié)束
  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是我們最外層的數(shù)據(jù)結(jié)構(gòu)，通常的情況，我們的應(yīng)用程序只有一個KeySpace，簡單點來講，keySpace，可以把keySpace想象成為RDBMS之中的 database。

                相對與關(guān)系型的數(shù)據(jù)庫的三層結(jié)構(gòu)：

                        database -> table -> colum而言。

                cassandra的結(jié)構(gòu)層次如下：

                        keyspace->column family>【column|super column】

看完上述內(nèi)容，你們掌握如何進行Cassandra模型以及架構(gòu)的分析的方法了嗎？如果還想學(xué)到更多技能或想了解更多相關(guān)內(nèi)容，歡迎關(guān)注創(chuàng)新互聯(lián)行業(yè)資訊頻道，感謝各位的閱讀！

新聞名稱：如何進行Cassandra模型以及架構(gòu)的分析
文章源于：http://chinadenli.net/article36/goicsg.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供定制網(wǎng)站、品牌網(wǎng)站建設(shè)、動態(tài)網(wǎng)站、外貿(mào)建站、網(wǎng)站制作、手機網(wǎng)站建設(shè)

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請盡快告知，我們將會在第一時間刪除。文章觀點不代表本網(wǎng)站立場，如需處理請聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時需注明來源： 創(chuàng)新互聯(lián)