TerarkDB 性能測試報告

AlpOquendo 8年前發布 | 20K 次閱讀 TerarkDB

本篇文章來自 Terark 官網，查看原文

TerarkDB 性能測試報告

TerarkDB是一款功能豐富的數據庫，具有優異的讀性能和良好的寫性能 — 因為使用的是自主研發的索引壓縮和數據壓縮技術（索引不是傳統的B+樹或者LSM，數據也不是塊壓縮）。

TerarkDB v0.13 近期剛剛發布，目前這個版本已經具有了比較完善的功能，為了更好地讓大家了解我們的產品，我們內部進行了一些比較全面的性能評測。

本文包含三種場景: 數據小于內存, 數據略大于內存以及數據遠大于內存, 后續我們會發布更多的測試報告。

1.環境

1.1.服務器信息

指標	描述
CPU	Intel(R) Xeon(R) CPU E5-2630 v3 @ 2.40GHz (2 x 8個物理核)
Memory	64 GB of DDR4 RAM
SSD	Intel? SSD 520 Series (480GB, 2.5in SATA 6Gb/s, 25nm, MLC)
Linux Kernel	3.10.0-327.10.1.el7.x86_64

1.2.比較對象

產品名稱	版本	公司
rocksdb	v4.4	非死book
wiredtiger	v2.8.0	MongoDB
hyperleveldb	v1.2.2
leveldb	v1.18	Google

1.3.測試數據集

Amazon movie data (~8 million reviews), 平均每條數據長度大約 1K

原始數據格式

product/productId: B00006HAXW
review/userId: A1RSDE90N6RSZF
review/profileName: Joseph M. Kotow
review/helpfulness: 9/9
review/score: 5.0
review/time: 1042502400
review/summary: Pittsburgh - Home of the OLDIES
review/text: I have all of the doo wop DVD's and this one is as good or better than the
1st ones. Remember once these performers are gone, we'll never get to see them again.
Rhino did an excellent job and if you like or love doo wop and Rock n Roll you'll LOVE
this DVD !!

元數據（列名）

因為 TerarkDB 有 Schema，不需要在每條記錄中額外保存元數據（列名）
為公平起見，對其它數據庫，僅在列（字段）之間插入一個分隔符，不保存列名

數據集大小

movies數據集的總大小約為 9GB, 記錄數大約為 800萬條

1.4.測試用例源代碼

Github倉庫

1.5.Compression Ratio

TerarkDB 使用自己研發的壓縮算法進行數據壓縮
其他數據庫使用塊壓縮，塊大小為 4KB，壓縮算法設置為 snappy
我們使用隨機寫的測試用例，對寫入并壓縮后的數據尺寸進行對比

2.Tests

所有的讀操作，都是單條記錄隨機查詢。所有的寫操作，也都是單條記錄隨機插入或更新。

2.1.Random Read

所有的數據會預先寫入文件系統
所有的數據庫寫入操作均啟用壓縮，配置 rocksdb/leveldb/wiredtiger 使用 snappy 算法
TerarkDB使用我們自己專有的壓縮算法，不需要塊壓縮，其他數據庫均使用4KB的默認塊大小(Block Size)

2.1.1.數據小于內存

在這種情況下我們的內存足夠大，可以把所有的數據裝入內存，同時 TerarkDB 不需要專有緩存，但其它數據庫需要專有緩存（主要用來緩存對塊壓縮解壓后的數據），我們為這些數據庫設置專有緩存設置為3GB。

同時這項測試我們不限制操作系統對內存的使用（總內存64GB），數據量遠小于內存，操作系統可以把所有數據緩存起來。

我們可以看到TerarkDB在這種情況下要好于其他數據庫：

TerarkDB 使用自主研發的數據壓縮算法，可以直接提取單條記錄，不需要傳統數據庫的塊壓縮/解壓
TerarkDB 使用自主研發的Succinct壓縮型數據結構作為索引，使用更少的內存，并且搜索速度更快

2.1.2.數據略大于內存

當數據量無法全部載入內存的情況下，我們需要把數據存儲在物理磁盤上（我們此處使用 SSD 作為存儲介質）。

操作系統可以使用的的物理內存限制為8GB
我們為其他數據庫設置了1GB的專用緩存用來裝載熱數據
所有數據庫進行了預熱(TerarkDB開啟mmap populate, 其他數據庫進行一輪預讀)

這種情況下，TerarkDB 的優勢更明顯：

除了 TerarkDB 以外，其他的數據庫均需要使用塊壓縮，在隨機讀的情況下，即便有緩存支持，但畢竟緩存的大小有限，不可能把所有數據裝入緩存，這就會導致頻繁的磁盤I/O，降低讀性能
TerarkDB 的壓縮率比較高，壓縮后的數據可以全部裝入內存，同時 TerarkDB 可以直接訪問壓縮后的數據，使 TerarkDB 的優勢更加明顯
其他數據庫由于使用了專有緩存，當讀取的數據遠遠超出緩存容量，會造成大量的數據換入和換出，增加了額外的資源開銷

2.1.3.數據遠大于內存

操作系統內存限制為3G
為其他數據庫設置256M的專用緩存
所有數據庫進行了預熱(TerarkDB開啟mmap populate, 其他數據庫進行一輪預讀)

由于TerarkDB比其他數據庫的數據高出太多，下面這幅圖使用對數坐標，更便于查看數量級（請觀察縱坐標軸）

2.2.Random Write

寫入時所有的數據庫均開啟壓縮，并且默認塊壓縮的大小為 4KB（TerarkDB不需要塊壓縮）
所有的寫 Buffer 都設置為256M
寫入時分別使用 1/3/6 個線程同時進行操作

