layout: post
title: 針對 Redis on Flash 優化RocksDB
category: 翻譯
keywords: Databases, Benchmark, Redis, Rocksdb, Key-Value Store, SSD,NVMe


原文 Optimization of RocksDB for Redis on Flash 作者Keren Ouaknine, Oran Agra, Zvika GuzCCS Concepts Information systems → Key-value stores; Database performance evaluation; Keywords: Databases, Benchmark, Redis, Rocksdb, Key-Value Store, SSD,NVMe

[TOC]

0. 概述

RocksDB是一個熱門的KV存儲引擎，針對高速存儲設備做了優化，隨著SSD變得流行prevalent，RocksDB獲得了廣泛的使用（widespread adoption）現在在生產環境中很常見is now common in production settings，尤其是許多軟體棧嵌入RocksDB作為存儲引擎來優化訪問塊存儲。不幸的是，調優RocksDB是一個複雜的任務，涉及到許多不同依賴程度的參數involving many parameters with different degrees of dependencies. 在我們這篇論文中，一個調優好的配置可以使性能比基線配置參數的表現提高一個數量級by an order of magnitude

在這篇論文中，我們將描述我們在優化RocksDB在Redis on Flash（RoF）上的經驗。RoF是一個Redis用SSD作為內存拓展的商業實現，用以動態提高每個節點的容量效率。RoF用來存儲載內存中的熱數據，利用RocksDB存儲管理SSD上的冷數據。我們將描述我們在調優RocksDB參數使用上的方法，展示我們的的經驗和發現（包括調優結果的利弊），使用兩個雲，EC2和GCE，綜上，我們會展示如何調參RocksDB提高RoF資料庫的複製實踐11倍以上。我們希望我們的經驗能幫助到其他使用，配置和調優RocksDB來認識到RocksDB的全部潛能

1. 介紹

RocksDB是一個持久化KV存儲特定面向告訴存儲，主要是SSD而設計[1]。從LevelDB[2]分支出來，RocksDB提供了更好的性能[3]，被設計成高度靈活來方便嵌入高層應用的一個存儲引擎，事實上，許多大規模產品使用RocksDB來管理存儲，Leveraging藉助它的高性能來mitigate緩和日益增長的存儲系統的壓力[4]

不幸的是RocksDB的靈活性和高性能也有代價：調優RocksDB是一個複雜的任務牽扯到上百個參數且有varying不同程度的內部依賴，此外，「然而最近的改動使RocksDB變得越好，比起levelDB它配置就越困難」；表現差的場景太多是錯誤的配置造成的。[5]

當使用RocksDB，經常被問到的問題主要有

1. 哪些配置參數使用在哪個硬體或那種工作場景下的？
2. 這些參數的最佳optimal參數是什麼
3. 這些參數是內部獨立的嗎（比如說，調優參數a只在參數b,c,d有特定值的事後才生效）
4. 兩個不同的調優是累積cumulate正優化還是負優化？
5. 如果有的話，這些參數調優後的副作用是什麼？（last but not least最後但不是不重要）

這篇論文試圖回答這些問題，通過分享我們在RoF上優化RocksDB的經驗[6,7]–這是一個Redis內存KV存儲的一個商業拓展[8]。RoF用SSDs作為內存RAM的拓展來提供可媲美內存Redis變小的性能，在動態增長擴容數據集的時候數據也能存在一個單點伺服器上。在ROF，熱數據存儲在內存中，類數據存儲在SSDs中，由RocksDB來管理。RocksDB能處理所有ROF訪問存儲，它的性能在整個系統性能中佔了主要角色。尤其是低訪問的局部場景。因為ROF致力於提供可以媲美純內存Redis表現的性能，調優RocksDB便成了首要挑戰

在調優RocksDB適配ROF的過程中，我們分析了大量的參數並且測試了它們在不同工作模式下對性能的影響。資料庫複製，只寫模式，1:1讀寫模式。為了驗證我們配置在不同硬體環境下的健壯性，我們測試了Amazon Elastic Compute Cloud （EC2）和Google Compute Engine（GCE），綜上，我們的調優減少了複製一個節點的時間（11倍）這篇論文來描述方法，調優過程和產生效果的參數設置

