cassandra的物理磁盤空間管理

Question

最近，我一直在從我們的新項目的角度來看待Cassandra，並從這個社區和它的wiki中學到了很多東西。但是在物理磁盤空間管理方面，我沒有發現關於如何在Cassandra中管理更新的任何信息，儘管它似乎與使用壓縮的記錄刪除管理非常相似。

假設有100條記錄與5個值的每一個，所以當所有的改變將被刷新磁盤中的所有記錄將被相鄰的書面當刪除操作完成那麼它標誌着存儲表第一和物理記錄一些時間後刪除在配置中設置或完全設置。壓實過程要求空間。

現在的問題是，在一側是模式較少有列沒有固定數量的開始，但在另一邊時，壓實過程中發生的話..它提出了相鄰的記錄在磁盤上像傳統的RDBMS速度讀取過程與RDBMS一樣簡單，因爲它們必須根據列數據類型的聲明分配固定的空間量。

但是，Cassandra如何在壓縮過程中精確地將記錄放置在磁盤上（用於更新/刪除）以加快讀取速度？

還有一個與壓縮相關的問題是，如果沒有刪除查詢，但有一個更新查詢用一些可變長度數據更新一個存在的記錄，或者全部插入一個新列，那麼壓縮如何使它在磁盤上的空間可用已經存在的數據行？

Answer 1

行和列按照排序順序存儲在SSTable中。這允許壓縮多個SSTable以輸出新的（排序的）SSTable，只有順序磁盤IO。這個新的SSTable將被輸出到磁盤上的新文件和可用空間中。這個過程不依賴於列的行數，只是按照排序順序存儲。所以是的，在所有的SSTables（即使是那些形成壓縮的行）中，行和列將按照排序順序排列在磁盤上。當你在你的問題中提示時，更新與插入沒有什麼不同 - 它們不會覆蓋磁盤上的值，而是被緩存在Memtable中，然後刷新到新的SSTable中。當新的SSTable最終與包含原始值的SSTable進行壓縮時，新值將湮滅舊值 - 即舊值不會從壓縮中輸出。時間戳用於確定哪些值是最新的。

刪除以相同的方式處理，有效地插入了「反值」或邏輯刪除。這個過程的侷限性是需要大量的空間開銷。刪除實際上是「懶惰的」，所以空間在一段時間後纔會被釋放。另外，雖然壓縮的輸出可以與輸入大小相同，但在完成新的SSTable之前，無法刪除舊的SSTable，因此可以將磁盤利用率降低至50％。

在該系統中如上所述，新值現有的密鑰可以是不同的尺寸與現有的鍵，但不填充到一些預先確定的長度，作爲新的值不被寫入在上更新的舊值，但到一個新的SSTable。