相信很多人都看過火爆的美劇《硅谷》，里面描寫的未來科技就是，可以在緊縮的數據上作檢索，而無需事前將數據解壓。在現實中，我們就在研發這類技術。基于這項核心技術，我們對外發布了存儲引擎產品 TerarkDB，這個產品具有極高的技術壁壘。我們的目標就是超出 Facebook 的 RocksDB，Google的 LevelDB，MongoDB 的 Wiredtiger，作出世界上性能最好的存儲引擎。

TerarkDB 簡介

TerarkDB 是1個具有極高性能和數據緊縮率的存儲引擎。使用方法類似Facebook的RocksDB，不過比 RocksDB 具有更多功能，下面是 TerarkDB 的功能特性：

• 高緊縮率，通常是 snappy 的2～5倍
• 實時免解壓直接檢索數據
• Query 延遲很低并且很穩定
• 同1 Table 可包括多個索引，支持聯合索引，支持范圍搜索
• 原生支持正則表達式檢索
• 支持嵌入進程，或 Server-Client 模式
• 數據持久化
• 支持 Schema，包括豐富的數據類型
• 列存儲和行存儲，支持 Column Group

TerarkDB 在互聯網和傳統行業都有相當廣泛的利用場景。由于 TerarkDB 對讀操作做了大量優化，因此更合適多讀少寫，和批量寫大量讀的場景。

TerarkDB 使用方法相當靈活，可以作為獨立庫使用以適應客戶的定制化場景。官方提供了下載包和 Docker 以方便用戶下載使用。目前支持Linux，Windows和Mac OS操作系統。

TerarkDB 作為1個存儲引擎，有自己的原生接口，同時提供兼容 LevelDB 的接口，從而可以適配到所有使用 LevelDB 的系統和利用，例照實現了大部份 Redis 接口的 SSDB。另外，大家廣泛使用的 RocksDB 接口是 LevelDB 接口的超集，所以大部份使用 RocksDB 的系統和利用也能夠很容易地適配到 TerarkDB。

Terark 官方提供了 TerarkDB 到 MongoDB 的適配，到 MySQL 和其他散布式數據庫系統的適配也在緊張的開發進程中，穩定版的 MongoTerark 產品已計劃在近期發布。

TerarkDB 性能測試報告

本節內容來自 Terark 官網，查看原文

目錄

• 1.環境
  
  • 1.1.服務器信息
  • 1.2.比較對象
  • 1.3.測試數據集
  • 1.4.測試源代碼
  • 1.5.緊縮率說明
• 2.Tests
  
  • 2.1.隨機讀測試
  • 2.2.隨機寫測試
  • 2.3.讀寫混測
  • 2.4 讀延遲測試

1.環境

1.1.服務器信息

1.2.比較對象

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，不需要在每條記錄中額外保存元數據（列名）
• 為公平起見，對其它數據庫，僅在列（字段）之間插入1個分隔符，不保存列名

數據集大小

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

1.4.Benchmark 源代碼

Benchmark 源代碼參見 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, 其他數據庫進行1輪預讀)

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

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

2.1.3.數據遠大于內存

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

由于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 采取索引和數據分離的方式進行寫操作，能夠將數據的寫入方式在1定程度上轉換成順序寫

2.2.3.數據遠大于內存

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

2.3.Read-Write Mixed

• TerarkDB 主要利用于少許寫大量讀的場景
• 測試1共使用8個線程，其中每一個線程內部隨機讀寫，95% / 99%的時間在進行讀操作
• 寫操作全部啟用緊縮，塊緊縮的大小是 4KB
• 首先讓其他數據庫進行1輪隨機讀(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, 其他數據庫進行1輪預讀)

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

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專用緩存

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

2.4.2. 數據遠大于內存

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

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

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

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

技術解析

TerarkDB使用了非常先進并且復雜的技術，同時也申請了4個專利。其核心技術與其他數據庫產品的B＋樹、LSM樹、和塊緊縮技術有著本質的區分。帶來的好處就是緊縮率與性能的同時大幅提高，并不是簡單的時間空間互換。本文扼要介紹幾個技術點，更多的技術細節請大家到 terark.com 上查看文檔。

并不是“空間換時間”或“時間換空間”

現有技術

現有的主流數據庫也在使用緊縮技術，只不過它們主要是對時間與空間的折衷：緊縮的方式都是使用通用緊縮技術按塊/頁(block/page)緊縮（塊尺寸通常是 4K~32K，以緊縮率著稱的 TokuDB 塊尺寸是 2M~4M）。

當啟用緊縮的時候，隨之而來的是訪問速度降落，這是由于：

• 寫入時，很多條記錄被打包在1起緊縮成1個個的塊，增大塊尺寸，緊縮算法可以取得更大的上下文，從而提高緊縮率；相反地，減小塊尺寸，會下降緊縮率。

