當前位置：首頁 > 人文社科 > 生活经验 >内容正文

生活经验

Rocksdb 与 TitanDb 原理分析及性能对比测试

發(fā)布時間：2023/11/27 生活经验 44 豆豆

生活随笔收集整理的這篇文章主要介紹了 Rocksdb 与 TitanDb 原理分析及性能对比测试小編覺得挺不錯的,現(xiàn)在分享給大家,幫大家做個參考.

文章目錄

- - 前言
  - Rocksdb的compaction機制
  - - compaction作用
    - compaction分類
    - - level style compaction（rocksdb 默認進行的compaction策略）
      - level 的文件存儲結(jié)構(gòu)
        compaction過程
        compaction中的level target size
      - universal style compaction
      - fifo style compaction
  - Titan相比于rocksdb的核心優(yōu)化
  - - key-value 存儲優(yōu)化
    - key-value 區(qū)分邏輯
    - 版本控制
    - GC垃圾回收機制
  - 編譯和安裝
  - - Rocksdb
    - TitanDb
  - 測試
  - - 使用rocksdb提供的接口編寫測試代碼
    - 編譯鏈接rocksdb和titandb 各自動態(tài)庫，生成二進制文件
    - 測試
  - 參考資料

前言

本文主要針對非關(guān)系型數(shù)據(jù)庫rocksdb以及在rocksdb基礎(chǔ)上所做的一些優(yōu)化的titandb做一個整體的介紹。
從他們編譯，安裝，測試以及titanDb相比于rocksdb優(yōu)化的方面進行一個整體歸納總結(jié)。

Rocksdb的compaction機制

compaction作用

compaction作為rocksdb使用LSM tree管理核心key-value數(shù)據(jù)的一種合并策略，主要是為了保證LSM tree的c0,c1…cn tree不過于冗余，影響讀性能。
關(guān)于LSM tree的介紹可以參考論文《The Log-Structured Merge-Tree (LSM-Tree)》

compaction分類

level style compaction 按層級進行合并
universal style compaction
fifo style compaction
none compaction

level style compaction（rocksdb 默認進行的compaction策略）

核心是將數(shù)據(jù)分成互不重疊的一系列固定大小（例如 2 MB）的SSTable文件，再將其分層（level）管理。

level 的文件存儲結(jié)構(gòu)

數(shù)據(jù)通過內(nèi)存寫到作為buffer的L0中，再持久化到底層的L1-Ln
當需要確認key的位置時，通過二分查找確認key所處的文件，再去具體文件中查找。
該過程會遍歷整個level集合
每一層level都有target size，compaction的目的是為了限制每一層數(shù)據(jù)，且每一層target的增加都是成倍增加

compaction過程

當level0的數(shù)據(jù)到達時，則會觸發(fā)compaction(level0_file_num_compaction_trigger 表示L0的SST文件個數(shù)達到了觸發(fā)參數(shù))到L1。操作過程會將L0中的file pick出來，以防重疊
當持續(xù)從L0 compaction到L1時，L1可能會達到target size。此時會從L1中挑選至少1個file,并與L2中的file進行合并，重新寫入L2中
當L2也達到了 target size，則和之前一樣進行file的合并，寫入到L3
并發(fā)compaction，通過 max_background_compactions控制可以進行并發(fā)compaction的個數(shù)
L0 – L1 在并發(fā)compaction的層中，該問題可能會是compaction的性能瓶頸。
優(yōu)化方式：通過設(shè)置 max_subcompactions 參數(shù)，來使用多線程方式分割 file range 進行并發(fā)compaction

compaction中的level target size

level_compaction_dynamic_level_bytes 來控制level target size的是固定還是可以動態(tài)進行調(diào)整的