在第三段，我們將描述我們的方法並解釋我們的實驗過程。第四段，我們會列出載性能上有最大正相關的參數。我們也列出了一些我們期望提高性能但實際上降低了或者you其他副作用的參數。我們相信這些信息會幫助到他人。然而我們的經驗只限於RoF場景中，我們期望相似的系統用相似的配置，希望我們的方法和結果會幫助減少調優的時間

綜上，這篇論文會有下面的產出

• 我們發表我們在EC2和GCE上 在一系列工作集下 RocksDB benchmark的結果和分析
• 我們描述了我們的條有過程，對性能有有最大影響的的參數，和最佳參數；並且
• 我們描述了調優的負面結果，或不成功，降低了性能，或有非直觀的副作用

2. 背景

這段簡要回顧下Redis，Redis on Flash，和RocksDB，描述這些系統的上層架構，提供簡要北京以幫助理解這篇論文的細節

2.1 Redis

Redis[8]是一個熱門的開源內存KV存儲提供了高級鍵值抽象，Redis是單線程的，只能在同一時間處理同一個命令。不像傳統的KV系統（鍵只是個簡單的數據類型，通常是字元串），Redis中的鍵can function as可以是複雜的數據類型，像hash，list，set，或者sorted set，furthermore此外，Redis可以使用複雜的原子操作，像是對列表的入隊出隊操作，在sorted set插入一個新值等等

事實證明，Redis的抽象和高速在許多延遲敏感的場景中特別有用，因此，Redis得到了廣泛的使用，越來越多公司在生產環境中使用redis[9]

Redis支持高可用和持久化，高可用通過主從節點同步複製來實現，故障轉移（failover），當主程序掛了，子程序能相應的接管過來。持久化可以通過以下兩種方法配置

1. 實時快照文件（RDB）
2. 使用log文件（AOF）

要注意這三種機制（AOF重寫，RDB快照，複製）都依賴於fork進程來處理一個時間點上的快照，（與此同時主程序繼續處理客戶端命令）

2.2 Redis on Flash (RoF)

像Redis這種內存資料庫通常把數據保存在內存中，資料庫快了但是也很貴，因為1內每個節點的內存容量有一定限制2每GB內存價格很貴。Redis on Flash（RoF）是一個Redis的商業拓展，用SSDs來作為內存的拓展，來高效的動態增加單個伺服器上數據集大小。RoF完全兼容Redis並實現了所有的Redis命令和特性，Rof用和Redis相同的機制來保證高可用和持久化且依賴於SSD（非易失性快閃記憶體）

RoF把熱數據保存在內存中，把冷數據持久化到固態硬碟上。它使用RocksDB作為存儲引擎，所有的固態硬碟通過RocksDB來管理，通過RocksDB介面來訪問硬碟上的值。當一個客戶端請求一個冷的數據，請求會被臨時阻塞直到designated指定的RoF I/O線程 將I/O請求提交到RocksDB，在此期間，Redis的主線程繼續處理其他客戶端的請求。

2.3 RocksDB

RocksDB[10] 是一個C++實現的開源的KV存儲，它提供get/put/delete/scan 鍵值的操作。RocksDB可以保存大量的數據，它使用sst（sorted static table）來將數據保存到NVMes，SATA SSDs，或者機械磁碟上，儘可能的降低延遲。RocksDB使用布隆過濾器來判定鍵在哪個sst文件中。為了避免隨機寫，它將數據積累到內存中的memtable中，然後一次性刷寫到硬碟中。RocksDB的文件是不可變的，一旦生成就不會繼續寫該文件。記錄不會被更新或者刪除，會生成一個新文件。這會在硬碟生成一些多餘的數據，會需要資料庫Compaction（壓縮），Compaction文件會移除冗餘的鍵值對並騰出空間，如圖所示

2.3.1 RocksDB架構

