- cassandra數(shù)據(jù)庫存儲結構_ cassandra數(shù)據(jù)庫數(shù)據(jù)的寫入，讀取和刪除

數(shù)據(jù)的讀取

Cassandra 的寫的性能要好于讀的性能，為何寫的性能要比讀好很多呢？原因是，Cassandra 的設計原則就是充分讓寫的速度更快、更方便而犧牲了讀的性能。事實也的確如此，僅僅看 Cassandra 的數(shù)據(jù)的存儲形式就能發(fā)現(xiàn)，首先是寫到 Memtable 中，然后將 Memtable 中數(shù)據(jù)刷到磁盤中，而且都是順序保存的不檢查數(shù)據(jù)的唯一性，而且是只寫不刪（刪除規(guī)則在后面介紹），最后才將順序結構的多個 SSTable 文件合并。這每一步難道不是讓 Cassandra 寫的更快。這個設計想想對讀會有什么影響。首先，數(shù)據(jù)結構的復雜性，Memtable 中和 SSTable 中數(shù)據(jù)結構肯定不同，但是返回給用戶的肯定是一樣的，這必然會要轉化。其次，數(shù)據(jù)在多個文件中，要找的數(shù)據(jù)可能在 Memtable 中，也可能在某個 SSTable 中，如果有 10 個 SSTable，那么就要在到 10 個 SSTable 中每個找一遍，雖然使用了 BloomFilter 算法可以很快判斷到底哪個 SSTable 中含有指定的 key。還有可能在 Memtable 到 SSTable 的轉化過程中，這也是要檢查一遍的，也就是數(shù)據(jù)有可能存在什么地方，就要到哪里去找一遍。還有找出來的數(shù)據(jù)可能是已經被刪除的，但也沒辦法還是要取。

下面是讀取數(shù)據(jù)的相關類圖：

圖 13. 讀取相關類圖

根據(jù)上面的類圖讀取的邏輯是，CassandraServer 創(chuàng)建 ReadCommand 對象，這個對象保存了用戶要獲取記錄的所有必須指定的條件。然后交給 weakReadLocalCallable 這個線程去到 ColumnFamilyStore 對象中去搜索數(shù)據(jù)，包括 Memtable 和 SSTable。將找到的數(shù)據(jù)組裝成 Row 返回，這樣一個查詢過程就結束了。這個查詢邏輯可以用下面的時序圖來表示：

圖 14. 查詢數(shù)據(jù)時序圖

在上圖中還一個地方要說明的是，取得 key 對應的 ColumnFamily 要至少在三個地方查詢，第一個就是 Memtable 中，第二個是 MemtablesPendingFlush，這個是將 Memtable 轉化為 SSTable 之前的一個臨時 Memtable。第三個是 SSTable。在 SSTable 中查詢最為復雜，它首先將要查詢的 key 與每個 SSTable 所對應的 Filter 做比較，這個 Filter 保存了所有這個 SSTable 文件中含有的所有 key 的 Hash 值，這個 Hsah 算法能快速判斷指定的 key 在不在這個 SSTable 中，這個 Filter 的值在全部保存在內存中，這樣能快速判斷要查詢的 key 在那個 SSTable 中。接下去就要在 SSTable 所對應的 Index 中查詢 key 所對應的位置，從前面的 Index 文件的存儲結構知道，Index 中保存了具體數(shù)據(jù)在 Data 文件中的 Offset。，拿到這個 Offset 后就可以直接到 Data 文件中取出相應的長度的字節(jié)數(shù)據(jù)，反序列化就可以達到目標的 ColumnFamily。由于 Cassandra 的存儲方式，同一個 key 所對應的值可能存在于多個 SSTable 中，所以直到查找完所有的 SSTable 文件后再與前面的兩個 Memtable 查找出來的結果合并，最終才是要查詢的值。

另外，前面所描述的是最壞的情況，也就是查詢在完全沒有緩存的情況下，當然 Cassandra 在對查詢操作也提供了多級緩存。第一級直接針對查詢結果做緩存，這個緩存的設置的配置項是 Keyspace 下面的 RowsCached。查詢的時候首先會在這個 Cache 中找。第二級 Cache 對應 SSTable 的 Index 文件，它可以直接緩存要查詢 key 所對應的索引。這個配置項同樣在 Keyspace 下面的 KeysCached 中，如果這個 Cache 能命中，將會省去 Index 文件的一次 IO 查詢。最后一級 Cache 是做磁盤文件與內存文件的 mmap，這種方式可以提高磁盤 IO 的操作效率，鑒于索引大小的限制，如果 Data 文件太大只能在 64 位機器上使用這個技術。

數(shù)據(jù)的刪除

從前面的數(shù)據(jù)寫入規(guī)則可以想象，Cassandra 要想刪除數(shù)據(jù)是一件麻煩的事，為何這樣說？理由如下：

1.數(shù)據(jù)有多處 同時還可能在多個節(jié)點都有保存。

2.數(shù)據(jù)的結構有多種 數(shù)據(jù)會寫在 CommitLog 中、Memtable 中、SSTable 中，它們的數(shù)據(jù)結構都不一樣。

4.數(shù)據(jù)時效性不一致 由于是集群，所以數(shù)據(jù)在節(jié)點之間傳輸必然有延時。

6.除了這三點之外還有其它一些難點如 SSTable 持久化數(shù)據(jù)是順序存儲的，如果刪除中間一段，那數(shù)據(jù)有如何移動，這些問題都非常棘手，如果設計不合理，性能將會非常之差。

本部分將討論 Cassandra 是如何解決這些問題的。