level_compaction_dynamic_level_bytes = false 則表示當rocksdb開始加載時，每一層的大小都一定固定了，且運行過程中不會發(fā)生變化。
eg: rocksdb初始化參數(shù)如下
```
max_bytes_for_level_base = 268435456
level_compaction_dynamic_level_bytes = false
max_bytes_for_level_multiplier = 10 
num_levels = 3
```
則最終的rocksdb每一層的大小為
以上配置下的各個層級targe size 為：
L1: 268435456
L2: 2684354560
L3: 26843545600
level_compaction_dynamic_level_bytes = true 則表示rocksdb每一層的level大小并不是固定的，而是可以動態(tài)進行變化的。
當前模式下每一層的level size的動態(tài)調(diào)整同樣是基于QOS的思想，我們通過以上compaction的實現(xiàn)可以發(fā)現(xiàn)IO一定是通過level0 flush到底層的L1-LN,那么如果IO密集型業(yè)務下短時間內(nèi)L0增長的sst文件急劇增加且遠大于L1的大小，這個時候如果L1-LN的大小還是固定的，那么IO肯定就阻塞在了從L0-L1之間。
此時可以通過該參數(shù)讓系統(tǒng)內(nèi)部自動進行每一層的target size的調(diào)整：

eg: 原來的L1 - L3: 1G,10G,100G
此時L0短時間內(nèi)的SST文件及占用容量達到了3G，超過了L1 的1G，那么進行動態(tài)調(diào)整后（修改Level的相關(guān)配置參數(shù)）的L1-L3的大小變成了：3G，18G，108G

universal style compaction

核心實現(xiàn)同樣是通過讀放大和空間放大來降低寫放大，universal comapction

每當某個尺寸的SSTable數(shù)量達到既定個數(shù)時，合并成一個大的SSTable
通過讀放大和空間放大（合并時的臨時數(shù)據(jù)結(jié)構(gòu)占用空間較大）來最小化寫放大

這種方式的讀放大和空間放大較為嚴重，雖然寫放大在一定程度上得到了緩解（同一個sst文件并不會產(chǎn)生多次寫入），但這并不是一個可以代替level方式的策略。

fifo style compaction

fifo style compaction當文件過時時，優(yōu)先壓縮最老的文件，有點像cahce中數(shù)據(jù)的過濾。
所有的SST文件都先存儲在L0中，當L0中的文件總大小超過了CompactionOptionsFIFO::max_table_files_size，則會選擇最老的文件進行刪除，所以它的key-value的數(shù)據(jù)從來不會復寫，也就是寫放大系數(shù)一直都是1。
當然這種方式有一個非常嚴重的問題是：核心key-value數(shù)據(jù)的刪除不會告知給用戶！！

這可嚴重影響系統(tǒng) 的可靠性啊。

Titan相比于rocksdb的核心優(yōu)化

通過對Rocksdb的compaction過程的分析，我們發(fā)現(xiàn)rocksdb默認使用的level 策略存在寫放大的情況，且在正常IO的時候compaction是在后臺進行的，這個時候顯然compaction和上層IO產(chǎn)生競爭，從而影響整體的rocksdb寫性能。

此時Titan借助論文wisckey提出的key-value分離存儲的思想進行了一系列相關(guān)的優(yōu)化。

具體的優(yōu)化方面如下幾個方面：

key-value 存儲優(yōu)化

如下圖為titan中寫請求闡述的數(shù)據(jù)存放方式

在LSM管理的SST文件之下多了一種blob結(jié)構(gòu)，用來存儲value數(shù)據(jù)，具體的blobfile結(jié)構(gòu)如下

其中：

blob record 有序得保存了key-value的鍵值對，且key是從sst中進行的一份拷貝，用來和保存和value的映射，方便后續(xù)進行過時key的垃圾回收，所以這里的存儲存在一些寫放大。不過，key本身數(shù)據(jù)量比較小，并不會有太激烈的IO資源競爭。
meta block主要是為了可擴展性，來存儲了當前blobfile的一些屬性信息。
meta index則主要是記錄metablock的索引信息，方便快速查找meta block。

key-value 區(qū)分邏輯

傳統(tǒng)的rocksdb在進行創(chuàng)建sorted string table(SST)文件的時候也是通過工廠函數(shù)模式進行table文件的實例化，這里titan也是借用該設(shè)計模式進行 key-value的分離實現(xiàn)，邏輯實現(xiàn)如下：