RocksDB用不同的排列組織數據，也就是層level，每層都有個目標大小，每層的目標大小增長倍數是相同的，默認是10倍，因此，如果第一層目標大小1g，那麼2,3,4層大小就是10g，100g，1000g，一個鍵可能出現在不同的層，隨著compaction，但是越新的值層越高，越舊的值層越低

RocksDBinitially首先將新的寫入存儲在內存memtable中，當memtable寫滿了，他會被轉成不可寫的memtable，並插入到落盤流程（flush pipeline）中，同時，分配一個新的memtable給後面的寫，第0層就是memtable，當第0層滿了，數據就會被compact，挪到下面的層中，compaction流程應用到所有的層，將文件從層n合併到層n+1

2.3.2 放大因子

我們通過檢測各種工作負載實驗下的吞吐量和持續時間來測評優化帶來的影響。此外，我們基於以下RocksDB定義的放大因子定義來監測副作用

• 讀放大是從硬碟中（包括數據compaction中的讀）讀的數據 比 從KV存儲中的讀的數據
• 寫放大是總的硬碟中的寫入數據 比寫入KV存儲中的數據
• 空間放大是硬碟上總的數據文件比 KV存儲的大小

2.3.3 memtier benchmark

Memtier benchmark[11]是一個benchmark工具，我們用它測量Redis流量。這是Redis實驗室[12]開發並開源的, 它可以發送各種比例的讀寫，實現了不同模式的流量模式，比如連續，隨機，高斯分佈等。這個工具維護了一個一個Redis命令的pipeline，保證當回復響應時發送一個新的請求。這個命令行工具也提供堆請求流的各種程度的控制，比如操作數，讀寫比率，工作線程數，客戶端數量，值大小等等。在每次運行的結尾，他會報告所有讀寫吞吐量的平均值和他們的延遲。

3. 方法

當我們優化RocksDB，我們首先的動機，以及我們首要的優化目標是減少ROF資料庫複製的時間。複製流程在保證主節點高可用是必要的，且包含以下兩個步驟，1從主節點服務區讀取整個數據集並發送到網路中的其他從節點，2從節點伺服器寫入數據集。一旦首次複製流程完成，所有的後續的反動都會從主節點發送到從節點來保持和主節點的同步。當（假如）主節點掛掉了，從節點會成為新的主節點，新的從節點進行複製，這樣整個資料庫保持容錯。因此，複製事件是很重要的，因為1複製流程期間由於主節點開始忙碌的讀和發送數據，整個集羣在一個低性能的狀況中，且2這會有數據丟失的風險，因為當前主節點掛了，無法進行數據複製。

使用默認的RocksDB設置，複製50g數據，內存：固態比10:90的情況下會使用whoping特別長的212分鐘。對我們的場景來說這是不可容忍的時長，應該降低到30分鐘以內，在第四段中，我們將描述我們在配置中所處的更改，降低複製時間到18分鐘。因為真正的生產環境通常單個Redis伺服器有50g左右的數據，所以我們用50g數據來實驗。

當我們首要的目的是減小資料庫複製的時間，保證我們的系統穩定性能是十分必要的imperative，因此，每次每次優化，我們都會測量四種工作負載場景

1. 只寫，寫50m key，1k value，總共50g，這個壓力代表所當前常用的資料庫規模
2. 只讀，讀10%的數據集
3. benchmark，混合讀寫，50-50
4. 資料庫複製，從主節點讀50g寫入從節點

使用這些工作模式，當我們的優化效果能顯著提高第四個並且沒有降低其他三個，我們接受這個結果。

優化流程第一步是確定瓶頸。因為資料庫複製主要是主讀從寫，我們只分析這兩種操作。我們跑兩個實驗，1主節點書全部存在內存，硬碟寫只發生在從節點（這個實驗叫純內存主節點），2所有從節點數據都存在內存，硬碟壓力都在主節點的讀上（這個實驗教純內存從節點），比較兩種場景的持續時間。幫助我們更好的優化，來達到減少複製時間的目的

