宇文湛泉，現任金融行業核心業務系統DBA，主要涉及Oracle、DB2、Cassandra等數據庫開發工作。
Cassandra數據庫，值得介紹的技術細節其實挺多的。因為它很多實現思路和關係型數據庫或者其他的NoSQL數據庫，是有一些不同的。這種不同是在數據庫設計實現思路上也是根源上的。所以衍生開來的諸多特點，在介紹起來就不太容易和其他數據庫去類比。那麼Cassandra有這麼大量的內容，本文只能選講其中的一部分，這部分內容是如何挑選的呢？
在《Cassandra The Definitive Guide》這本書裡，有一段概括性的描述，即用50個word描述Cassandra。它歸納了Cassandra的幾大特性，依次為：開源、分佈式、去中心化、可擴展性、高可用、容錯性、可配置的一致性、行存儲。
我把這幾大特性分為四類：
第一類開源，這個不需要討論。其餘的三類7個特性，就是選講的核心提綱。
第二類是高可用、容錯性、可配置的一致性，這是圍繞著多節點冗餘數據的特性，換句話說，如果Cassandra的數據，每一行數據只有一份而沒有副本，那麼第二類特點就是不存在的。
第三類是分佈式、去中心化、可擴展性，這三個特點圍繞的是數據庫的可拆分性，且各節點可以獨立運行的能力。若只裝一個單機的Cassandra，那這一類特點就不存在。
第四類是行存儲，是描述數據庫底層存放數據的最基本的存儲結構特徵，也是我切入的第一個特徵。
行存儲結構
任何數據庫設計和優化始終圍繞一個核心事情——查詢優化。查詢永遠是使用數據的核心需求。為什麼要INSERT？為了以後這個數據要查詢。為什麼要DELETE？因為不再查詢，並且讓其他的數據更快的查詢。為什麼要UPDATE，因為要實時的查詢使用。無論是數據庫的存儲結構，像ORACLE的段、區、塊的設計，還是輔助的存儲結構，像索引這種，歸根結底，為了更快速的查詢出需要數據。Cassandra也不例外，瞭解它的存儲結構，就更加能夠理解它是如何在這個存儲體系下提高查詢性能的，即便它是一個號稱更擅長於INSERT的數據庫。
在早期的Cassandra中，數據庫表一直被稱之為ColumnFamily（列族），我也有很長的時間將其理解為列的集合的意思。所以，我有一段時間認為Cassandra是一個列存儲的數據庫。那為什麼Cassandra的數據模型，可以認為是行存儲（ROW-ORIENTED）的，但又會在早期表被稱之ColumnFamily呢？因為從根本上來講，Cassandra不能算一個嚴格的行存儲，當然它更不是列存儲，它的數據是存儲在一個稀疏矩陣中的。可能這個解釋略微抽象。那麼我先來說下它為什麼不是行存儲。
任何傳統的行存儲數據庫，一旦DDL定義了數據表有多少個列。那麼這一行數據一定存儲了所有的列值。即使出現了這一列沒有值的情況，那麼也一定存儲了一個值，或者是由應用程序存儲一個空格或0來表示沒有值。這一列對應的存儲空間一定是存在的，當然數據庫中的varchar或者壓縮算法會使得這個存儲空間儘可能小。
但是，Cassandra允許對於任何給定的行，你可以只包含其中幾列，而並非一行數據要有所有的列，當然KEY列是要有的。這種在列值存儲上的動態性，是傳統的行存儲數據庫根本不具備的。我猜這也可能早期為何有ColumnFamily概念的根源。
前文提到了，我有一段時間認為Cassandra是一個列存儲的數據庫。但是，我從來都認為它是一個不徹底的列存儲數據庫，而是一個受限的列存儲數據庫。不徹底在哪裡？大部分的列存儲數據庫，都是為了OLAP而生的，它的優勢在於，在某一列上做聚合的性能無語倫比。
比如我一個表有100列，我要對某一列求個SUM。列存儲數據庫可以完美繞過多餘的99列，只把需要的這一列一個不差的拿出來做SUM。但是，用過Cassandra數據庫的人都知道，在任何一列上做全列級的聚合，那簡直是災難性的。就憑Cassandra會將不同的KEY部署在不同的數據庫節點/分區PARTITION（注意這裡和傳統數據庫分區不同），任何列級的操作，都會需要在多個數據庫上打轉。更何況，CQL語句到來的時候，還要搞清楚，這個聚合列在這行數據上有沒有。所以，Cassandra是不具備列存儲數據庫的特質的。
為什麼，最後Cassandra還是被描述為是一個ROW-ORIENTED呢？
首先，它的存儲是緊緊圍繞著Key的。Key，它是一行數據的唯一標識符號。一行數據圍繞著Partition Key存在一起,並且圍繞著Clusterting Key局部有序。可見它ROW-ORIENTED的特點還是很鮮明的。什麼樣的存儲結構，就決定一個數據庫擅長做什麼。按主鍵排序的行存儲DB2數據庫最擅長的是什麼？是在OLTP系統裡，通過主鍵做單條記錄的快速查詢（Select by Key），這也正是Cassandra最為常見的CQL形態。什麼樣的存儲結構，也決定了什麼樣的操作會有限制。
在理解了Cassandra數據庫的ROW-ORIENTED的稀疏矩陣存儲之後，再來看看CQL語句的語法限制，那麼這些限制就很容易理解。例如：Select 語句，Where條件裡，一定要送Partition Key（沒有次索引的情況）。如果不送，則語法上必須要添加ALLOW FILTERING。
為什麼是這樣，剛才提到了，Partition Key決定了數據存在哪裡，它像是一個指針，直接指向了這一行數據的物理位置。ALLOW FILTERING表示什麼，表示的是Cassandra數據庫獲得這條記錄是通過篩選得來的，而不是通過直接定位得來的。
類比一下傳統數據庫，Where 條件送Partition Key就好比通過HASH索引定位記錄，ALLOW FILTERING就如同先做一次TABLE SCAN，讀出大量記錄再從記錄裡過濾出符合WHERE條件的。再看看關於Clusterting Key的，CQL語法要求，範圍查找、Order by一類的語法都需要使用Clusterting Key，這就十分好理解。在定位的Partition Key確定了位置之後，同一Partition Key的數據，都是Clusterting Key有序存放的，那麼通過在這個有序的Key列上，無論範圍也好、排序也好，都不會需要數據庫引擎真正去排序，這就好像在傳統數據庫裡，ORDER BY的列，和某一個索引一致的情況下，執行計劃裡不會真的排序是一個道理。
搞清楚了Cassandra的存儲結構之後，我們來看Cassandra在某一個節點上怎麼做增刪改查。無論Cassandra的多節點特點多麼鮮明，在單一節點上面，數據的讀寫，永遠才是數據庫性能的根基。節點再多，如果單節點上讀寫性能不行，那數據庫終究是快不起來的。所以這裡我們來看一下，Cassandra是怎麼樣讀寫數據的。
先翻譯《Cassandra The Definitive Guide》一段話。“在Cassandra中，寫入數據非常快，因為它的memtables和SSTables設計，使它插入時，不需要執行磁盤讀取或搜索，這些減慢數據庫速度的操作。Cassandra中的所有寫入都是追加形態的。”
我們看一下Cassandra的寫入步驟，來解讀它的寫入優勢。
第一步，寫Commit Logs。這個步驟完全不是什麼新發明。我覺得它和傳統數據庫的REDO Log幾乎是一樣的。無論是什麼數據庫，這個Log的寫入，都是追加形態的。但是，注意看這個圖，Commit Logs直接寫在硬盤上，我認為這個描述並不準確。無論時傳統數據庫的REDO LOG還是Cassandra 的Commit Logs，它都是先到內存，再FLUSH到磁盤上的。而FLUSH的策略是由一些參數決定的，比如commitlog_sync。這和傳統數據庫非常相似，這裡不展開來討論，只需要認識到一點，FLUSH的動作頻率越高，系統奔潰時丟失的數據越少，同時損失部分數據插入性能。就像Mysql數據庫的參數Innodb_flush_log_at_trx_commit=1時，Mysql是最安全，但是也是最慢的。
第二步，Add to memtable，這是關鍵的一步，Cassandra的這一步是完完全全的內存動作。而若是傳統的數據庫，則大約需要做這麼幾個動作：
逐層搜索索引，若這個索引塊不在DATA BUFFER裡，觸發磁盤IO。
通過索引定位數據塊，若數據塊不在DATA BUFFER裡，觸發磁盤IO。
修改索引塊，修改數據塊，如果修改併發量大時，可能產生鎖等。
當然，若是像Oracle數據庫那樣的堆表設計，純粹的INSERT動作在b的IO觸發可能性要少一點，但是在UPDATE（Cassandra中也是Insert）場景下，這些開銷都是不可少的。Cassandra為什麼可以在Memtable上純粹的做追加寫入，這個Cassandra記錄的Timestamp概念是分不開的，即無論你寫入多少次，數據庫只會以最新Timestamp的記錄為準。這樣就不需要去對記錄資源上鎖。這樣的設計，不要說沒有鎖衝突了，就連去把需要上鎖的記錄找出來的開銷都省了，快就快在這個地方。
但是，這個快是有代價的，那就是數據的一致性。比如一個簡單的需求，在數據寫入之前，需要看看這條數據是不是存在，如果存在了就不能插入（CQL的IF NOT EXIST語法），或者UPDATE需要看數據條件（WHERE IF Column = ‘*’） 。一旦這種帶條件CQL使用，那可以推斷，上面的這些優勢，也就不存在了。
看第三步，如果這行數據在Row Caches裡，使它失效。注意這個地方，Row Caches裡的記錄是不改的。那麼Row Caches的使用場景，只有特別熱點的數據讀取的時候使用，它並不適合高併發熱點數據修改的場景。
常規交易，做完這三步就返回成功了，不需要等待Memtable的內容落盤。換句話說，直接影響交易性能的步驟，結束了。這和傳統數據庫也沒有太大的差別。那麼接下來的步驟，就不直接影響數據庫的寫入能力。
第四步，數據的落盤，這個動作通常是異步的，在後面會詳細展開將SSTable的存儲。第五步，這個就是多節點特性了，是一個節點異常的處理過程。
總結一下，傳統的數據庫的寫入（包括INSERT、UPDATE、Delete），通常是一個讀後寫的過程。而Cassandra的寫入，是沒有先讀這個動作的，這也是它快的根本原因。一旦使用了IF NOT EXIST之類的語法，那麼它的寫入性能也就會要受損。
接下來看一下Cassandra的讀取，它的讀取是多節點、多副本的讀取。此處，我們先關注一個節點上的情況。
第一步，如果這一行數據在Row Caches中，直接返回數據，這個好理解。
第二步，檢查檢查KeyCaches裡的索引，這裡可以理解為，這是一個主鍵索引，它存儲的是未來在Memtables或者SSTables用來定位的信息（書上原文是offset location）。需要注意的是，這裡面的值，在第三步、和第四步的時候，都可能用得上，而不是僅僅用於第三步。看到這個地方，可以發現，其實這個圖有個問題，就是沒有指出KeyCaches的維護。Cache是可以在建表時配置的一個參數。可以推測，假如我們建表的時候，keys的Cache採用了ALL的設置，那麼應該是在有新的KEY值寫入Memtables時，維護到了Key Caches中。
第三步，這一步需要關注是，對於一個指定的表（或列族），是隻會使用唯一的一個Memtable 的，那麼這個搜索就是線性的。Memtable中的內容，是還沒有FLUSH到SSTables裡的數據，在查詢是，它裡面的內容和SSTables中的內容，都是要同步讀取的，但對單節點而言，它的內容通常更新。
與寫入場景大有不同的地方是，讀數據的關鍵步驟，是第4步，讀SSTables。這裡在後面的內容展開，看一下第五步，如果Row Caches還可用，把這條記錄加入的Row Caches。Row Caches放的是一整行的數據，如前面提到了，適合於存放熱點讀取的數據。
所有的數據庫，通常都是有四大常規操作，謂之“增刪改查”。介紹了寫入、查詢之後，這裡簡單的介紹一下Cassandra的刪和改。一句話簡述之，Cassandra的刪除都是修改，Cassandra的修改都是寫入，所以Cassandra只有寫入和查詢。Cassandra一直寫入數據，豈不是會存儲爆炸不成。在這裡，我們介紹三個新概念（相對傳統數據庫）-Tombstones，Timestamps，Compaction。
Cassandra的刪除都是修改，這個好理解，在很多業務數據庫表裡面，經常會為了保留痕跡，而做一個邏輯刪除動作。也就是修改某個標識，表示這條記錄以及刪除或作廢，而並沒有在數據庫裡真正的刪除。Cassandra在收到Delete命令時，並不會立刻去刪除這行記錄。而是會給這行記錄一個Tombstones，表示它被刪除了。
Cassandra的修改都是寫入。前面提到Cassandra速度快，快在不需要定位數據。任何Update命令，在傳統數據庫上，都需要把這條記錄讀到內存裡，並上鎖。而在Cassandra上，Update命令會變成一條INSERT語句，那豈不是在系統裡重KEY了嗎？這裡便要依靠記錄上的Timestamps。
Cassandra的每次查詢，都會把所有重的KEY讀出來，但是永遠會以最新的Timestamps為準。這就解決了把所有的修改，都變成寫入的問題。但是，這麼幹有兩大顯而易見問題。第一，數據會無限的膨脹，吃掉磁盤。第二，數據膨脹會帶來查詢需要讀出的重複數據增加，無限的膨脹則會無限的增加，讀取性能就會受損。
所以這裡，就要介紹壓縮（Compaction）的概念。這裡要特別的注意，這不是我們通常說的數據庫壓縮技術，那個通常用的Compress。只是由於多個官方文檔都把Compaction翻譯成了壓縮，我個人覺得它更應該翻譯成數據的整理。Compaction是在數據庫後臺異步做的，接著前面的內容，它的內容至少有比如把墓碑數據真實移除，把時間戳比較老的數據移除，重新整理SSTable的存儲文件等。這樣來解決前面那兩個問題。這個動作在某種意義上來講甚至有一點像DB2數據庫的REORG動作。不同的數據庫表，可以在Keyspace級別選擇不一樣的CompactionStrategy。它常翻譯為壓縮算法，我覺得翻譯成整理策略更加合適。我覺壓縮算法，應該和Compress的那個概念一致。畢竟，這個Compaction沒有給數據文件裡連續的值，用個RLE算法，或者建個字典什麼的對吧。介紹完了這些之後，讓我們來直面數據庫最大的瓶頸。
只要一個數據庫不是內存數據庫，那它永遠都要面對它最大的性能瓶頸，磁盤IO。我們前面提到的諸多概念，比如Cache、列存儲、索引等等，他們優化性能的本質都指向一處，減少磁盤IO。前面講讀寫部分時，都跳過了第4步。而對於SSTable的讀取，其實才是影響性能的關鍵步驟。
我們來看一下，SSTable到底是什麼，它的讀取是什麼樣子的。我們根據SSTable的訪問順序來看，在3.0版本中，SSTable包含以下這麼幾個文件：
Filter.db這是SSTable的Bloom過濾器，簡單的講，它告訴你，你要的Key，在我這裡有沒有。Bloom過濾器的工作方式是將數據集中的值映射到位數組，並使用散列函數將較大的數據集壓縮為摘要字符串。根據定義，摘要使用的內存量比原始數據少得多。它速度快，可能誤報，但不會漏。簡言之，有可能告訴你有，但是沒有。但絕不會告訴沒有，卻有。注意！這裡劃一個重點，Cassandra會維護一個Bloom filter的副本在內存裡面。所以，這一步不一定會有實際IO。在書上也提到，如果加大內存，是可以減少Bloom過濾器誤報的情況。
Summary.db，這裡是索引的抽樣，用來加速讀取的。
Index.db，提供Data.db裡的行列偏移量。
CompressionInfo.db提供有關Data.db文件壓縮的元數據。這裡值得關注的是，它用了Compression這個詞，我猜測，如果Data.db裡面採用了壓縮算法，比如說字典壓縮之類的，那麼這個文件裡面應該就會存儲字典數據，或者類似的Compress相關的元素據。這也就是為什麼這個文件，在訪問流程中是不可繞過的。因為一旦Data.db的數據進行了壓縮，那就必須依靠相關的元數據來解壓縮數據。從圖上可以看出，這個元數據在內存中，相對性能會比較快。
Data.db是存儲實際數據的文件，是Cassandra備份機制保留的唯一文件。它是唯一的真實數據，其他的都是輔助數據。比如索引可以重建，字典可以重建等等。
Digest.adler32是Data.db校驗用的。
Statistics.db存儲nodetool tablehistograms命令使用的有關SSTable的統計信息。
TOC.txt列出此SSTable的文件組件。
其中1-5是跟SSTable訪問數據性能相關的文件。如果Cache是ALL的情況下，Cassandra在通常都可以在內存訪問之後，直接定位到SSTable的具體文件和數據所在偏移量中去。相對於傳統數據庫，B樹索引層層向下，遇到沒有的索引塊就要IO。這個性能應該還是非常可觀的。
講到這裡，不知道你有沒有感受到，Cassandra的一個重要精華所在，那就是沒有鎖，或者叫沒有資源上的衝突和爭搶。通過Timestamps概念，解決數據可相同Key數據不要上鎖的問題。儘管我們前面的內容，全部都還只是在圍繞單節點數據庫介紹。但是Timestamps的使用，是為Cassandra分佈式、去中心、可擴展、高可用、容錯性、可配置一致性提供了更多靈活方便的地方。
分佈式、去中心、可擴展性
前面我們把這六條分成了兩類，分佈式、去中心、可擴展，這三個圍繞的是KEY的獨立性。尤其是Partition Key，它是具有極強的獨立性的。由於它的極度獨立，理論上任何不同Partition Key的數據，就都可以放在不同機器上，去獨立的提供服務，也就成就它的分佈式、去中心和可擴展。對照這幾條特性看一下。
分佈式，百度詞條上解釋為，建立在網絡上的軟件系統。有四大特性：
分佈性。分佈式系統由多臺計算機組成，它們在地域上是分散的，可以散佈在一個單位、一個城市、一個國家，甚至全球範圍內。整個系統的功能是分散在各個節點上實現的，因而分佈式系統具有數據處理的分佈性。一個邏輯上的數據庫表，他是分散存儲來多個Node中的。不同的Key值的記錄會由Cassandra的不能節點提供分散的的服務。
自治性。分佈式系統中的各個節點都包含自己的處理機和內存，各自具有獨立的處理數據的功能。通常，彼此在地位上是平等的，無主次之分，既能自治地進行工作，又能利用共享的通信線路來傳送信息，協調任務處理。Cassandra只有在Partition Key劃分數據所屬Node的存儲位置時，有主次副本之分。比如說，我的Node1要存放的Key值是多少到多少，其他的勉強稱之為副本。其實Cassandra存的是多個地位平等主本，且都具備獨立處理數據等能力，它們協同處理任務，並非傳統意義上的主備數據概念。
並行性。一個大的任務可以劃分為若干個子任務，分別在不同的主機上執行。每個Node自然是自己提供涉及的Key的服務，相互之間獨立、並行。對於不同的CQL而言，可能會由不同Node來完成查詢。也可以是一個CQL裡面涉及的多個Node，它們也基本上是並行來完成這個CQL的。
全局性。分佈式系統中必須存在一個單一的、全局的進程通信機制，使得任何一個進程都能與其他進程通信，並且不區分本地通信與遠程通信。同時，還應當有全局的保護機制。系統中所有機器上有統一的系統調用集合，它們必須適應分佈式的環境。在所有CPU上運行同樣的內核，使協調工作更加容易。Cassandra是完全符合這個定義的，Coordinator節點並不是固定的。每個節點都可以接受任何的CQL，並且來充當協調者的角色。重要的是，對於一個應用程序或者客戶端而且，可以不關心Cassandra後來是怎麼樣存儲和查詢數據的。它從外面看到的，始終只有一張完整的邏輯數據表。
有了分佈式的基礎，Cassandra可以運行在多個Node下，並且多個Node可以部署在真實的不同的數據中心機房裡，不同機架上，也就能做到去中心Decentralized。有了這個基礎，就可以配合Cassandra的多中心的複製策略NetworkTopologyStrategy，在每一個數據中心定義數據複製了。
可擴展這個詞其實，並不是特別準確，它的重點其實是可水平擴展。簡而言之，就是在圖中環上加Node，就可以提高Cassandra的處理能力。這其實和它的分佈式特點是密不可分的。Cassandra的拆分粒度最細，理論上幾乎可以到一個Partition KEY。或者說，每一個Partition KEY，都可以被看作可以拆分的，獨立處理的最小的單位。增加數據的同時只要增加Node就可以了，這就使得它的水平擴展性是很好的。
做一個偏激的假設，如果Cassandra只有一份數據存儲，就憑Key獨立的特點，把不同的Key分到不同的機器上提供服務，也可以算得上是分佈式、去中心和可擴展的。但是它這個特點是不完美，不徹底的。因為機器分得越多，任何一臺機器故障，它提供的服務就是不完整的。
高可用、容錯性、可配置一致性
接下來，我們繼續看另外三個特點，高可用、容錯性、可配置的一致性，這些特點圍繞的核心就數據冗餘。
任何的高可用背後，一定是有數據冗餘的。傳統數據庫通常偏愛的是主備模式，就是當提供服務的數據庫節點DOWN掉之後，備節點開始提供服務。這時候往往故障檢測、主備切換，應用切換的時間就會成為關注的焦點，做得好一點的數據庫可以在1分鐘或者幾十秒內完成切換。不過在如今7*24*365的環境下，1分鐘的故障恢復時間通常並不能讓用戶十分滿意，當切換時間壓縮到一定程度，還會出現一個矛盾點，就是數據庫異常時間監測閾值。如果設得太長，主備切換就慢，設太短了，一個網絡抖動，就可能觸發不必要的主備切換誤判。
Cassandra的數據複製（replicas）並不像傳統的備份數據，它更像是多份主數據，這些數據都是時時刻刻對外提供服務的，換句話說，有一個數據庫節點DOWN掉，完全不需要主備切換時間。在資源充足的情況下，甚至是幾乎無感的（比如7個replicas壞了1個）。
在Cassandra裡面，數據複製（replicas）多少份，怎麼存儲，這個策略是可以根據不同的Keyspace來設置的，相當於提供一個靈活的選擇，可以根據數據庫表的實際使用場景和形態，來決定數據複製的策略。
數據冗餘可以說是分佈式系統中的常規操作，像參數數據之類的，經常會採用數據冗餘的方法來處理。然而，有冗餘的地方就有同步。數據一致性問題，永遠和數據冗餘相伴而生。好在Cassandra有Timestamps來解決一致性問題，容錯性只是一致性的一個衍生產品，簡單的說，只是Cassandra發現了一個老Timestamps的錯誤數據，後臺修復一下而已。
而可配置一致性，就是Cassandra的一個特別重要的特性了。因為它的影響但不僅僅是對於高可用，它還直接影響數據庫性能。就傳統數據庫而言，開不開備庫，對OLTP交易性能也是有直接影響的（包括Redis也是）。從理論上來說，Cassandra要等更多的Node寫入數據，那響應時間就會越慢。這個響應時間取決與最慢的那個Node。若要交易響應更快，就需要通過異步的方式。所以Cassandra通常都不會等所有的Node都響應，等多少Node，等哪些Node，就是可配置一致性。
在數據寫入讀取方面Cassandra的一直性級別有：
ANY（僅寫入）,ONE,TWO,THREE ,QUORUM,ALL
LOCAL_ONE, LOCAL_QUORUM,EACH_QUORUM
以上這些級別很好理解，不需要逐個解釋。關於高可用和強一致性，永遠都是魚和熊掌。假如我們的系統使用了最快的方式寫入，比如寫ANY，讀ONE。那麼讀到的數據並不是最實時的準確數據的可能性就會大幅增加。如上面的圖，有6個節點在寫入數據，任意一個寫成功，程序就成功返回。那麼假定其餘5個節點還沒有完成寫入。那這時候，有一個讀ONE的程序，恰好讀到了這5節點中的一個，併成功返回，這就產生了數據的不一致。要做到數據的強一致，讀寫策略就必須配合設置，滿足這樣的條件。
W+R>RF W—寫一致性級別 R—讀一致性級別 RF—副本數
Cassandra的這個設計非常的巧妙，它提供極好的調優靈活性。數據庫調優的本質無非是個損有餘而補不足的過程，這個有餘並非指損性能好的地方去補性能不好的地方。
數據庫或數據，有些地方有些功能，我們不用或者少用，性能不需要那麼好，稱之為有餘；有些地方有些功能我們常用，主要用，性能要越快越好，我們稱之為不足。比如很多系統的某個數據庫表，它的訪問形態是有侷限性的。有可能一張表，100次插入，只有1次讀取，像流水數據。有可能一張表，1次插入，100次讀取，像參數數據。這裡面就有了極大的靈活性，我們可以損失冷門操作的性能，來保障我們的主要操作。例如，以讀取為主的表，我們可以設置寫入的一致性為ALL ,讀取的一致性為ONE。從而獲得一個非常高效的系統性能。
需要注意的是，數據的複製因子，是定義在Keyspace，也就是在存儲方面決定。而讀取的一致性，是由客戶端決定的。同樣的數據，也可以根據不同使用場景來使用不同的一致性級別。比如說，對數據實時性要求高時，可以設置成讀QUORUM或者ALL，實時性要求低時，選擇讀ONE。
總結
至此，我已經完整的講解了Cassandra的分佈式、去中心化、可擴展性、高可用、容錯性、可配置的一致性、行存儲的特性。
回顧一下，我們先講了Cassandra單節點上的行存儲結構，然後圍繞Cassandra數據Key的獨立性介紹了分佈式、去中心化、可擴展性。繼而討論了關於Cassandra多副本數據帶來的高可用、容錯性、和可配置一致性。
當然Cassandra數據庫還有很多值得探討和介紹的內容和概念，如Secondary Index、Tokens、Hinted等等。此外在Cassandra數據庫的使用過程中，也還有監控、備份恢復、性能調優、安全等等內容值得關注學習，這裡就不一一介紹了，未來有機會，再做續集吧。
>>>>
2020年4月17日，北京，Gdevops全球敏捷運維峰會將開啟年度首站！重點圍繞數據庫、智慧運維、Fintech金融科技領域，攜手阿里、騰訊、螞蟻金服、中國銀行、平安銀行、中郵消費金融、建設銀行、農業銀行、民生銀行、中國聯通大數據、浙江移動、新炬網絡等技術代表，展望雲時代下數據庫發展趨勢、破解運維轉型困局。
閱讀更多 dbaplus社群 的文章