當value-size >= min_blob_size的時候，將整個key-value存放在blobfile之中，同時創(chuàng)建一個key-index的結(jié)構(gòu)，存放在SST中，用來索引該key-value
反之，將整個key-value 存放在SST文件中

版本控制

因為多了一種數(shù)據(jù)結(jié)構(gòu)，那么在分布式存儲系統(tǒng)中，即要保證在上層應用并發(fā)add或者delete的時候仍然能夠?qū)ν馓峁┮恢滦缘脑L問服務。此時，blob file也要加入到系統(tǒng)的版本控制中，這里主要用的是Multi-version Concurrency Control (MVCC)多版本控制的思想。

通過頭尾相對的雙向鏈表進行版本文件的管理，同時設(shè)置一個versionSet的數(shù)據(jù)結(jié)構(gòu)來管理所有的文件，同時增加一個current指針，一直指向最新的version版本。通過這種版本控制的方式，達到不需要對文件加鎖，即可在并發(fā)add/delete的時候?qū)ν馓峁┮恢滦苑铡?/p>

GC垃圾回收機制

titan的GC機制主要有兩個功能進行協(xié)助：

BlobFileSizeCollector
這是一種屬性收集器，用來從對應的SST文件中SST屬性信息，最后收集到的屬性集叫做BlobFileSizeProperties。
收集前的表格和收集后的BlobFileSizeProperties表格如下：

對于SST的表格內(nèi)容(大括號里面的內(nèi)容)：第一列表示blob file ID ，第二列表示blob record在blob file中的偏移地址，第三列表示blob record的大小。
對于BlobFileSizeProperties表格內(nèi)容如下：第一列表示blob fileID,第二列表示數(shù)據(jù)的大小。
EventListener
在compaction的時候，rocksdb本身會丟掉一部分舊數(shù)據(jù)來釋放空間。同樣，在titandb中，compaction之后，titan中的部分blobfile存儲的數(shù)據(jù)可能已經(jīng)過時。此時，titan通過監(jiān)控compaction的事件來觸發(fā)自身的GC機制。
這里GC做的內(nèi)容是，通過對比compaction輸入，輸出前后的BlobFileSizeProperties表格內(nèi)容變化的情況，來決定哪一些數(shù)據(jù)可以進行丟棄。過程如下：

可以發(fā)現(xiàn)輸入輸出前后：
blobfile 1: 從size-1536變?yōu)榱藄ize:512，那么表示blobfile1可以丟棄1024大小的內(nèi)容
blobfile 2: 從size-1024 變成了沒有輸出，那么表示blobfile2可以完全丟棄
blobfile 3: 同blobfile2,也可以完全丟棄

對于每一個有效的blobfile,titan會在內(nèi)存中維護一個有效的變量來記錄當前blob file可丟棄的大小。當進行compaction的時候，變量會隨著相應的blobfile的變化進行累加（以上event listener）。當GC開始的時候，會從累計的blobfile可丟棄的變量中挑選一個最大的blobfile最為可丟棄的候選人。

為了降低寫放大，titan盡可能減少GC所造成的IO，使用可控的配置來控制GC的寫放大，當blobfile挑選出來作為可丟棄的候選者的時候需要滿足一定的大小才能夠真正被丟棄。

這里使用的GC實現(xiàn)算法入下：

從blobfile中隨機選取一部分數(shù)據(jù)A，起其size 為a
遍歷A中所有的key, 使用d 來累加所有過時的key所代表的blob record（我們上面說過blobfile的結(jié)構(gòu)，blob reocord代表的是key 對應的data的大小）
計算比例 r = d / a，如果r >= discardable_ratio，即認為當前過時的key已經(jīng)超過了一定的比例，那么就在對應的blobfile上進行GC，否則不進行GC。