我們也分析伺服器的活動：我們統計每次調優過程中的運行時間，吞吐量和延遲。我們也檢測各項系統指標，Redis和RocksDB的線程負載，IO狀態，RocksDB的每層的狀態，放大因子，放慢速度和寫停止the slowdowns, and the write stalls.這些指標幫助我們去測量評估每次優化後的副作用，選擇不使用opt-out那些降低性能的調優參數（見第四段）

硬體：我們所有的實驗都泡在EC2和GCE雲上，EC2是廣泛使用的雲伺服器，我們使用i2.8x Large 32vCPU 244GB內存，8x800GB SSD，10g加強型網路帶寬，此外我們使用的GCE用的是EC2上用不到的NVMe硬碟，同樣採用32vCPU，Intel Xeon 2.20GHz， 208g RAM，8x375gb NVMe。

4. 測試和結果

這小節描述我們的測試過程和我們在優化期間的發現。首先 4.1小節我們通過實驗詳細的介紹了顯著提高性能的兩個參數和一個本以為能提升性能卻帶來負面影響的參數，這些實驗是在EC2傷實驗的，在4.3我們重複該實驗在用NVMe的GCE上

在Throughout這節中，粗體字是RocksDB調優實驗， 引用是RocksDB配置項的名字（knob name），它們的影響列在下表中

參數parameter名字初始值改過的新值性能影響Compaction threadsmax_background_compactions86424%Slowdownslevel0_slowdown_writes_trigger122410%Stopslevel0_stop_write_trigger204010%Compaction readaheadcompaction_readhead_size02MB300%Redis IO threadsRedis IO threads864500%RAID chunkschunk512k16k68%filter for hitsoptimize_filters_for_hits017%bulk modeprepare_for_bulk_mode01500%Block sizeblock_size4k16k60%Synchronizationbytes_per_sec0MB2MB0%

4.1 在EC2 上使用SATA介面SSD

我們的RocksDB基線配置用的RocksDB4.9和幾個和默認參數不同，列在下表中

Parmetervaluememtable budget128MBLevel 0 slowdown12max open files-1WALdisabledOS bufferdisabledCachedisabled

這些在開始階段就設定了，是有一定的原因的，因為Redis on Flash用內存來緩存，所以我們禁用了RocksDB的cache，沒有必要同一個值緩存兩次。我們也禁用了OS緩衝（buffer）來保證寫在內存緩衝或者直接寫入硬碟。另外一個有效的改動是禁用WAL通過（rocksdb_writeoptions_disable_WAL），在我們這個場景下WAL有消耗但是用不到，Redis on Flash本身就保證了一致性，無需使用WAL。

4.1.1 最大化並行來消除瓶頸

開始優化，我們先降低每個線程上的負載來降低高CPU利用率high CPU utilization

我們讓RocksDB後臺縣城和Redis I/O線程一樣多，增加他們的並行性來防止他們成為瓶頸

RocksDB後臺線程主要是兩個函數，compaction 工作和刷到硬碟（flush job），在圖片2可以看到， 使用max_background_compaction從把compaction 線程8改到64，性能提高24%，我們觀察到compaction越並行化，compaction週期就越短，寫就有更高的吞吐量。我們也針對flush線程（拷貝數據從memtable寫到硬碟）做了測試，他們的並行化並沒有顯著的提高性能。

4.1.2 穩定吞吐量和延遲

下一步，我們嘗試穩定系統的性能，即（namely）在吞吐量和延遲方面降低伺服器性能差異variance。在圖三，我們能觀察到伺服器吞吐量上斷斷續續stop-start的現象，每十秒有著50k ops/sec低於10k ops/sec。這個表現也顯示出長尾延遲，即少量請求造成長時間的響應

正如預期，是compaction週期造成這種流量。這有由於level 0 文件到達上限產生的。比如說level0_slowdown_writes_trigger（默認12），當這個上限很低，compaction就會很頻繁，就會擾亂流量，就像在圖三中看到的那樣。在另一方面，如果這個上限過高，我們積累的需要compaction的量（debt）就比較多，最終會造成RocksDB觸發level0_stop_write_trigger 阻塞所有流量數秒。對於ROF，她最好有較慢但穩定的吞吐量載整個期間避免stop-start和寫阻塞，一個例子，在圖4中顯示了一個穩定的吞吐量幾乎沒有出現1-2k ops/sec的情況