CassandraServer 中刪除數(shù)據(jù)的接口只有一個 remove，下面是 remove 方法的源碼：

清單 3. CassandraServer.remove

public void remove（String table， String key， ColumnPath column_path，

long timestamp， ConsistencyLevel consistency_level）{

checkLoginDone（）;

ThriftValidation.validateKey（key）;

ThriftValidation.validateColumnPathOrParent（table， column_path）;

RowMutation rm = new RowMutation（table， key）;

rm.delete（new QueryPath（column_path）， timestamp）;

doInsert（consistency_level， rm）;

}

仔細和 insert 方法比較，發(fā)現(xiàn)只有一行不同：insert 方法調用的是 rm.add 而這里是 rm.delete。那么這個 rm.delete 又做了什么事情呢？下面是 delete 方法的源碼：

清單 4. RowMutation. Delete

public void delete（QueryPath path， long timestamp）{
....

if （columnFamily == null）

columnFamily = ColumnFamily.create（table_， cfName）;

if （path.superColumnName == null && path.columnName == null）{

columnFamily.delete（localDeleteTime， timestamp）;

}else if （path.columnName == null）{

SuperColumn sc = new SuperColumn（path.superColumnName，

DatabaseDescriptor.getSubComparator（table_， cfName））;

sc.markForDeleteAt（localDeleteTime， timestamp）;

columnFamily.addColumn（sc）;

}else{

ByteBuffer bytes = ByteBuffer.allocate（4）;

bytes.putInt（localDeleteTime）;

columnFamily.addColumn（path， bytes.array（）， timestamp， true）;

}

}

這段代碼的主要邏輯就是，如果是刪除指定 Key 下的某個 Column，那么將這個 Key 所對應的 Column 的 vlaue 設置為當前系統(tǒng)時間，并將 Column 的 isMarkedForDelete 屬性設置為 TRUE，如果是要刪除這個 Key 下的所有 Column 則設置這個 ColumnFamily 的刪除時間期限屬性。然后將這個新增的一條數(shù)據(jù)按照 Insert 方法執(zhí)行下去。

這個思路現(xiàn)在已經很明顯了，它就是通過設置同一個 Key 下對應不同的數(shù)據(jù)來更新已經在 ConcurrentSkipListMap 集合中存在的數(shù)據(jù)。這種方法的確很好，它能夠達到如下目的：

1.簡化了數(shù)據(jù)的操作邏輯。將添加、修改和刪除邏輯都統(tǒng)一起來。

2.解決了前面提到的三個難點。因為它就是按照數(shù)據(jù)產生的方式，來修改數(shù)據(jù)。有點以其人之道還治其人之身的意思。

4.但是這仍然有兩個問題：這個只是修改了指定的數(shù)據(jù)，它并沒有刪除這條數(shù)據(jù)；還有就是 SSTable 是根據(jù) Memtable 中的數(shù)據(jù)保存的，很可能會出現(xiàn)不同的 SSTable 中保存相同的數(shù)據(jù)，這個又怎么解決？的確如此，Cassandra 并沒有刪除你要刪除的數(shù)據(jù)，Cassandra 只是在你查詢數(shù)據(jù)返回之前，過濾掉 isMarkedForDelete 為 TRUE 的記錄。它能夠保證你刪除的數(shù)據(jù)你不能再查到，至于什么時候真正刪除，你就不需要關心了。Cassandra 刪除數(shù)據(jù)的過程很復雜，真正刪除數(shù)據(jù)是在 SSTable 被壓縮的過程中，SSTable 壓縮的目的就是把同一個 Key 下對應的數(shù)據(jù)都統(tǒng)一到一個 SSTable 文件中，這樣就解決了同一條數(shù)據(jù)在多處的問題。壓縮的過程中 Cassandra 會根據(jù)判斷規(guī)則判定哪些數(shù)據(jù)應該被刪除。

SSTable 的壓縮

數(shù)據(jù)的壓縮實際上是數(shù)據(jù)寫入 Cassandra 的一個延伸，前面描述的數(shù)據(jù)寫入和數(shù)據(jù)的讀取都有一些限制，如：在寫的過程中，數(shù)據(jù)會不停的將一定大小的 Memtable 刷到磁盤中，這樣不停的刷，勢必會產生很多的同樣大小的 SSTable 文件，不可能這樣無限下去。同樣在讀的過程中，如果太多的 SSTable 文件必然會影響讀的效率，SSTable 越多就會越影響查詢。還有一個 Key 對應的 Column 分散在多個 SSTable 同樣也會是問題。還有我們知道 Cassandra 的刪除同樣也是一個寫操作，同樣要處理這些無效的數(shù)據(jù)。

鑒于以上問題，必然要對 SSTable 文件進行合并，合并的最終目的就是要將一個 Key 對應的所有 value 合并在一起。該組合的組合、該修改的修改，該刪除的刪除。然后將這個 Key 所對應的數(shù)據(jù)寫在 SSTable 所對應的 Data 文件的一段連續(xù)的空間上。

何時壓縮 SSTable 文件由 Cassandra 來控制，理想的 SSTable 文件個數(shù)在 4~32 個。當新增一個 SSTable 文件后 Cassandra 會計算當期的平均 SSTable 文件的大小當新增的 SSTable 大小在平均 SSTable 大小的 0.5~1.5 倍時 Cassandra 就會調用壓縮程序壓縮 SSTable 文件，導致的結果就是重新建立 Key 的索引。這個過程可以用下圖描述：

圖 15 數(shù)據(jù)壓縮

?