• 讀取時，即使是讀取很短的數據，也需要先把全部塊解壓，再去讀取解壓后的數據。這樣，塊尺寸越大，同1個塊內包括的記錄數目越多，為讀取1條數據，所做的沒必要要的解壓就也就越多，性能也就越差。相反地，塊尺寸越小，性能也就越好。

1旦啟用緊縮，為了減緩以上問題，傳統數據庫1般都需要比較大的專用緩存，用來緩存解壓后的數據，這樣可以大幅提高熱數據的訪問性能，但又引發了雙緩存的空間占用問題，1是操作系統緩存中的緊縮數據，2是專用緩存中解壓后的數據。還有1個一樣很嚴重的問題：專用緩存終歸是緩存，當緩存未命中時，仍需要解壓全部塊，這就是慢Query問題的1個來源；慢Query 的另外一個來源是操作系統緩存未命中時……

傳統數據庫的 Btree 索引本身也會占據較大的空間，由于 Btree 通常使用的前綴緊縮的緊縮率很低。

這些都致使現有傳統數據庫在訪問速度和空間占用上是1個此消彼長，沒法完全解決的問題，只能進行這樣或那樣的折衷。

Terark 的技術 與現有數據庫有本質上的區分

對數據的緊縮（可以認為是 key-value 中對 value 的緊縮），TerarkDB 主要使用自己研發的專門針對數據庫的全局緊縮技術，緊縮率更高，并且沒有塊緊縮的概念，也沒有雙緩存的問題。這類緊縮技術可以按 RowID/RecordID 直接讀取單條數據，如果把這類讀取單條數據看做是1種解壓，那末，按 RowID 順序解壓時，解壓速度1般在 500MB每秒(單線程)，最高到達約 7GB/s；按 RowID 隨機解壓時，解壓速度1般在 300MB每秒(單線程)，最高到達約3GB/s。

對索引的緊縮，Terark 主要使用 Succinct 技術，緊縮率高于現有技術，并且緊縮的同時，不用解壓就能夠高效地履行搜索，除此以外，索引可以支持正則表達式搜索(不用逐條遍歷匹配正則表達式)。這類基于 Succinct 技術的索引，還額外支持 反向搜索：正向是從 Key 獲得 RowID，反向搜索就是從 RowID 獲得 Key，這樣，Key 就不需要再單獨存儲1份（傳統Btree索引無這個功能）。這就為 TerarkDB 在同1個 Table 上支持多個索引提供了1個技術支點。

Succinct 技術誕生已有很長時間，但是1直由于性能問題未得到廣泛利用，Terark Succinct 技術在 CPU 指令級別專門做了優化，大幅提升了 Succinct 的性能。

正是這些新技術的使用，TerarkDB 的緊縮率和訪問速度同時大幅提升，并且功能非常豐富。

TerarkDB數據庫架構

TerarkDB 數據庫包括多個 segment，依照 segment 的狀態可分為 writing segment，writable frozen segment，和 readonly segment。數據會首先寫入 writing segment，這個 segment 中的數據可以直接更新及檢索。當寫入的數據到達1定的尺寸時，writing segment 會成為 writable frozen segment ，同時開始被后臺線程進行緊縮。當后臺緊縮結束時，就會生成 readonly segment，并刪除 writable frozen segment。除此以外，數據的物理刪除、segment 合并等工作也都在后臺線程中履行。終究，大部份數據都會處于 readonly segment 中，從而具有極高的緊縮率和訪問性能。

自動機技術和 Succinct 技術

與 Terark 同時在工程化 Succinct 技術的還有著名的伯克利 AmpLab 實驗室，Spark 就是在這個實驗室誕生的。Terark 在算法、數據結構和工程技術上都有著本身的優勢。

自動機技術在 TerarkDB 中有大量的利用，自動機就是1張狀態轉移圖，這張圖用來表達數據，沿著圖中的邊，依照某個肯定的規則訪問節點，就能夠抽取出所需要的數據。用傳統技術來存儲這個圖，內存消耗很大，Terark 采取 Succinct 技術來緊縮這個狀態轉移圖。Succinct 技術的本質就是使用 bitmap 來表示數據結構，內存用量大大下降的同時保持快速的訪問性能。另外一方面，由因而基于自動機，也就能夠原生支持正則表達式檢索。

結語

歡迎大家下載使用 Terark 產品。未來 Terark 計劃把核心引擎移植到更多散布式系統以適用更多場景，比如 Elastic Search，Spark，手機和嵌入式裝備等。Terark 現階段的計劃是，尋覓到更多的研發和商務合作，把產品盡快推向市場。我們目前也在招人，感興趣的朋友可以直接聯系我們。也能夠訪問 官方網站 來獲得更多信息。