綜上為titanDb在rocksdb基礎(chǔ)之上所做的一些優(yōu)化以及優(yōu)化產(chǎn)生的周邊開發(fā)。顯然，key-value的分離存儲和管理是核心優(yōu)化點，解決了rocksdb 原生compaction帶來的大量的value寫放大問題。
且通過后續(xù)對應的測試，也確實發(fā)現(xiàn)了big value場景下，寫性能確實有2-3倍的優(yōu)化提升。

后續(xù)將深入titan的核心實現(xiàn)，詳細分析研究titan的實現(xiàn)邏輯，從而應用到現(xiàn)有的業(yè)務上。

編譯和安裝

Rocksdb

基本變異過程可以參考官方給的安裝步驟，不過坑比較多，可以將一下步驟和官方給的步驟結(jié)合起來看。

確認系統(tǒng)編譯器版本gcc -v，建議版本在gcc 4.8.5以上，否則變異出來最新的代碼會缺少一些glibc的屬性信息。
這里如果發(fā)現(xiàn)系統(tǒng)gcc版本確實比較低，可以下載gcc較高版本編譯安裝一下，我這里選擇的是gcc 5.3，詳細可以參考gcc編譯安裝
這里需要注意：
- 如果個人不想安裝的gcc在系統(tǒng)默認的目錄下，且gcc版本變更為可配置的，可以在gcc源碼生成makefile的那一步進行安裝的路徑指定（否則系統(tǒng)默認會安裝到/usr/local下）：
  ./configure --prefix=/xxxx
- 當GCC 編譯安裝在指定的目錄之后可以可以通過系統(tǒng)變量加載glibc庫和我們編譯好的gcc版本
  修改當前用戶的.bashrc文件(root用戶的在/etc/.bashrc，個人用戶直接編輯~/.bashrc)
  增加如下內(nèi)容：
  export CC=/xxx/gcc-5.3/bin/gcc #makefile中的gcc的路徑
  export CXX=/xxx/gcc-5.3/bin/g++ #makefile中的g++路徑
  export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/xxx/gcc-5.3/lib64#指定glibc的庫，使用當前版本編譯器的庫

gflags安裝，gflags是谷歌提供的一些第三方庫，這里rocksdb部分功能需要使用到。
該步驟的安裝可以參考：gflags安裝

a. git clone https://github.com/gflags/gflags.git
b. cd gflags
c. mkdir build && cd build#以下DCMAKE_INSTALL_PREFIX 之后的路徑為自己想要安裝的路徑，如果有root權(quán)限且可以安裝到系統(tǒng)目錄下，那么可以不用指定prefix選項
d. cmake .. -DCMAKE_INSTALL_PREFIX=/xxx -DCMAKE_BUILD_TYPE=Release e. make && make install	#增加gflags的include 和 lib庫的路徑到系統(tǒng)庫下面，如上面未指定路徑，則系統(tǒng)默認安裝在
#/usr/local/gflags
f. 編輯當前用戶下的bashrc，添加如下內(nèi)容：
export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/xxx/gcc-5.3/lib64:/xxx/gflags/lib
export LIBRARY_PATH=$LIBRARY_PATH:/xxx/gflags/include

安裝snappy
sudo yum install snappy snappy-devel
安裝 zlib
yum install zlib zlib-devel
安裝 bzip2
yum install bzip2 bzip2-devel
安裝lz4
yum install lz4-devel

安裝zstardard

wget https://github.com/facebook/zstd/archive/v1.1.3.tar.gz
mv v1.1.3.tar.gz zstd-1.1.3.tar.gz
tar zxvf zstd-1.1.3.tar.gz
cd zstd-1.1.3
make && sudo make install

以上已經(jīng)將rocksdb以及titandb所需要的一些系統(tǒng)庫安裝完成，接下進行rocksdb的安裝

rocksdb源碼下載：
git clone https://github.com/facebook/rocksdb.git
或者直接在以上github鏈接中下載對應的源碼包即可
安裝，可以參考官方給的安裝過程rocksdb官網(wǎng)安裝過程
```
cd rocksdb 
make static_lib  #編譯rocksdb的靜態(tài)庫
cd example && make all
```
此時成功之后，可以看到expample下生成了官方所給出的一些rocksdb的測試樣例。

