一、ToplingDB的分布式Compact和RocksDB的RemoteCompaction不同之處
1、可靠性不同
RocksDB 的 RemoteCompaction：還處在 Experimental 狀態(tài)。ToplingDB 的分布式 Compact：已在托管 Todis 中使用多時，得到了充分的驗證。2、可觀測性不同
RocksDB 的 RemoteCompaction：只能查看 LOG。ToplingDB：通過引擎內嵌 Web，支持分布式 Compact 在線觀測（長時間運行的演示實例）。3、分布式 Compact 實現(xiàn)方式不同
ToplingDB 的分布式 Compact：是通過將整個數(shù)據(jù)集分為多個分片，每個節(jié)點上都進行 Partial Compaction 操作來實現(xiàn)的。Partial Compaction 僅對每個分片進行壓縮，壓縮完成后，將新的分片發(fā)送給其他節(jié)點進行合并，最終形成整體的壓縮結果。RocksDB 的 Remote Compaction：是將需要壓縮的 SST 文件從源節(jié)點傳輸?shù)侥繕斯?jié)點，并在目標節(jié)點上執(zhí)行 Compaction 操作。這種方式允許在遠程節(jié)點上執(zhí)行 Compaction 操作，在網絡傳輸和數(shù)據(jù)合并方面也更加有效率。4、數(shù)據(jù)傳輸方式不同
ToplingDB 的分布式 Compact：采用點對點的方式進行數(shù)據(jù)傳輸，即將數(shù)據(jù)塊直接從一個節(jié)點傳輸?shù)搅硪粋€節(jié)點進行合并。在大規(guī)模分布式集群中，數(shù)據(jù)傳輸復雜度較高，可能會影響整個系統(tǒng)的性能。RocksDB 的 Remote Compaction：通過使用基于 TCP 的流式傳輸協(xié)議來實現(xiàn)數(shù)據(jù)傳輸。該協(xié)議允許數(shù)據(jù)在網絡上傳輸時進行壓縮和流式處理，同時減少了數(shù)據(jù)復制和存儲所需的空間。5、自適應壓縮策略不同
ToplingDB 的分布式 Compact：通過使用自適應壓縮策略來調整 Compaction 操作的執(zhí)行時間和頻率。該策略根據(jù)定期測量的讀寫負載動態(tài)調整 Compaction 的執(zhí)行時間和頻率，以最大化的優(yōu)化數(shù)據(jù)庫的性能。RocksDB 的 Remote Compaction：則采用了類似的自適應壓縮策略，但該策略還考慮了目標節(jié)點的 CPU 和磁盤 I/O 負載等因素，以最小化對目標節(jié)點的負載影響。二、RocksDB介紹
1、簡介
Rocksdb 是基于Google LevelDB研發(fā)的高性能kv持久化存儲引擎，以庫組件形式嵌入程序中，為大規(guī)模分布式應用在ssd上運行提供優(yōu)化。RocksDB不提供高層級的操作，例如備份、負載均衡、快照等，而是選擇提供工具支持將實現(xiàn)交給上層應用。正是這種高度可定制化能力，允許RocksDB對廣泛的需求和工作負載場景進行定制。
2、架構
RocksDB 是一個基于鍵值對存儲接口的存儲引擎庫，其中鍵和值是任意字節(jié)流。RocksDB 將所有數(shù)據(jù)按排序順序組織起來，常用的操作有Get(key), NewIterator(), Put(key, val), Delete(key), 和SingleDelete(key)。
RocksDB 的三個基本結構是memtable、sstfile和logfile。memtable是一種內存數(shù)據(jù)結構 – 新的寫入被插入到memtable中，并且可以選擇寫入日志文件（又名。Write Ahead Log(WAL)）。日志文件是存儲上按順序寫入的文件。當 memtable 填滿時，它會被刷新到存儲上的sstfile，并且可以安全地刪除相應的日志文件。對 sstfile 中的數(shù)據(jù)進行排序以方便查找鍵。
RocksDB使用布隆過濾器來判定鍵在哪個sst文件中。為了避免隨機寫，它將數(shù)據(jù)積累到內存中的memtable中，然后一次性刷寫到硬盤中。RocksDB的文件是不可變的，一旦生成就不會繼續(xù)寫該文件。記錄不會被更新或者刪除，會生成一個新文件。這會在硬盤生成一些多余的數(shù)據(jù)，會需要數(shù)據(jù)庫Compaction（壓縮），Compaction文件會移除冗余的鍵值對并騰出空間。
3、RocskDB和LevelDB的區(qū)別
RocskDB結構和levelDB大同小異，只是多了一些改進：
增加了column family，有了列簇的概念，可把一些相關的key存儲在一起內存中有多個immute memtalbe，可防止Leveldb中的 write stall(寫停頓)可支持多線程同時compaction，理論上多線程同時compction會比一個線程compaction要快支持TTL過期淘汰機制flush與compation分開不同的線程池來調度，并具有不同的優(yōu)先級，flush要優(yōu)于compation，這樣可以加快flush，防止stall對SSD存儲做了優(yōu)化，可以以in-memory方式運行增加了對 write ahead log（WAL）的管理機制，更方便管理WAL，WAL是binlog文件支持多種不同的compaction策略三、ToplingDB介紹
1、簡介
ToplingDB 是 較好ling 開發(fā)的 KV 存儲引擎，fork 自 RocksDB，進行了很多改造，其中一個最重要的功能是分布式 Compact，將 Compact 從 DB 結點轉移到由多個 DB 共享的計算集群中執(zhí)行，實現(xiàn)了降本增效的目的。
2、Compact 中反查 DB
在一些應用中（例如 pika、kvrocks 等等），CompactionFilter 需要反查 DB(使用 DB::Get) 獲取元數(shù)據(jù)，而在 Compact 服務中，只有 SST，沒有 DB 對象，這就使得 CompactionFilter 無法在 Compact 服務中工作。
在 Todis 中，我們通過事先把 CompactionFilter 反查會用到的元數(shù)據(jù)撈出來，然后在 Compact 服務中訪問，代替原本的 DB::Get，為此我們還對 Todis 的數(shù)據(jù)進行了針對性的編碼。
在 kvrocks 中，因為數(shù)據(jù)的組織方式，無法通過編碼在 Compact 服務中有效地代替原本的 DB::Get，所以，只有 metadata 才能支持分布式 Compact。kvrocks 中各種數(shù)據(jù)類型的 metadata 保存在一起，如果照搬 todis 的方案，事先撈數(shù)據(jù)，撈到的元數(shù)據(jù)很可能 99.9% 都是無用的元數(shù)據(jù)，例如 compact hash 數(shù)據(jù)時，事先撈出來的元數(shù)據(jù)可能大都是 string 數(shù)據(jù)。
延伸閱讀1：數(shù)據(jù)庫存儲引擎是什么
存儲引擎說白了就是如何存儲數(shù)據(jù)、如何為存儲的數(shù)據(jù)建立索引和如何更新、查詢數(shù)據(jù)等技術的實現(xiàn)方法。因為在關系數(shù)據(jù)庫中數(shù)據(jù)的存儲是以表的形式存儲的，所以存儲引擎也可以稱為表類型（即存儲和操作此表的類型）。在Oracle 和SQL Server等數(shù)據(jù)庫中只有一種存儲引擎，所有數(shù)據(jù)存儲管理機制都是一樣的。而MySql數(shù)據(jù)庫提供了多種存儲引擎。用戶可以根據(jù)不同的需求為數(shù)據(jù)表選擇不同的存儲引擎，用戶也可以根據(jù)自己的需要編寫自己的存儲引擎。
京公網安備 11010802030320號