2.2.1.數據小于內存

隨機寫測試和隨機讀(Random Read)測試的環境類似：

存儲介質使用內存文件系統(即數據先預讀到內存文件系統中，以加快測試速度)
操作系統內存不做限制
除了 TerarkDB, 為其他數據庫設置 3GB 的專用緩存

2.2.2.數據略大于內存

與隨機讀測試的環境類似：

操作系統的總內存限制為 8GB
除了 TerarkDB ，其他數據庫的專用緩存設置為1GB
數據存儲介質采用 SSD
寫 buffer 設置為 256M

在SSD上的測試結果，更真實的反應了磁盤I/O對性能的影響:

TerarkDB 采用索引和數據分離的方式進行寫操作，能夠將數據的寫入方式在一定程度上轉換成順序寫

2.2.3.數據遠大于內存

操作系統內存限制為3G
為其他數據庫設置256M的專用緩存

2.3.Read-Write Mixed

TerarkDB 主要應用于少量寫大量讀的場景
測試一共使用8個線程，其中每個線程內部隨機讀寫，95% / 99%的時間在進行讀操作
寫操作全部啟用壓縮，塊壓縮的大小是 4KB
首先讓其他數據庫進行一輪隨機讀(warm up), 填充專用緩存

2.3.1. 數據量小于內存

存儲介質使用內存文件系統(即數據先預讀到內存文件系統中，以加快測試速度)
操作系統內存不做限制
除了 TerarkDB ，其他數據庫的專用緩存設置為3GB

2.3.2. 數據略大于內存

存儲介質改為 SSD
操作系統內存限制為8GB
其他數據庫的專用緩存設置為1GB
分別測試 99% Read 和 95% Read

2.3.3.數據遠大于內存

操作系統內存限制為3G
為其他數據庫設置256M的專用緩存
所有數據庫進行了預熱(TerarkDB開啟mmap populate, 其他數據庫進行一輪預讀)

同樣，由于數量級相差較大，我們通過對數坐標看一下數據：

2.4 Read Latency Test

該測試中數據集依然是9G的電影點評數據，僅測試的 Read Query 延遲，測試中無 Write 操作。

因為 TerarkDB 的壓縮率很高，系統內存3G就可以裝下全部數據（實際上壓縮后的數據只有2.1G，但測試程序本身要占大約750M內存），所以以下3組對比中，TerarkDB都是在3G內存的條件下測試的。對于rocksdb和wiredtiger，我們分別在8G，4G和3G內存的條件下進行了測試。所有測試中，我們均使用了8個線程。

2.4.1. 數據略大于內存

8G物理內存（TerarkDB是3G）
其他數據庫有512M專用緩存

Average	Median	99th Percentile	StdDev
rocksdb	40.86	24	300
wiredtiger	58.82	41	450
terarkdb	6.66	6	25

- 橫坐標表示延遲，數字的單位是微秒，坐標比例是近似對數的
- 仔細觀察橫坐標的數字可以發現 TerarkDB 的延遲要低得多
- 縱坐標表示區間內累計Query數的所占總Query數的百分比
- Point(X, Y%) 表示 延遲低于 X微秒的Query數 占 總Query數 的 Y%
- 數據結果，越快到達100%，說明 Query 延遲表現越好（延遲越低）
- 在當前情況下，內存對所有數據庫都夠用，所以曲線較為平滑
- TerarkDB的Latency均值，中值，標準差，99分位值都有明顯優勢，Latency很穩定。

2.4.2. 數據遠大于內存

3G物理內存
其他數據庫有256M的專有緩存

Average	Median	99th Percentile	StdDev
rocksdb	1338.88	1210	5000
wiredtiger	273.06	353	600
terarkdb	6.67	6	25

其他數據庫有兩段斜向上的曲線，分別表示讀取的數據命中內存以及沒有命中內存兩種情況下的延遲，中間那條直線基本上是緩存是否命中的分界點
TerarkDB的延遲要低得多，TerarkDB的Latency均值，中值，標準差，99分位值都有明顯優勢，Latency很穩定
在這種情況下，雖然總內存只有3G，但是我們的壓縮率比較高，壓縮后的數據完全可以裝入內存，所以不會出現Cache未命中的情況

2.4.3 我們還測試了 rocksdb 和 wiredtiger 在4G內存條件下的指標：

Average	Median	99th Percentile	StdDev
rocksdb	964.21	970.36	2500
wiredtiger	204.85	56.25	600
terarkdb	6.67	6	25

- 我們可以看到，在 4G 內存的情況下，RocksDB 和 WiredTiger 出現緩存命中的操作比率升高了（中間一段水平直線）

來自： http://blog.csdn.net/whinah/article/details/51545839

本文由用戶 AlpOquendo 自行上傳分享，僅供網友學習交流。所有權歸原作者，若您的權利被侵害，請聯系管理員。

轉載本站原創文章，請注明出處，并保留原始鏈接、圖片水印。

本站是一個以用戶分享為主的開源技術平臺，歡迎各類分享！

本文地址：http://www.baiduhome.net/lib/view/open1464679206471.html

TerarkDB

TerarkDB 性能測試報告

目錄

1.環境

1.1.服務器信息

1.2.比較對象

1.3.測試數據集

1.4.測試用例源代碼

1.5.Compression Ratio

2.Tests

2.1.Random Read

2.2.Random Write

2.3.Read-Write Mixed

2.4 Read Latency Test

相關經驗

相關資訊

相關文檔

目錄