TitanDb

以上rocksdb的一些插件都安裝完成且成功之后，記錄下gflags是安裝路徑，接下來進行TitanDbb的安裝。Titan的官方安裝過程如下titan安裝

#titanDb屬于rocksdb 6.4版本基礎(chǔ)上的一個插件，所以編譯時仍然需要rocksdb對應代碼的支持
#下載rocksdb對應版本的代碼
git clone https://github.com/tikv/rocksdb pingcap_rocksdbgit clone https://github.com/tikv/titan.git
cd titan && mkdir build && cd build#編譯時需制定我們剛才下載好的titan使用的rocksdb版本代碼,在pingcap_rocksdb目錄下
#（不能使用最新的rocksdb代碼，否則部分文件會缺失
#同時還要指定我們編譯好的glfags 安裝的路徑
cmake .. -DROCKSDB_DIR=../pingcap_rocksdb -DCMAKE_PREFIX_PATH=/xxx/gflags -DCMAKE_BUILD_TYPE=Releasemake -j #編譯

測試

使用rocksdb提供的接口編寫測試代碼

目標：測試rocksdb的寫性能。
需求子功能如下：

可以指定寫請求的輸入
key的選擇范圍可以輸入（測試熱點讀的性能），默認(2^64)范圍內(nèi)，key的生成在指定的范圍內(nèi)是隨機的
value的size可以輸入，可以測試不同大小的value場景下寫的性能
compaction線程數(shù)目可以指定

編寫測試代碼如下 rocksdb_titan_test.h：

