Nebula Graph 的 KV 存储分离原理和性能测评
本文首發于 Nebula Graph Community 公眾號
1. 概述
過去十年，圖計算無論在學術界還是工業界熱度持續升高。相伴而來的是，全世界的數據正以幾何級數形式增長。在這種情況下，對于數據的存儲和查詢的要求越來越高。因此，圖數據庫也在這個背景下引起了足夠的重視。根據世界知名的數據庫排名網站 DB-Engines.com 的統計，圖數據庫至 2013 年以來，一直是“增速最快”的數據庫類別。雖然相比關系型數據庫，圖數據庫的占比還是很小。但由于具有更加 graph native 的數據形式，以及針對性的關系查詢優化，圖數據庫已經成為了關系型數據庫無法替代的數據庫類型。此外，隨著數據量的持續爆炸性上漲，人們對于數據之間的關系也越來越重視。人們希望通過挖掘數據之間的關系，來獲取商業上的成功，以及獲得更多人類社會的知識。因此我們相信，天生為存儲數據關系和數據挖掘而優化的圖數據庫會在數據庫中持續保持高速增長。
圖1: 關系型和圖數據庫在關系查詢的性能對比
圖1 顯示了查詢數據之間多跳關系（圖的深度優先或者廣度優先搜索）的關系型數據庫和圖數據庫的性能差異。（這里我們雖然以 Neo4j 為例，但 Nebula 無論在性能還是在可擴展性上都是優于 Neo4j 的）。
雖然關系查詢性能勝于關系型數據庫，當前主流的圖數據庫在多跳查詢（高深度圖遍歷）上的性能還是災難性的。尤其對于大數據量， 分布式系統來說更是如此。而存儲的性能又往往是數據庫性能的瓶頸。在我們的簡單測試（單機，1GB/s SSD， 73GB 數據）中，簡單的三跳查詢并返回屬性 P50 延遲可以達到 3.3s，P99 延遲可以達到 9.0s。而且隨著查詢語句的復雜度提升，系統很可能變得不可用。
目前，Nebula 使用 RocksDB 作為底層存儲引擎。我們知道圖數據庫的主要 workload 是對于關系的多層次遍歷，一次查詢往往需要多次對存儲引擎的讀取。因此對 RocksDB 一次讀取的性能劣勢在圖查詢中會被多次放大。這也是為什么多跳圖查詢延遲巨大。反過來說，對于單次 RocksDB 查詢的性能提升也將在 Nebula 查詢中被多次放大。因此如何優化 RocksDB，使得 RocksDB 適配圖數據庫的 workload，成為優化存儲端性能的重中之重。
RocksDB 的核心數據結構是 LSM-Tree。所有 key 和 value 都存于 LSM-Tree 中。但這種設計有一個缺點：由于 value 往往比 key 大，LSM-Tree 中大部分的空間是用來存 value 的。一旦 value 特別大，那么 LSM-Tree 會需要更深的 level 來存儲數據。而 LSM-Tree 的讀寫性能是直接跟層數負相關的。層數越深，可能帶來的讀寫放大就越多，性能也就越差。因此我們提出使用 KV 分離來存儲圖數據庫：將值較小的數據存在 LSM-Tree 中，而將值較大的數據存在 log 中。這樣操作，大 value 并不存在 LSM-Tree 中，LSM-Tree 的高度會降低。而 RocksDB 相鄰兩層的 size 是 10 倍關系，即便減少一層 LSM-Tree 高度，也能大大增加 Cache 的可能性，從而提高讀性能。此外，KV 分離帶來的讀寫放大的減少也能加快讀寫速度。
在我們的測試中，我們發現 KV 分離對于圖查詢的性能具有巨大提升。對于小 value 的查詢延遲降低可以高達 80.7%。而對于大 value 的查詢，延遲降低相對較少，但也可以達到 52.5%。考慮到大部分大 value 的數據是冷數據而且占絕大多數的，因此總體性能的提升將更接近于對于小 value 的查詢。
值得注意的是，Nebula 從 3.0.0 版本開始已經提供了 KV 分離的功能。用戶可以通過 nebula-storaged 的配置文件來配置 KV 分離的功能。
2. KV 分離技術
上文說到 LSM-Tree 存在比較嚴重的讀寫放大問題。這是因為每次 Compaction 都需要同時對 key 和 value 進行 Compaction，而且這個放大率會隨著數據庫的數據增加而增大（對于 100GB 數據，寫放大可以達到 300 多倍）。這對 LevelDB 來說也許不是那么嚴重的問題。因為 LevelDB 是為 HDD 設計的。對 HDD 來說，隨機讀寫性能遠遠低于順序讀寫（1,000 倍差距）。只要讀寫放大比例小于 1,000 就是合算的。但對于 SSD 來說，隨機和順序讀寫性能差距沒那么大，尤其對于 NVMe SSD（如下圖）。
圖2. NVMe SSD 性能
因此大量的讀寫放大會浪費帶寬。于是，Lu. etc 在 2016 年提出了 KV 分離的存儲結構： https://www.usenix.org/system/files/conference/fast16/fast16-papers-lu.pdf。論文的核心思想是比較小的 key 存在 LSM-Tree 中，value 放在 log 中。這樣 LSM-Tree 每一層可以存更多的 KV，同樣的數據量，層級會比較低，這樣可以提高讀寫的效率。對于寫沒那么多的 workload，Compaction 時省下來的寫帶寬可也可以降低讀的 P99 延遲。當然這個設計也有一定的問題。相比 SSTable 中的 KV 絕對有序而言，log 中的 value 只是相對有序（按照 key 排序）。因為每次插入數據都是 append 到 log 中，必須依賴后續的 Garbage Collection（下簡稱 GC）來使 log 中的數據也變得相對有序。因此對于大規模的范圍查詢 Range Query，并且是小 value（64B），性能可能會差。
目前 RocksDB 的最新版本已經支持了 KV 分離：http://rocksdb.org/blog/2021/05/26/integrated-Blob-db.html。它將分離后的 value 存到了多個 log 上（.blob file）。每一個 SST 對應多個 Blob。Blob 的 GC 是在 SST Compaction 的時候觸發。
3. Nebula KV 分離性能測試
在這里，我們測試 Nebula 在不同的數據和查詢下的 KV 分離的性能，包括：
3.1 測試環境
本次測試主要使用了一臺物理機。Node A 具有 56 核 Intel? Xeon? CPU E5-2697 v3 @ 2.60GHz，256GB 內存，圖數據存儲在 1.5 TB 的 NVMe SSD 上。
測試數據都是由 LDBC（https://github.com/ldbc）生成。為了測試 KV 分離效果，我們準備了兩類數據：一類全是小 value，另一類是大 value 和小 value 混合。對于前者，我們使用默認 LDBC 的設置，如圖 3。
圖3. LDBC 默認 Text 和 Comment value 設置
對于后者我們將 text、comment、large post 和 large comment 全部設置成 min size 4KB、max size 64KB。這是屬于大 value，由 REPLY_OF 邊連接。我們保留 Person 的默認設置，屬于小 value，由 KNOW 邊連接，其 value 的具體分布參考表 1。
| 0-32B | 2.67% |
| 32B-128B | 0.04% |
| 128B-160B | 96.60% |
| 160B-192B | 0.69% |
表1. Person value 大小分布
據此我們準備了兩個數據，見表2。
| Data1 | < 200B Person | ||
| Default for others | 37GB | scale * 30 | |
| Data2 | <200B Person | ||
| Min 4K, Max 64K for others | 73GB | scale * 3 |
表2. 數據集詳情
這里我們使用 nebula-bench 中不同的測試語句，包括 1 跳、2 跳、3 跳查詢和 FindShortestPath（測試中縮寫 FSP）、INSERT 語句。此外，我們還添加了 5 跳查詢來測試更極限的性能情況。同一測試重復執行 5 次，后文將使用 NoSep 和 Sep 分別指代未配置 KV 分離和配置了 KV 分離。
3.2 KV 分離后 RocksDB 的內部結構
我們分別使用 KV 分離和不分離的方式導入數據集 Data2。對于 KV 分離的設置，我們設置大于某個閾值的數據存在 Blob 中（分離），小于閾值的數據存在 SST 中（不分離）。這里以 100B 閾值為例。
對于 NoSep，導入數據后，一共有 13GB 數據，217 個 SST。對于 Sep，導入數據后，一共有 16GB 數據，39 個 SST。圖 4. 和圖 5. 分別顯示 NoSep 和 Sep 的 LSM-Tree 內部情況。
圖 4. KV 不分離 RocksDB 有三層 LSM-Tree
圖 5. KV 分離后 RocksDB 有兩層 LSM-Tree
可以看到 NoSep 使用了 3 層 LSM-Tree，而 Sep 只有兩層。考慮到我們配置 RocksDB L1 為 256MB， L2 為 2.5GB，L3 為 25GB。單單層數從 3 層減少到 2 層可能就是能否將所有數據存入 Cache 的區別。
3.3 拓撲查詢的性能
對于圖的查詢既有屬性查詢也有拓撲查詢。首先，我們測試 KV 分離對于非值（拓撲）查詢的影響。拓撲查詢對 RocksDB 不會調用 GET 操作，而只有 SEEK 和 NEXT 操作。而對于拓撲查詢，又分為對于 KNOW 關系和 REPLY_OF 關系進行 walk。值得注意的是，雖然這兩種關系（邊）所連接的點的屬性大小存在很大差別，但拓撲查詢只涉及邊。我們將同一份 Data2 數據集分別導入到 KV 分離和不分離的 Nebula 中，并且從同一個原始數據中獲取查詢語句進行查詢。
查詢性能跟 Cache 機制有關。RocksDB 主要使用了自身的 LRU Cache，也叫 Block Cache，和 OS 的 Page Cache。其中 Block Cache 儲存的是解壓縮后的 Block，而 Page Cache 儲存的是壓縮后的 Block。Block Cache 雖然效率更高，但是空間使用率低。在生產環境中，我們推薦將 Block Cache 大小設置為 1/3 內存。本次測試將分別比較不使用 Block Cache（只有 OS Page Cache），1/3內存（80GB）大小的 Block Cache + OS Page Cache，和 direct I/O （既沒有 Block Cache，也沒有 OS Page Cache）各自的性能。
圖 6. KV 分離對于 KNOW 關系拓撲查詢的性能影響
| Go 1 Step | 0.9% | 1.0% | 0.7% |
| Go 2 Step | 4.7% | 5.3% | 5.1% |
| Go 3 Step | 15.9% | 21.4% | 9.4% |
| Go 5 Step | 11.2% | 12.2% | 7.9% |
| FSP | 6.8% | 10.1% | 2.7% |
表 3a. KV 分離對于 KNOW 關系拓撲查詢的延遲減少（Page Cache）
| Go 1 Step | 1.2% | 1.1% | 1.5% |
| Go 2 Step | 8.3% | 10.0% | 7.1% |
| Go 3 Step | 26.8% | 43.2% | 29.6% |
| Go 5 Step | 31.7% | 38.3% | 21.6% |
| FSP | 8.6% | 12.4% | 3.9% |
表 3b. KV 分離對于 KNOW 關系拓撲查詢的延遲減少（Block Cache + Page Cache）
| Go 1 Step | 1.1% | 1.0% | 1.8% |
| Go 2 Step | 14.3% | 15.0% | 12.4% |
| Go 3 Step | 17.4% | 17.8% | 16.0% |
| Go 5 Step | 10.5% | 3.0% | 17.2% |
| FSP | 15.8% | 21.7% | -3.6% |
表 3c. KV 分離對于 KNOW 關系拓撲查詢的延遲減少（direct I/O）
圖6 和表 3顯示了 Nebula 對于 KNOW 關系查詢的測試結果。針對數據集 Data2 的數據分布特性，我們測試了分別以 100B 和 4KB 作為 KV 分離的閾值。可以很明顯地看到 KV 分離極大地提升了 Data2 的查詢性能。對于圖遍歷深度較淺的查詢（ Go 1 Step），KV 分離的延遲降低比較少，在 100B 閾值下的 P50 延遲降低大約在 1%。但對于更深的查詢，其提升就非常明顯了，比如：對于 Go 3 Step，在使用大 Block Cache 下（表 3.b），在 100B 閾值下 P50 延遲降低可以達到 43.2%。而尋找最短路徑對于圖的遍歷的深度往往在 1 跳和多跳查詢之間，因此其性能提升是多跳查詢的平均。
注意這里 KV 分離在 Go 5 Step 并沒有進一步的性能提升，可能因為對于更深的遍歷，其主要瓶頸不在存儲。相比于 KV 分離之于不分離的性能提升，100B 和 4KB 的閾值區別并不大。因此在表 3 中，我們以 100B 閾值為例展示了具體的延遲減少百分比。
另外，對于有 Cache 的情況下（Block 或 Page Cache），所有數據都可以緩存，此時 KV 分離性能比不分離性能更好，也說明 KV 分離后內存中的數據訪問效率更高。具體的原因可能是 SST 本來就不是內存訪問的最佳數據結構。因此小 LSM-Tree 相比大 LSM-Tree 帶來的性能提升會比較明顯。
圖 7. KV 分離對于 REPLY_OF 拓撲查詢的性能 （注意這里 Go 3 Step 和 Go 5 Step 之間性能并沒有多大差別。這是因為 Go 5 step 只有 0.6% 的查詢返回了非 0 結果。因此 Go 5 Step 本質上不會比 Go 3 Step 多 walk 多少邊。）
| Go 1 Step | 1.1% | 1.8% | 0.1% |
| Go 2 Step | 1.2% | 1.3% | 1.1% |
| Go 3 Step | 1.2% | 1.4% | 0.8% |
| Go 5 Step | 1.1% | 1.2% | 1.0% |
| FSP | 6.4% | 9.1% | 3.3% |
表 4a. KV 分離對于 REPLY_OF 關系拓撲查詢的延遲減少（Page Cache）
| Go 1 Step | 0.8% | 0.9% | 0.2% |
| Go 2 Step | 1.2% | 1.4% | 0.2% |
| Go 3 Step | 1.3% | 1.6% | 0.4% |
| Go 5 Step | 1.3% | 1.6% | 0.7% |
| FSP | 5.4% | 8.0% | 2.4% |
表 4b. KV 分離對于 REPLY_OF 關系拓撲查詢的延遲減少（Block Cache + Page Cache）
| Go 1 Step | 1.2% | 1.4% | 0.2% |
| Go 2 Step | 1.3% | 1.7% | 0.0% |
| Go 3 Step | 1.3% | 1.5% | 0.6% |
| Go 5 Step | 1.8% | 2.0% | 0.7% |
| FSP | 9.1% | 13.3% | -4.3% |
表 4c. KV 分離對于 REPLY_OF 關系拓撲查詢的延遲減少（direct I/O）
圖 7. 和表 4. 展示了對于 REPLY_OF 關系的查詢結果。此時，可以看到 KV 分離雖然性能提升效果不明顯，但也是有確定的提升的。注意這里 Go 3 Step 和 Go 5 Step 之間性能并沒有多大差別。這是因為 Go 5 Step 只有 0.6% 的查詢返回了非 0 結果。因此 Go 5 Step 本質上不會比 Go 3 Step 多 walk 多少邊。注意這里由于性能差別不大，我們只展示了 4K 閾值下 KV 分離和不分離的對比情況。
3.4 點的屬性查詢性能
在這部分，我們來測試 KV 分離對于屬性（值）查詢的性能影響。按照 KV 分離的理論，傳統的 LSM-Tree 對于讀性能的影響主要來源于讀放大。而讀放大要通過 GET 操作才能體現得明顯。而屬性查詢恰好能體現讀放大的影響。
首先，我們測試對于點的屬性查詢。同上，測試分為對于小 value 和大 value 進行 walk。
圖 8. KV 分離對于小 value 屬性查詢的性能
| Go 1 Step | 36.2% | 37.6% | 32.4% |
| Go 2 Step | 34.0% | 35.5% | 28.6% |
| Go 3 Step | 37.4% | 40.3% | 29.3% |
| Go 5 Step | 16.3% | 19.0% | 14.3% |
表 5a. KV 分離對于小 value 屬性查詢的延遲減少（Page Cache）
| Go 1 Step | 35.6% | 37.8% | 31.6% |
| Go 2 Step | 29.6% | 31.1% | 23.4% |
| Go 3 Step | 33.8% | 36.0% | 25.4% |
| Go 5 Step | 19.1% | 33.5% | 9.9% |
表 5b. KV 分離對于小 value 屬性查詢的延遲減少（Block Cache + Page Cache）
| Go 1 Step | 78.6% | 78.9% | 77.9% |
| Go 2 Step | 80.8% | 81.3% | 78.7% |
| Go 3 Step | 75.8% | 77.3% | 72.1% |
| Go 5 Step | 53.2% | 46.3% | 37.5% |
表 5c. KV 分離對于小 value 屬性查詢的延遲減少（direct I/O）
圖 8 和表 5 顯示了 KV 分離對于小 value 進行 walk 并返回值（屬性）查詢的性能影響。這是通過對 KNOW 關系進行查詢并返回節點屬性實現的。我們可以看到以 4K 為閾值情況下，KV 分離 P50 延遲降低可以達到 81.3%，而 P99 延遲降低可以達到 78.7%。這主要得益于對于 KV 分離對于點查詢的性能提升巨大，這也和 RocksDB 對于 KV 分離的測試結果一致。另外，可以看到 KV 分離對于 direct I/O 的性能提升最大。這是因為 KV 分離對讀性能的提升主要來源于讀放大的減少和 Cache 命中率的提升。但由于磁盤 I/O 性能遠小于內存訪問，所以讀放大的減小對于性能提升更加明顯。而讀放大只在產生 I/O 的情況下才會產生。所以這里 direct I/O 主要是體現讀放大的減小對于性能的提升。
圖 9. KV 分離對于大 value 屬性查詢的性能
| Go 1 Step | 7.1% | 6.7% | 8.8% |
| Go 2 Step | 3.8% | 4.2% | 3.8% |
| Go 3 Step | 1.9% | 1.8% | 1.6% |
| Go 5 Step | 0.5% | 1.0% | -0.6% |
表 6a. KV 分離對于大 value 屬性查詢的延遲減少（Page Cache）
| Go 1 Step | 0.7% | 0.5% | 1.3% |
| Go 2 Step | 0.9% | 0.9% | 1.0% |
| Go 3 Step | 1.5% | 1.6% | 1.6% |
| Go 5 Step | 1.4% | 1.7% | 1.0% |
表 6b. KV 分離對于大 value 屬性查詢的延遲減少（Block Cache + Page Cache）
| Go 1 Step | 52.3% | 52.5% | 51.1% |
| Go 2 Step | 26.4% | 22.9% | 24.3% |
| Go 3 Step | 7.6% | 1.0% | 16.8% |
| Go 5 Step | 2.4% | 2.4% | 3.8% |
表 6c. KV 分離對于大 value 屬性查詢的延遲減少（direct I/O）
圖 9 和表 6 通過對 REPLY_OF 關系進行 walk 并返回終點 value，體現了 KV 分離對于讀取大 value 性能的影響。此時 KV 分離在比較淺的遍歷的時候，性能提高反而較大，而對于較深的遍歷沒有太多影響。這主要是因為對于 REPLY_OF 關系，99.99% 的查詢存在 1 跳及以上關系、只有 50.7 %的數據之間存在 2 跳及以上關系、只有 16.8% 的數據之間存在 3 跳及以上關系。因此隨著查詢跳數上升，需要實際去 GET 屬性的查詢比例反而減少。因此對于實際 GET property 比例最高的查詢 Go 1 Step，KV 分離對于其性能提升反而最多。而對于其他查詢，KV 分離對于性能的影響會更接近于 3.3 節中對于 REPLY_OF 關系的拓撲查詢。
3.5 邊的屬性查詢性能
再來測試對于邊屬性的查詢性能。根據之前的測試結果，我們知道 REPLY_OF 邊連接的深度比較淺，較深的查詢也會退化成淺查詢。因此，這里我們僅關注對于 KNOW 關系的邊屬性查詢。
圖 10. KV 分離對于邊屬性查詢的性能影響
| Go 1 Step | 0.5% | 0.6% | -0.5% |
| Go 2 Step | 3.3% | 4.2% | 2.8% |
| Go 3 Step | 11.4% | 25.8% | 1.2% |
| Go 5 Step | 15.0% | 24.3% | 6.6% |
表 7a. KV 分離對于邊屬性查詢的延遲減少（Page Cache）
| Go 1 Step | 0.0% | 0.2% | 0.1% |
| Go 2 Step | -0.3% | -0.1% | -0.6% |
| Go 3 Step | 4.2% | 13.0% | -1.7% |
| Go 5 Step | 0.7% | 4.7% | -0.1% |
表 7b. KV 分離對于邊屬性查詢的延遲減少（Block Cache + Page Cache）
| Go 1 Step | 0.5% | 0.2% | 1.4% |
| Go 2 Step | 4.0% | 4.9% | 2.1% |
| Go 3 Step | 12.5% | 12.9% | 10.2% |
| Go 5 Step | 6.9% | 1.2% | 13.4% |
表 7c. KV 分離對于邊屬性查詢的延遲減少（direct I/O）
圖 10 和表 7 顯示了測試結果。可以看出此種情況下 KV 分離的性能提升大大降低。因為在 LDBC 數據集中，邊上的屬性只有 creationDate，小于測試中 KV 分離的閾值 100B。因此無論是否使用 KV 分離，邊上的屬性都存儲在 LSM-Tree 上。只是 KV 分離后，LSM-Tree 的大小變小，Cache 效率更高。因此，KV 分離對于 LDBC 數據集中的邊上屬性查詢性能提升較小。
3.6 數據插入的性能
這里，我們也測試下 KV 分離對于數據插入的性能影響。由于 Cache 對于 RocksDB 的 PUT 的性能影響不大，這里只測試了只有 OS Page Cache 的場景。我們繼續使用數據集 Data2，并且每次插入查詢都運行 10 分鐘，以確保 Compaction 會被觸發。
圖 11. KV 分離對數據插入的性能影響
圖 11 顯示了數據插入性能。一個是插入 Person 數據，屬于小 value。另一個是插入 Comment 數據 （至少4KB），屬于大 value。我們可以看到 KV 分離對于插入大 value 具有比較明顯的性能提升。其收益主要來自于更少的 Compaction。而對于小 value 的插入，由 PUT 導致的寫放大在 RocksDB 中并不明顯。但另一方面，在每一個 KV Flush 到 L0 的時候，KV 分離帶來的額外一次寫的開銷（需要同時寫 SST 和 Blob）卻比較明顯。因此，在 value 比較小的時候，KV 分離的寫性能會受影響。
3.7 如果我的數據集全是小 Value？
我們已經知道如果數據集中有大 value，那么無論是拓撲查詢還是值查詢，KV 分離都能帶來巨大的性能提升。那如果沒有大 value 呢？是否存在副作用？
這一節我們測試了 KV 分離對于沒有大 value 情況的性能影響。
首先需要注意的是，KV 分離并不是在任何時候都能對 RocksDB 帶來性能提升。尤其在小 value 情況下， Range Query 性能是會變差的。我們這里測試也不會覆蓋所有小 value 的情況。我們選擇使用數據集 Data1，針對默認的 LDBC 數據進行測試。
圖 12. KV 分離對小 value 拓撲結構和屬性查詢的性能影響
| Go 1 Step | 3.2% | 3.5% | 2.5% |
| Go 2 Step | 5.1% | 7.0% | -1.4% |
| Go 3 Step | 2.1% | 3.5% | 0.4% |
| FSP | 2.6% | 3.7% | 1.1% |
表 9a. 所有小 value 查詢的延遲降低
| Test | Avg reduction | P50 reduction | P99 reduction |
| Go 1 Step | 0.2% | -1.5% | 7.7% |
| Go 2 Step | 11.2% | 9.3% | 19.2% |
| Go 3 Step | 3.4% | 1.6% | 8.2% |
| FSP | 5.9% | 8.3% | 1.9% |
表 9b. 所有小 value 查詢的延遲降低
| Go 1 Step | 17.8% | 19.1% | 15.1% |
| Go 2 Step | 22.2% | 24.9% | 19.1% |
| Go 3 Step | 58.1% | 68.1% | 28.1% |
| FSP | 26.2% | 35.6% | 3.2% |
表 9c. 所有小 value 查詢的延遲降低
圖 12 展示了在全是小 value 情況下，將 KV 分離的閾值置成 100B 的性能。其中，在 Go 1 Step、Go 2 Step、Go 3 Step 中，我們提取了目標節點的屬性，是屬性查詢，FindShortestPath 是不返回值的拓撲查詢。可以看到，雖然性能提升不如數據集 Data2，但是延遲也是有降低的，在 direct I/O 情況下尤為明顯。注意，我們這里沒有展示 Go 5 Step，因為 Go 5 Step 的壓力測試中出現了超時情況，因此測試結果不準確。
總之，我們證明了無論是大 value 還是小 value，拓撲查詢還是值查詢，KV 分離都是能帶來性能提升的。
4. 結論
我們提出使用 KV 分離來存儲圖數據庫：將值較小的數據存在 LSM-Tree 中，而將值較大的數據存在 log 中。這樣由于大 value 并不存在 LSM-Tree中，LSM-Tree 的高度可能因此降低，增加 Cache 的可能性，從而提高讀性能。哪怕不考慮 Cache，KV 分離帶來的讀寫放大的減少也能加快讀寫速度。在我們的測試實驗中，我們發現 KV 分離對于圖查詢的性能具有巨大提升。對于小 value 的查詢延遲降低可以高達 80.7%。而對于大 value 的查詢，延遲降低相對較少，但也可以達到 52.5%。考慮到大部分大 value 的數據是冷而且占絕大多數的，因此總體性能的提升將更接近于對于小 value 的查詢。從 Nebula Graph 3.0.0版本開始，可以通過 nebula-storaged 的配置文件來配置 KV 分離的功能。
交流圖數據庫技術？加入 Nebula 交流群請先填寫下你的 Nebula 名片，Nebula 小助手會拉你進群~~
關注公眾號
總結
以上是生活随笔為你收集整理的Nebula Graph 的 KV 存储分离原理和性能测评的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： cmd命令行进入D盘的方法
- 下一篇： 钥匙密的7002osiv