我們實驗了不同的參數來調優slowdown和stop，我們觀察到了很高的吞吐量，當我們繼續提高這個參數的時候，又造成了負優化導致積累了太多的compaction debt，結果在圖5中顯示，最優的參數是slowdown=24和stop=40，給我們帶來了10%的性能提升。Compaction參數後面的值（slowdown=40，stop=60）表現出更快的複製但是在只讀工作集種對於吞吐量帶來了負面影響。在延遲的compaction的場景下，訪問時間會變長，因為bloom filter頁更大，數據也沒壓縮。

4.1.3 產生更大的吞吐量

compaction預讀選項（compaction_readahead_size）起用能在compaction過程中 讀取大的compaction inputs。默認RocksDB不使用預讀（0MB），我們使用2MB readahead進行實驗獲得了縮短三倍複製時間的效果。前文提到，compaction效率受到RocksDB吞吐量的影響。此外，我們通過調整RedisIO線程數獲得了更好的輸出，因為RocksDB的API是同步的，我們使用多路IO線程模型來提高IO並行化，我們發現提高RedisIO頁提高了讀請求的延遲，但是這個提高也帶來了memtable的爭用，導致顯著降低了寫請求的性能。

因此我們決定用單線程IO來處理寫，用其餘的IO線程來處理並發讀（一寫多讀 , one writer），這個提升提高了五倍。

因為RoF會部署在多個存儲器組合的設備來增加存儲帶寬，我們也在各種RAID設置的環境中做了實驗。RoF使用（employ）RAID-0來壓縮卷，我們在不同的壓縮塊大小的環境中測試比較了性能。見圖6，RAID 越小的塊chunk越能提高硬碟的並行程度以及性能，因此，我們將默認的512kb改成16kb，從而提高了68%。注意RocksDB調優指南建議使用大的塊大小（chunk size）[14]，我們的實驗結果正好相反，越小的塊性能越好

最後，因為RoF 把所有key和他們的位置放在了內存中，向RocksDB的請求不會錯過（miss），請求不可用的key會被ROF處理，只有請求已知在硬碟上的數據才會轉發到RocksDB子系統，因此，我們開啟了RocksDB特定designated的bloom filter配置項來優化這個場景， optimize_filters_for_hits。RocksDB實現的布隆過濾器對於每個SST文件會快速檢查搜索的key是否在該文件中存有一份，這個優化去掉了對最底層的過濾，因為一旦請求來到這層，那值肯定就在這層。這個優化會對複製性能帶來7%的提升。

4.1.4 讀速度

當複製一個資料庫，主節點發送數據集的一個副本給從節點，主節點需要把硬碟和內存中的值都讀出來。這有兩種方法來從硬碟中讀數據，第一種就是使用RocksDB的迭代器來按照順序讀RocksDB資料庫文件，第二種方法就是讀那些值不在內存中的，這降低了總的讀但是增加了隨機讀。我們主要根據下面兩個條件來對這兩種方法進行取捨

1. RocksDB在兩種場景下的性能
2. 順序讀和隨機讀下的硬碟速度

圖7 畫出了在複製過程中剩餘的keys在內存中還有多少來比較這兩種方法。x軸越長表示數據在快閃記憶體硬碟中（不在內存中）的比例越高。在順序讀RocksDB數據集的場景下，所有實驗場景下，複製時間很穩定（大致保持不變stays roughly constant）（藍線），相反，隨機讀只向硬碟訪問必要的數據的方法下，複製時間隨著快閃記憶體硬碟中數據的比例而線性上升。圖中可以看到，隨機讀僅在內存中有85%數據以上的場景下表現較好，順序讀載配置了預讀後有效果提升，讀取大的塊（chunk）能加速順序讀，上述結果在不同的數據集合對象大小表現是一致的。我們採用順序讀作為複製方案。

4.2 負優化結果