#include <ctime>
#include <cstdio>
#include <cstdlib>
#include <cassert>#include <sys/time.h>
#include <unistd.h>
#include <signal.h>#include <iostream>
#include <string>
#include <vector>#include "rocksdb/db.h"using namespace std;static long db_count = 3; //生成三個db數(shù)據(jù)庫，使用三個字進程分別向三個db數(shù)據(jù)庫壓測數(shù)據(jù)
static long test_count;
static long key_range;static long compaction_num = 32; //指定compaction的線程數(shù)，默認是32個
static long value_size = 100; //指定value_size的大小，默認是100KBstatic long db_no = -1;static long parse_long(const char *s)
{char *end_ptr = nullptr;long v = strtol(s, &end_ptr, 10);assert(*s != '\0' && *end_ptr == '\0');return v;
}static double now()
{struct timeval t;gettimeofday(&t, NULL);return t.tv_sec + t.tv_usec / 1e6;
}static string long_to_str(long n)
{char s[30];sprintf(s, "%ld", n);return string(s);
}/*初始化各個參數(shù) 以及 生成子進程來負責分別向各自的數(shù)據(jù)庫進行壓測*/
static void init(int argc, char *argv[])
{assert(argc == 5);test_count = parse_long(argv[1]);key_range = parse_long(argv[2]);value_size = parse_long(argv[3]);compaction_num = parse_long(argv[4]);/*如果key輸入為0，那么key的范圍為2^62次方，即完全的隨機key寫 */if (key_range == 0){key_range = 1L << 62;}assert(db_count > 0 && db_count <= 20 && test_count > 0 && key_range > 0 && value_size > 0 && compaction_num >= 0);for (long i = 0; i < db_count; ++ i){pid_t pid = fork();assert(pid >= 0);if (pid == 0){//childsignal(SIGHUP, SIG_IGN); //接收到兩個終止信號，則子進程終止運行db_no = i;break;}}if (db_no < 0){//parentsleep(1);exit(0);}srand((long)(now() * 1e6) % 100000000);
}/*在給定的key的范圍內(nèi)，隨機生成key*/
static string rand_key()
{char s[30];unsigned long long n = 1;for (int i = 0; i < 4; ++ i){n *= (unsigned long long)rand();}sprintf(s, "%llu", n % (unsigned long long)key_range);string k(s);return k;
}/*使用模版函數(shù)來實例化Rocksdb和titanDb*/
template <class DB, class OPT>
static void do_test(const string &db_name)
{OPT options;options.create_if_missing = true;options.stats_dump_period_sec = 30;Options.use_fsync=true; //初始化db時使用SYNC寫，否則數(shù)據(jù)會通過文件系統(tǒng)寫入到pagecache中就返回了。if(compaction_num == 0) {options.compaction_style = kCompactionStyleNone;// 如設(shè)置的compaction線程數(shù)為0，則需制定None參數(shù)來禁止compaction} else {Options.max_background_compactions = compaction_num;  //否則設(shè)置具體線程數(shù)}string db_full_name = db_name + "_" + long_to_str(db_no); //組合各個子db數(shù)據(jù)庫的名稱printf("%s: db_count=%ld, test_count=%ld, key_range=%ld\n", db_full_name.c_str(), db_count, test_count, key_range);/*rocksdb自身的open函數(shù)，打開./db/rocksdb_1 或者 ./db/titan_1作為db目錄*/DB *db;rocksdb::Status status = DB::Open(options, string("./db/") + db_full_name, &db);if (!status.ok()){cerr << "open db failed: " << status.ToString() << endl;exit(1);}const size_t long_value_len = 5 * 1024 * 1024;string long_value(long_value_len, 'x');assert(long_value.size() == long_value_len);for (size_t i = 0; i < long_value_len; ++ i){long_value[i] = (unsigned char)(rand() % 255 + 1);}double ts = now();const size_t value_slice_len = value_size * 1024; //每一個value的分片大小for (long i = 1; i <= test_count; ++ i){rocksdb::Slice rand_value(long_value.data() + rand() % (long_value_len - value_slice_len), value_slice_len);/*Put請求*/rocksdb::Status s = db->Put(rocksdb::WriteOptions(), rand_key(), rand_value);if (!s.ok()){cerr << "Put failed: " << s.ToString() << endl;exit(1);}/*每寫10000 key-value到數(shù)據(jù)庫，計算耗時和寫入性能*/if (i % 10000 == 0){double tm = now() - ts;printf("%s: time=%.2f, count=%ld, speed=%.2f\n", db_full_name.c_str(), tm, i, i / tm); fflush(stdout);}}printf("\n");sleep(30);   //等待最后的stat dump輸出delete db;
}

rocksdb_test.cpp

#include "rocksdb_titan_test.h"int main(int argc, char *argv[])
{init(argc, argv);do_test<rocksdb::DB, rocksdb::Options>("rocksdb");
}

titan_test.cpp

#include "titan/db.h"
#include "rocksdb_titan_test.h"int main(int argc, char *argv[])
{init(argc, argv);do_test<rocksdb::titandb::TitanDB, rocksdb::titandb::TitanOptions>("titan");
}

編譯鏈接rocksdb和titandb 各自動態(tài)庫，生成二進制文件

將以上三個文件放在同一目錄下db_code,且在當前目錄下編寫用于編譯鏈接庫的Makefile

PS:makefile中的一些路徑(g++/gflags)需要和之前編譯rocksdb/titandb時的路徑一致

#高版本g++所在路徑
CC = /xxx/gcc-5.3/bin/gcc#指定編譯時所需要的庫
CFLAGS = -std=gnu++11 -Wall -O2 -fno-strict-aliasing -fPIC -pthread -rdynamic#指定rocksdb和titandb 運行時需要依賴的庫
LDFLAGS = -lz -lbz2 -ldl -lrt -llz4 -lsnappyROCKSDB_DIR = /home/xxx/rocksdb_vs_titan/rocksdb
ROCKSDB_INCLUDE_FLAGS = -I$(ROCKSDB_DIR)/include
ROCKSDB_LIB = $(ROCKSDB_DIR)/librocksdb.arocksdb:$(CC) $(CFLAGS) $(R_INCLUDE_FLAGS) -o rocksdb_test rocksdb_test.cpp $(R_LIB) $(LDFLAGS)TITANR_DIR = /home/xxx/rocksdb_vs_titan/rocksdb_vs_titan/pingcap_rocksdb
TITAN_DIR = /home/xxx/rocksdb_vs_titan/rocksdb_vs_titan/titan
TITAN_INCLUDE_FLAGS = -I$(TITAN_DIR)/include -I$(TITANR_DIR)/include -I$(TITANR_DIR)
TITAN_LIB = $(TITAN_DIR)/build/libtitan.a $(TITAN_DIR)/build/rocksdb/librocksdb.atitan:$(CC) $(CFLAGS) $(T_INCLUDE_FLAGS) -o titan_test titan_test.cpp $(T_LIB) $(LDFLAGS)all: rocksdb titan

編譯：
在當前目錄下db_code執(zhí)行：
make rocksdb_test 來生成rocksdb的測試二進制文件 rocksdb_test
在當前目錄下db_code執(zhí)行：
make titan_test 生成titandb的測試二進制文件 titan_test

或者執(zhí)行make all生成兩個測試的二進制文件

測試

尋找一塊磁盤（建議ssd），格式化成文件系統(tǒng)
mkfs.xfs /dev/sdd
掛載進入到文件系統(tǒng)
mount /dev/sdd /db_test && cd /db_test
拷貝我們編譯好的兩個二進制文件到當前目錄，創(chuàng)建db文件夾
運行方式如下:
./rocksdb_test 500000 0 8 32
測試五十萬value大小為8KB隨機key寫性能，后臺設(shè)置compaction線程個數(shù)為32

輸出如下:

Thu May 14 23:03:14 2020
rocksdb_1: db_count=3, test_count=500000, key_range=4611686018427387904
Thu May 14 23:03:14 2020
rocksdb_2: db_count=3, test_count=500000, key_range=4611686018427387904
Thu May 14 23:03:14 2020
rocksdb_0: db_count=3, test_count=500000, key_range=4611686018427387904
Thu May 14 23:03:14 2020rocksdb_3: time=275.50, count=30000, speed=108.89
Thu May 14 23:03:14 2020rocksdb_2: time=277.97, count=30000, speed=107.92
Thu May 14 23:03:14 2020rocksdb_0: time=280.40, count=30000, speed=106.99
Thu May 14 23:03:14 2020rocksdb_3: time=282.53, count=30000, speed=106.18
Thu May 14 23:03:14 2020rocksdb_2: time=358.02, count=40000, speed=111.73

同時在當前目錄的db目錄下可以看到對應的rocksdb數(shù)據(jù)庫相關(guān)文件已經(jīng)生成

#查看當前目錄下的db目錄
ls db/
rocksdb_0 rocksdb_1 rocksdb_2#查看rocksdb_0目錄可以看到已經(jīng)生成的sst和manifest文件
ls rocksdb_0
001303.sst
001304.log
001305.sst
CURRENT
IDENTITY
LOCK
LOG
MANIFEST-000009
OPTIONS-000005

可以通過LOG文件，分析rocksdb的寫過程 + compaction過程以及產(chǎn)生的寫放大的詳細情況。

通過以上方式分別在不同value size 和compaction線程數(shù)的情況下對rocksdb和titan Db的性能進行測試。目前僅僅測試了寫，發(fā)現(xiàn)titanDb的隨機key以及big value情況下的寫性能優(yōu)于rocksdb 2-3倍。
具體原因可以參考以上titanDB相對于rocksdb的核心優(yōu)化點。

參考資料

wisckey論文：https://www.usenix.org/system/files/conference/fast16/fast16-papers-lu.pdf
titanDb設(shè)計: https://pingcap.com/blog/titan-storage-engine-design-and-implementation/
titanDb代碼: https://github.com/tikv/titan
rocksdb設(shè)計: https://github.com/facebook/rocksdb/wiki
rocksdb代碼: https://github.com/facebook/rocksdb

總結(jié)

以上是生活随笔為你收集整理的Rocksdb 与 TitanDb 原理分析及性能对比测试的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。