寫在前面
cassandra3.x官方文檔的非官方翻譯。翻譯內容水平全依賴本人英文水平和對cassandra的理解。所以強烈建議閱讀英文版cassandra 3.x 官方文檔。此文檔一半是翻譯，一半是個人對cassandra的認知。盡量將我的理解通過引用的方式標注，以示區別。另外文檔翻譯是項長期并有挑戰的工作，如果你愿意加入cassandra git book,可以發信給我。當然你也可以加入我們的QQ群,104822562。一起學習探討cassandra.
Cassandra寫的時候分好幾個階段寫處理數據，從立即寫一個write操作開始，到把數據寫到磁盤中
寫log到commit log
寫數據到memtable
從memtable中flush數據
將數據存儲在SSTables中的磁盤中
寫Log及memtable存儲
當一個寫發生的時候，Cassandra將數據存儲在一個內存結構中，叫memtable,并且提供了可配置
的持久化，同時也追加寫操作到磁盤上的commit log中。commit log記載了每一個到Cassandra 節點的寫入。
這些持久化的寫入永久的存活即使某個節點掉電了。memtable是一個數據分區寫回的緩存。Cassandra通過key
來查找。memtables順序寫，直到達到配置的限制，然后flushed.
從memtable中Flushing數據
為了flush數據，Cassandra以memtable-sorted的順序將數據寫入到磁盤。同時也會在磁盤上創建一個分區索引，
將數據的token map到磁盤的位置。當memtable 內容超過了配置的閾值或者commitlog的空間超過了
commitlog_total_space_in_mb的值，memtable 會被放入到一個隊列中，然后flush到磁盤中。這個隊列可以通過
cassandra.yaml文件中memtable_heap_space_in_mb,或者memtable_offheap_space_in_mb來配置。如果待flush的
數據超過了memtable_cleanup_threshold，Cassandra會block住寫操作。直到下一次flush成功。你可以手動的flush一張表，
使用nodetool flush 或者nodetool drain(flushes memtables 不需要監聽跟其他節點的連接)。為了降低commit log
的恢復時間，建議的最佳實踐是在重新啟動節點之前，flush memtable.如果一個節點停止了工作，將會從節點停止前開始，將commit log
恢復到memtable中。
當數據從memtable中flush到磁盤的一個SSTable中，對應的commit log數據將會被清除。
將數據存儲到磁盤中的SSTables中
Memtables 和 SSTables是根據每張表來維護的。而commit log則是表之間共用的。SSTables是不可改變的，當memtable被flushed后，
是不能夠重新寫入的。因此，一個分區存儲著多個SSTable文件。有幾個其他的SSTable 結構存在幫助讀操作。
對于每一個SSTable，Cassandra 創建了這些結構:
Data(Data.db)
SSTable的數據
PRimary Index(Index.db)
行index的指針，指向文件中的位置
Bloom filter (Filter.db)
一種存儲在內存中的結構，在訪問磁盤中的SSTable之前,檢查行數據是否存在memtable中
Compression Information(CompressionInfo.db)
保存未壓縮的數據長度，chunk的起點和其他壓縮信息。
Statistics(Statistics.db)
SSTable的內容統計數據元數據。
Digest(Digest.crc32, Digest.adler32, Digest.sha1)
保存adler32 checksum的數據文件
CRC (CRC.db)
保存沒有被壓縮的文件中的chunks的CRC32
SSTable Index Summary(SUMMARY.db)
存儲在內存中的的分區索引的一個樣例。
SSTable Table of Contents(TOC.txt)
存儲SSTable TOC 中所有的組件的列表。
Secondary Index(SL_.*.db)
內置的secondary index。每個SSTable可能存在多個SIs中。
SSTables是存儲在磁盤中的文件。SSTable文件的命名從Cassandra 2.2開始后發生變化為了
縮短文件路徑。變化發生在安裝的時候,數據文件存儲在一個數據目錄中。對于每一個keyspace,
一個目錄的下面一個數據目錄存儲著一張表。例如,
/data/data/ks1/cf1-5be396077b811e3a3ab9dc4b9ac088d/la-1-big-Data.db 代表著
一個數據文件.ks1 代表著keyspace 名字為了在streaming或者bulk loading數據的時候區分
keyspace。一個十六進制的字符串，5be396077b811e3a3ab9dc4b9ac088d在這個例子中，被加到
table名字中代表著unique的table IDs.
Cassandra為每張表創建了子目錄，允許你可以為每個table創建syslink，map到一個物理驅動或者數據
磁盤中。這樣可以將非常活躍的表移動到更快的媒介中，比如SSDs,獲得更好的性能，同時也將表拆分到各個
掛載的存儲設備中，在存儲層獲得更好的I/O平衡。
Cassandra 寫入過程中將數據存入到的文件叫做SSTables.SSTables 是不可更改的。Cassandra在寫入或者更新時不是去覆蓋已有的行，而是寫入一個帶有新的時間戳版本的數據到新的SSTables中。Cassandra刪除操作不是去移除數據，而是將它標記為墓碑。
隨著時間的推移，Cassandra可能會在不同的SSTables中寫入一行的多個版本的數據。每個版本都可能有獨立的不同的時間戳的列集合。隨著SSTables的增加，數據的分布需要收集越來越多的SSTables來返回一個完整的行數據。
為了保證數據庫的健康性，Cassandra周期性的合并SSTables,并將老數據廢棄掉。這個過程稱之為合并壓縮。
Cassandra 支持不同類型的壓縮策略，這個決定了哪些SSTables被選中做compaction，以及壓縮的行在新的SSTables中如何排序。每一種策略都有自己的優勢，下面的段落解釋了每一種Cassandra’s compaction 策略。
盡管下面片段的開始都介紹了一個常用的推薦，但是有很多的影響因子使得compaction策略的選擇變得很復雜。
建議用在寫占比高的情況。 當Cassandra 相同大小的SSTables數目達到一個固定的數目(默認是4),STCS 開始壓縮。STCS將這些SSTables合并成一個大的SSTable。當這些大的SSTable數量增加，STCS將它們合并成更大的SSTables。在給定的時間范圍內，SSTables大小變化如下圖所示 
STCS 在寫占比高的情況下壓縮效果比較好，它將讀變得慢了，因為根據大小來合并的過程不會將數據按行進行分組，這樣使得某個特定行的多個版本更有可能分布在多個SSTables中。而且，STCS不會預期的回收刪除的數據，因為觸發壓縮的是SSTable的大小，SSTables可能增長的足夠快去合并和回收老數據。隨著最大的SSTables 大小在增加，disk需要空間同時去存儲老的SSTables和新的SSTables。在STCS壓縮的過程中可能回超過一個節點上典型大小的磁盤大小。
優勢: 寫占比高的情況壓縮很好劣勢: 可能將過期的數據保存的很久，隨著時間推移，需要的內存大小隨之增加。建議用在讀占比高的情況。
LCS減少了STCS多操作的一些問題。這種策略是通過一系列層級來工作的。首先，memtables中數據被flush到SSTables是第一層(L0)。LCS 壓縮將這些第一層的SSTables合并成更大的SSTables L1。
Leveled compaction —— 添加SSTables 
高于L1層的SSTables會被合并到一個大小大于等于sstable_size_in_md（默認值:160MB）的SSTables中。如果一個L1層的SSTable存儲的一部分數據大于L2，LCS會將L2層的SSTable移動到一個更高的等級。
許多插入操作之后的Leveled compaction 
在每個高于L0層的等級中，LCS創建相同大小的SSTables。每一層大小是上一層的10倍，因此L1層的SSTable是L0層的10倍，L2層是L0層100倍。如果L1層的壓縮結果超過了10倍，超出的SSTables就會被移到L2層。
LCS壓縮過程確保了從L1層開始的SSTables不會有重復的數據。對于許多讀，這個過程是的Cassandra能夠從一個或者二個SSTables中獲取到全部的數據。實際上，90%的都能夠滿足從一個SSTable中獲取。因為LCS不去compact L0 tables。資源敏感型的讀涉及到多個L0 SSTables的情況還是會發生。
高于L0層，LCS需要更少的磁盤空間去做壓縮——一般是SSTable大小的10倍。過時的數據回收的更頻繁，因此刪除的數據占用磁盤空間更少的比例。然而，LCS 壓縮操作使用了更多的I/O操作，增加了節點的I/O負擔。對于寫占比高的情況，使用這種策略的獲取的報酬不值得付出的I/O操作對性能造成損失的代價。在大多數情況下，配置成LCS的表的測試表明寫和壓縮I/O飽和了。
注： 當使用LCS策略bootstrapping一個新節點到集群中，Cassandra繞過了compaction操作。初始的數據被直接搬到正確的層級因為這兒沒有已有的數據，因此每一層沒有分片重復。獲取更多的信息，查看
優勢： 磁盤空間的要求容易預測。讀操作的延遲更容易預測。過時的數據回收的更及時。
劣勢: 更高的I/O使用影響操作延遲。
建議用在時間序列且設置了TTL的情況。
TWCS有點類似于簡單設置的DTCS。TWCS通過使用一系列的時間窗口將SSTables進行分組。在compaction階段，TWCS在最新的時間窗口內使用STCS去壓縮SSTables。在一個時間窗口的結束，TWCS將掉落在這個時間窗口的所有的SSTables壓縮層一個單獨的SSTable，在SSTable maximum timestamp基礎上。一旦一個時間窗口的主要壓縮完成了，這部分數據就不會再有進一步的壓縮了。這個過程結束之后SSTable開始寫入下一個時間窗口。 
如上圖所示，從上午10點到上午11點，memtables flush到100MB的SSTables中。使用STCS策略將這些SSTables壓縮到一個更大的SSTables中。在上午11點的時候，這些SSTables被合并到一個單獨的SSTable,而且不會被TWCS再進行壓縮了。在中午12點，上午11點到中午12點創建的新的SSTables被STCS進行壓縮，在這個時間窗口結束的時候，TWCS壓縮開始。注意在每個TWCS時間窗口包含不同大小的數據。
注: 可以在這里看動畫解釋。
TWCS配置有兩個主要的屬性設置
compaction_window_unit: 時間單位，用來定義窗口大小(milliseconds,seconds,hours等等)compaction_window_size: 每個窗口有多少單元(1,2,3等等)上面配置的一個例子：compaction_window_unit = ‘minutes’,compaction_window_size = 60
優勢:用作時間序列數據，為表中所有數據使用默認的TTL。比DTCS配置更簡單。
劣勢: 不適用于時間亂序的數據，因為SSTables不會繼續做壓縮，存儲會沒有邊界的增長，所以也不適用于沒有設置TTL的數據。相比較DTCS，需要更少的調優配置。
Cassandra 3.0.8/3.8 中棄用了。
DTCS類似于STCS。但是STCS壓縮事基于SSTable 大小，而DTCS是基于SSTable年紀(在一個SSTable中，每一列都標記著一個寫入的時間戳。)對于一個SSTable的年紀，DTCS使用SSTable中任意列中的oldest(最小的)時間戳。
配置DTCS時間戳
為了實現最好的壓縮策略: 1. Review 你應用的需求 2. 配置表使用最合適的策略 3. 測試壓縮策略
下面的問題基于有Cassandra 開發者和使用者的使用經驗以及上述描述的策略。
你的表處理的是時間序列的數據嗎
如果是的，你最好的選擇是TWCS 或者DTCS。想要看更多的細節，參考上面的描述。
如果你的表不是局限于時間序列的數據，選擇就變得更加復雜了。下面的問題可能會給你其他的考慮去做選擇。
你的表處理讀比寫多，或者寫多于讀嗎 LCS 是一個好的選擇，如果表處理的讀是寫的兩倍或者更多——尤其是隨機讀。如果讀的比重和寫的比重類似。LCS對性能的影響可能不值得獲取的好處。要意識到LCS可能會被一大批寫很快覆蓋掉。
表中的數據是否經常改變 LCS的一個優勢在于它將相關的數據都保持在小范圍的SSTables中，如果你的數據是不可更改的或者不是經常做upserts.STCS可以實現相同類型的分組而不用付出LCS在性能上影響。
是否需要預測讀和寫等級 LCS 保證SSTables在一個可預測的大小和數量中。例如，如果你的表讀/寫比例比較小，對于讀，期望獲得一致的服務層面的一致性，或許值得付出寫性能的犧牲去確保讀速率和延遲在一個可預測的等級。而且可以通過水平擴展（添加更多的節點）來克服掉寫入犧牲。
表會通過一個batch操作插入數據嗎 batch 寫或batch讀，STCS表現的都比LCS好。batch過程造成很少或沒有碎片，因此LCS的好處實現不了，batch操作可以通過LCS配置來覆蓋。
系統有受限的磁盤空間嗎 LCS處理磁盤空間比STCS更高高效：除了數據本身占用的空間，需要大約10%的預留空間。STCS和DTCS需要更多，在某些情況下，差不多需要50%。
系統是否到達I/O限制 LCS相比較DTCS 或者STCS，對I/O更加的敏感。換成LCS，可能需要引入更多的I/O來實現這種策略優勢。
新聞熱點
疑難解答