許多參數我們試驗後決定不採用，不僅是因為他們沒有減少膚質是件，反而還有副作用，在這個小結，我們列舉三個調優過程中反直覺counter-intuitive或造成意外副作用的幾個場景

我們開始在（批量寫？）bulk load模式上開始調優（prepareforbulkload），開啟這個模式提高了複製時間五倍，然而，bulk load 模式有副作用，會使讀變得特別慢（prohibitively slow），因為這個模式禁止了壓縮，如果數據集不壓縮，就會有非常多的SST文件，需要非常多的讀取。我們在複製結束試著關掉bulk load啟動手動compaction來恢復資料庫可用，但是手動compaction是一個單線程處理，會花費很長時間來完成，比複製時間還要長，我們採用自動compaction，多線程，但是後續subsequent的讀仍然很慢。

意外的是，這兩種compaction最終結果不一樣，第一種花費較長時間，第二種產生較低的讀取，此外也沒有權利compaction。還記得4.1.2我們遇到的類似的compaction debt問題嗎。Bulk mode（13）是有許多不同的調優參數組成的is composed of，我們分別測試各種參數來試試能不能帶來好處。然而，禁用compaction被證明是性能提升背後的主要原因，我們就放棄了這個配置選項。

全同步在RoF不是必須，因為我們使用快閃記憶體硬碟作為內存擴展，因此，我們針對全同步消耗來進行調優，我們配置了2MB同步一次，bytes_per_sync，意外的是，我們沒觀察到任何提升，我們用dd寫數據到硬碟，我們比較了寫入50g數據不開啟同步的時間，發現性能提升了2倍，在複製實驗中沒有類似表現，我們有點困惑。我們猜測寫被緩存了（cached）因此我們看不到同步的優化（saving），但是查看meminfo我們觀察到數據沒被緩存 ，我們也看了其他設備RAID和他們的iops，也沒有降低。最後我們用strace確定確實沒有同步動作。這個反直覺的現象仍然是個謎。

最後，我們調了block_size參數，每個SST文件包含索引和他自己的block，增加塊（block）大小可以減少每個文件中索引的數量。但是塊大了讀取會變多（見2.3.2讀放大），增加了block大小也減少了內存使用，因為內存中的索引更大了（？），默認的塊大小是4kb，當我們block調到16kb，我們觀察到了60%的降低，不像其他參數可以在運行時動態調節，block大小修改不能撤銷（編譯進去的）所以我們觀測到了在讀性能上的負面影響後我們就結束了這個調優。

4.3 在GCE NVMe SSD上的實驗

在EC2上的調優經驗也幫助我們在GCE上進行試驗，首先我們調整RAID優化，我們把之前的在chunk 大小上的經驗直接搬過來（a sweep of），證實了16kb確實是最優參數，能將複製時間提高41%。

默認的level0_slowdown(12)和stop（20）延遲寫是不必要的。當我們達到12個文件後，延遲寫在吞吐量上面的表現非常明顯，從60k降到600 ops/sec 直到compaction工作結束才恢復。為了避免系統的這種stop-start現象，我們增加了這兩個參數到20 24，觀察到性能提升了15%（類似EC2）

此外，我們加上了其他調優，比如優化filter等等，我們也加了RocksDB compaction線程和Redis IO線程，配置了一個寫者 (one writer)，增加了數據預讀。這些改動累積效果，複製時間縮短到12分50秒，相同的數據規模在EC2上同樣參數配置用了18分鐘。不過硬體參數也不同，SATA-SSD和NVMe SSD，我們認為GCE本應該有更快的複製時間

5. 相關工作

雖然也有其他可用的存儲引擎[15,16,17],RocksDB有著更好的性能而得到了廣泛的使用，RocksDB調優指南[18]提供了RocksDB[10]基本的配置指引，也是我們測試中的基本配置。在我們的這篇論文中，更進一步的調優帶來了可觀considerably的性能提升（我們的例子中是11倍）

krishnamoorthy和Choi[19]做了在NVMe SSD上調優RocksDB的工作，據我們所知，這是最接近我們論文展示的工作，然而，他們的分析是在RocksDB壓力測試場景下的，我們的優化是在工業實踐（用RocksDB做後端引擎）場景下的。所以，兩者的調優過程和結論也有所不同。

類似Redis on Flash，也有一些Redis的拓展使用了快閃記憶體硬碟為Redis提供拓展能力，在Intel的項目[20]，也是Redis分支，依賴SSD來提供持久化，動機是消除eliminate硬碟備份寫硬碟的同步代價而採用了AOF策略，如果有個節點故障，機器會通過固態硬碟上的數據來修復。這個方法不能用在雲設備上，因為機器不能復用/修復。Redis原生硬碟存儲（Naive-Disk-Store）使用LMDB[17]來管理硬碟上的數據，數據是週期性的刷到硬碟上的，如果一旦故障僅會丟失最後一次沒刷盤的數據。它不會把key存到內存中也不支持持久化複製，定期刪除，scan。

6. 結論

隨著使用RocksDB作為存儲引擎的應用越來越多，Rocksdb也是選型存儲引擎的首選，然而，靈活和高性能是有代價的，調優RocksDB是個複雜的工作，在我們這篇論文中，調優好的配置要比基本配置表現好出一個數量級

在這篇論文中我們使用Redis on Flash 一個熱門Redis KV存儲的一個商業拓展，作為調優RocksDB的研究用例，我們描述條有方法，調優過程，和RocksDB設置上的改動點，使得RoF性能提升11倍以上，實驗還展示了可能會導致負面效果或預料之外副作用的的配置。然而不同的使用場景有不同的最優配置，我們希望我們的經驗會幫助其他人來優化RocksDB，提高新更能，減少研發時間。高度調優的Rocksdb的性能提升絕對值得付出這些工作。

7. 援引

[1] Siying Dong. RocksDB: Key-Value Store Optimized for

Flash-Based SSD.https://www.youtube.com/watch?v=xbR0epinnqo.

[2] RocksDB and LevelDB.

http://rocksdb.org/blog/2016/01/29/compaction_pri.html.

[3] Paul Dix. Benchmarking LevelDB vs RocksDB. https:

//www.influxdata.com/benchmarking-leveldb-vs-rocksdbvs-hyperleveldb-vs-lmdb-performance-for-influxdb/.

[4] RocksDB users. https:

//github.com/facebook/rocksdb/blob/master/USERS.md.

[5] Mark Callaghan blog. http://smalldatum.blogspot.co.il/2014/07/benchmarking-leveldb-family.html, July 7, 2014.

[6] Redis on Flash documentation. Quick Setup of a Redis on Flash Database.

[7] Redis on Flash. RLEC 4.3 - Faster, More Secure and Cost Effective | Redis Labs.

[8] Redis. Redis.

[9] Redis Users. techstacks.io.

[10] RocksDB website. http://rocksdb.org/.

[11] Memtier benchmark.

https://redislabs.com/blog/memtier_benchmark-a-highthroughput-benchmarking-tool-for-redis-memcached.

[12] Redis Labs. Redis Labs | Database for the Instant Experience.

[13] Gartner. Magic Quadrant. https://www.gartner.com/doc/reprints?id=1-2G2O5FC&ct=150519.

[14] RocksDB FAQ.facebook/rocksdb.

[15] Kyoto Cabinet. Kyoto Cabinet: a straightforward implementation of DBM.

[16] LevelDB. LevelDB.org.

[17] Lightning Memory Mapped Database.lmdb - lmdb 0.94 documentation.

[18] Facebook. RocksDB Tuning Guide. facebook/rocksdb.

[19] Praveen Krishnamoorthy and Choi Changho. Fine-tuning RocksDB for NVMe SSD. https://www.percona.com/live/data-performance-conference2016/sites/default/files/slides/Percona_RocksDB_v1.3.pdf.

[20] Intel. Redis with persistent memory. pmem/redis.

[21] Redis Naive Disk Storage.https://github.com/mpalmer/redis/blob/nds-2.6.redis

推薦閱讀：

相關文章