作為數(shù)據(jù)庫，在系統(tǒng)資源(CPU、內(nèi)存、SSD、磁盤等)一定的前提下，我們希望：

• 存儲(chǔ)的數(shù)據(jù)更多：采用壓縮，這個(gè)世界上有各種各樣的壓縮算法;
• 訪問的速度更快：更快的壓縮(寫)/解壓(讀)算法、更大的緩存。

幾乎所有壓縮算法都嚴(yán)重依賴上下文：

• 位置相鄰的數(shù)據(jù)，一般情況下相關(guān)性更高，內(nèi)在冗余度更大;
• 上下文越大，壓縮率的上限越大(有極限值)。

塊壓縮

傳統(tǒng)數(shù)據(jù)庫中的塊壓縮技術(shù)

對(duì)于普通的以數(shù)據(jù)塊/文件為單位的壓縮，傳統(tǒng)的(流式)數(shù)據(jù)壓縮算法工作得不錯(cuò)，時(shí)間長(zhǎng)了，大家也都習(xí)慣了這種數(shù)據(jù)壓縮的模式。基于這種模式的數(shù)據(jù)壓縮算法層出不窮，不斷有新的算法實(shí)現(xiàn)。包括使用最廣泛的gzip、bzip2、Google的Snappy、新秀Zstd等。

• gzip幾乎在在所有平臺(tái)上都有支持，并且也已經(jīng)成為一個(gè)行業(yè)標(biāo)準(zhǔn)，壓縮率、壓縮速度、解壓速度都比較均衡;
• bzip2是基于BWT變換的一種壓縮，本質(zhì)是上對(duì)輸入分塊，每個(gè)塊單獨(dú)壓縮，優(yōu)點(diǎn)是壓縮率很高，但壓縮和解壓速度都比較慢;
• Snappy是Google出品，優(yōu)點(diǎn)是壓縮和解壓都很快，缺點(diǎn)是壓縮率比較低，適用于對(duì)壓縮率要求不高的實(shí)時(shí)壓縮場(chǎng)景;
• LZ4是Snappy一個(gè)強(qiáng)有力的競(jìng)爭(zhēng)對(duì)手，速度比Snappy更快，特別是解壓速度;
• Zstd是一個(gè)壓縮新秀，壓縮率比LZ4和Snappy都高不少，壓縮和解壓速度略低;相比gzip，壓縮率不相上下，但壓縮/解壓速度要高很多。

對(duì)于數(shù)據(jù)庫，在計(jì)算機(jī)世界的太古代，為I/O優(yōu)化的Btree一直是不可撼動(dòng)的，為磁盤優(yōu)化的Btree block/page size比較大，正好讓傳統(tǒng)數(shù)據(jù)壓縮算法能得到較大的上下文，于是，基于block/page的壓縮也就自然而然地應(yīng)用到了各種數(shù)據(jù)庫中。在這個(gè)蠻荒時(shí)代，內(nèi)存的性能、容量與磁盤的性能、容量涇渭分明，各種應(yīng)用對(duì)性能的需求也比較小，大家都相安無事。

現(xiàn)在，我們有了SSD、PCIe SSD、3D XPoint等，內(nèi)存也越來越大，塊壓縮的缺點(diǎn)也日益突出：

• 塊選小了，壓縮率不夠;塊選大了，性能沒法忍;
• 更致命的是，塊壓縮節(jié)省的只是更大更便宜的磁盤、SSD;
• 更貴更小的內(nèi)存不但沒有節(jié)省，反而更浪費(fèi)了(雙緩存問題)。

于是，對(duì)于很多實(shí)時(shí)性要求較高的應(yīng)用，只能關(guān)閉壓縮。

塊壓縮的原理

使用通用壓縮技術(shù)(Snappy、LZ4、zip、bzip2、Zstd等)，按塊/頁(block/page)進(jìn)行壓縮(塊尺寸通常是4KB~32KB，以壓縮率著稱的TokuDB塊尺寸是2MB~4MB)，這個(gè)塊是邏輯塊，而不是內(nèi)存分頁、塊設(shè)備概念中的那種物理塊。

啟用壓縮時(shí)，隨之而來的是訪問速度下降，這是因?yàn)椋?/p>

• 寫入時(shí)，很多條記錄被打包在一起壓縮成一個(gè)個(gè)的塊，增大塊尺寸，壓縮算法可以獲得更大的上下文，從而提高壓縮率;相反地，減小塊尺寸，會(huì)降低壓縮率。
• 讀取時(shí)，即便是讀取很短的數(shù)據(jù)，也需要先把整個(gè)塊解壓，再去讀取解壓后的數(shù)據(jù)。這樣，塊尺寸越大，同一個(gè)塊內(nèi)包含的記錄數(shù)目越多。為讀取一條數(shù)據(jù)，所做的不必要解壓就也就越多，性能也就越差。相反地，塊尺寸越小，性能也就越好。

一旦啟用壓縮，為了緩解以上問題，傳統(tǒng)數(shù)據(jù)庫一般都需要比較大的專用緩存，用來緩存解壓后的數(shù)據(jù)，這樣可以大幅提高熱數(shù)據(jù)的訪問性能，但又引起了雙緩存的空間占用問題：一是操作系統(tǒng)緩存中的壓縮數(shù)據(jù);二是專用緩存(例如RocksDB中的DBCache)中解壓后的數(shù)據(jù)。還有一個(gè)同樣很嚴(yán)重的問題：專用緩存終歸是緩存，當(dāng)緩存未***時(shí)，仍需要解壓整個(gè)塊，這就是慢Query問題的一個(gè)主要來源(慢Query的另一個(gè)主要來源是在操作系統(tǒng)緩存未***時(shí))。

這些都導(dǎo)致現(xiàn)有傳統(tǒng)數(shù)據(jù)庫在訪問速度和空間占用上是一個(gè)此消彼長(zhǎng)、無法徹底解決的問題，只能采取一些折衷。

RocksDB 的塊壓縮

以RocksDB為例，RocksDB中的BlockBasedTable就是一個(gè)塊壓縮的SSTable，使用塊壓縮，索引只定位到塊，塊的尺寸在dboption里設(shè)定，一個(gè)塊中包含多條(key，value)數(shù)據(jù)，例如M條，這樣索引的尺寸就減小到了1/M：

• M越大，索引的尺寸越小;
• M越大，Block的尺寸越大，壓縮算法(gzip、Snappy等)可以獲得的上下文也越大，壓縮率也就越高。

創(chuàng)建BlockBasedTable時(shí)，Key Value被逐條填入buffer，當(dāng)buffer尺寸達(dá)到預(yù)定大小(塊尺寸，當(dāng)然，一般buffer尺寸不會(huì)精確地剛好等于預(yù)設(shè)的塊尺寸)，就將buffer壓縮并寫入BlockBasedTable文件，并記錄文件偏移和buffer中的***個(gè)Key(創(chuàng)建index要用)，如果單條數(shù)據(jù)太大，比預(yù)設(shè)的塊尺寸還大，這條數(shù)據(jù)就單獨(dú)占一個(gè)塊(單條數(shù)據(jù)不管多大也不會(huì)分割成多個(gè)塊)。所有Key Value寫完以后，根據(jù)之前記錄的每個(gè)塊的起始Key和文件偏移，創(chuàng)建一個(gè)索引。所以在BlockBasedTable文件中，數(shù)據(jù)在前，索引在后，文件末尾包含元信息(作用相當(dāng)于常用的FileHeader，只是位置在文件末尾，所以叫footer)。

搜索時(shí)，先使用searchkey找到searchkey所在的block，然后到DB Cache中搜索這個(gè)塊，找到后就進(jìn)一步在塊中搜索searchkey，如果找不到，就從磁盤/SSD讀取這個(gè)塊，解壓后放入DB Cache。RocksDB中的DB Cache有多種實(shí)現(xiàn)，常用的包括LRU Cache，另外還有Clock Cache、Counting Cache(用來統(tǒng)計(jì)Cache***率等)，還有其他一些特殊的Cache。

一般情況下，操作系統(tǒng)會(huì)有文件緩存，所以同一份數(shù)據(jù)可能既在DB Cache中(解壓后的數(shù)據(jù))，又在操作系統(tǒng)Cache中(壓縮的數(shù)據(jù))。這樣會(huì)造成內(nèi)存浪費(fèi)，所以RocksDB提供了一個(gè)折衷：在dboption中設(shè)置DIRECT_IO選項(xiàng)，繞過操作系統(tǒng)Cache，這樣就只有DB Cache，可以節(jié)省一部分內(nèi)存，但在一定程度上會(huì)降低性能。

傳統(tǒng)非主流壓縮：FM-Index

FM-Index的全名是Full Text Matching Index，屬于Succinct Data Structure家族，對(duì)數(shù)據(jù)有一定的壓縮能力，并且可以直接在壓縮的數(shù)據(jù)上執(zhí)行搜索和訪問。

FM-Index的功能非常豐富，歷史也已經(jīng)相當(dāng)悠久，不算是一種新技術(shù)，在一些特殊場(chǎng)景下也已經(jīng)得到了廣泛應(yīng)用，但是因?yàn)楦鞣N原因，一直不溫不火。最近幾年，F(xiàn)M-Index開始有些活躍，首先是GitHub上有個(gè)大牛實(shí)現(xiàn)了全套Succinct算法，其中包括FM-Index，其次Berkeley的Succinct項(xiàng)目也使用了FM-Index。

FM-Index屬于Offline算法(一次性壓縮所有數(shù)據(jù)，壓縮好之后不可修改)，一般基于BWT變換(BWT變換基于后綴數(shù)組)，壓縮好的FM-Index支持以下兩個(gè)最主要的操作：

• data = extract(offset, length)
• {offset} = search(string) ，返回多個(gè)匹配string的位置/偏移(offset)

FM-Index還支持更多其他操作，感興趣的朋友可以進(jìn)一步調(diào)研。

但是，在筆者看來，F(xiàn)M-Index有幾個(gè)致命的缺點(diǎn)：

• 實(shí)現(xiàn)太復(fù)雜(這一點(diǎn)可以被少數(shù)大牛們克服，不提也罷);
• 壓縮率不高(比流式壓縮例如gzip差太多);
• 搜索(search)和訪問(extract)速度都很慢(在2016年最快的CPU i7-6700K上，單線程吞吐率不超過7MB/sec);
• 壓縮過程又慢又耗內(nèi)存(Berkeley的Succinct壓縮過程內(nèi)存消耗是源數(shù)據(jù)的50倍以上);
• 數(shù)據(jù)模型是Flat Text，不是數(shù)據(jù)庫的KeyValue模型。

可以用一種簡(jiǎn)單的方式把Flat Model轉(zhuǎn)化成KeyValue Model：挑選一個(gè)在Key和Value中都不會(huì)出現(xiàn)的字符“#”(如果無法找出這樣的字符，需要進(jìn)行轉(zhuǎn)義編碼)，每個(gè)Key前后都插入該字符，Key之后緊鄰的就是Value。如此，search(#key#)返回了#key#出現(xiàn)的位置，我們就能很容易地拿到Value了。

Berkeley的Succinc項(xiàng)目在FM-Index的Flat Text模型上實(shí)現(xiàn)了更豐富的行列(Row-Column)模型，付出了巨大的努力，達(dá)到了一定的效果，但離實(shí)用還相差太遠(yuǎn)。

感興趣的朋友可以仔細(xì)調(diào)研下FM-Index，以驗(yàn)證筆者的總結(jié)與判斷。

Terark的可檢索壓縮(Searchable Compression)

Terark公司提出了“可檢索壓縮(Searchable Compression)”的概念，其核心也是直接在壓縮的數(shù)據(jù)上執(zhí)行搜索(search)和訪問(extract)，但數(shù)據(jù)模型本身就是KeyValue模型，根據(jù)其測(cè)試報(bào)告，速度要比FM-Index快得多(兩個(gè)數(shù)量級(jí))，具體闡述：

• 摒棄傳統(tǒng)數(shù)據(jù)庫的塊壓縮技術(shù)，采用全局壓縮;
• 對(duì)Key和Value使用不同的全局壓縮技術(shù);
• 對(duì)Key使用有搜索功能的全局壓縮技術(shù)COIndex(對(duì)應(yīng)FM-Index的search);
• 對(duì)Value使用可定點(diǎn)訪問的全局壓縮技術(shù)PA-Zip(對(duì)應(yīng)FM-Index的extract)。

對(duì)Key的壓縮：CO-Index

我們需要對(duì)Key進(jìn)行索引，才能有效地進(jìn)行搜索，并訪問需要的數(shù)據(jù)。

普通的索引技術(shù)，索引的尺寸相對(duì)于索引中原始Key的尺寸要大很多，有些索引使用前綴壓縮，能在一定程度上緩解索引的膨脹，但仍然無法解決索引占用內(nèi)存過大的問題。

我們提出了CO-Index(Compressed Ordered Index)的概念，并且通過一種叫做Nested Succinct Trie的數(shù)據(jù)結(jié)構(gòu)實(shí)踐了這一概念。

較之傳統(tǒng)實(shí)現(xiàn)索引的數(shù)據(jù)結(jié)構(gòu)，Nested Succinct Trie的空間占用小十幾倍甚至幾十倍。而在保持該壓縮率的同時(shí)，還支持豐富的搜索功能：

• 精確搜索;
• 范圍搜索;
• 順序遍歷;
• 前綴搜索;
• 正則表達(dá)式搜索(不是逐條遍歷)。

與FM-Index相比，CO-Index也有其優(yōu)勢(shì)(假定FM-Index中所有的數(shù)據(jù)都是Key)。 

表1 FM-Index對(duì)比CO-Index

CO-Index的原理

實(shí)際上我們實(shí)現(xiàn)了很多種CO-Index，其中Nested Succinct Trie是適用性最廣的一種，在這里對(duì)其原理做一個(gè)簡(jiǎn)單介紹：

Succinct Data Structure介紹

Succinct Data Structure是一種能夠在接近于信息論下限的空間內(nèi)來表達(dá)對(duì)象的技術(shù)，通常使用位圖來表示，用位圖上的rank和select來定位。

雖然能夠極大降低內(nèi)存占用量，但實(shí)現(xiàn)起來較為復(fù)雜，并且性能低很多(時(shí)間復(fù)雜度的常數(shù)項(xiàng)很大)。目前開源的有SDSL-Lite，我們則使用自己實(shí)現(xiàn)的Rank-Select，性能也高于開源實(shí)現(xiàn)。

以二叉樹為例

傳統(tǒng)的表現(xiàn)形式是一個(gè)結(jié)點(diǎn)中包含兩個(gè)指針：struct Node { Node *left, *right; };

每個(gè)結(jié)點(diǎn)占用 2ptr，如果我們對(duì)傳統(tǒng)方法進(jìn)行優(yōu)化，結(jié)點(diǎn)指針用最小的bits數(shù)來表達(dá)，N個(gè)結(jié)點(diǎn)就需要2*[log2(N)]個(gè)bits。

• 對(duì)比傳統(tǒng)基本版和傳統(tǒng)優(yōu)化版，假設(shè)共有216個(gè)結(jié)點(diǎn)(包括null結(jié)點(diǎn))，傳統(tǒng)優(yōu)化版需要2 bytes，傳統(tǒng)基本版需要4/8 bytes。
• 對(duì)比傳統(tǒng)優(yōu)化版和Succinct，假設(shè)共有10億(~230)個(gè)結(jié)點(diǎn)。
• 傳統(tǒng)優(yōu)化版每個(gè)指針占用[log2(230)]=30bits，總內(nèi)存占用：($\frac{2*30}{8}$)*230≈ 7.5GB。
• 使用Succinct，占用：($\frac{2.5}{8}$)*230≈ 312.5MB(每個(gè)結(jié)點(diǎn)2.5 bits，其中0.5bits是 rank-select 索引占用的空間)。

Succinct Tree

Succinct Tree有很多種表達(dá)方式，這里列出常見的兩種： 

圖1 Succinct Tree表達(dá)方式示例

Succinct Trie = Succinct Tree + Trie Label

Trie可以用來實(shí)現(xiàn)Index，圖2這個(gè)Succinct Trie用的是LOUDS表達(dá)方式，其中保存了hat、is、it、a、四個(gè)Key。

Patricia Trie加嵌套

僅使用Succinct技術(shù)，壓縮率遠(yuǎn)遠(yuǎn)不夠，所以又應(yīng)用了路徑壓縮和嵌套。這樣一來，壓縮率就上了一個(gè)新臺(tái)階。

把上面這些技術(shù)綜合到一起，就是我們的Nest Succinct Trie。

對(duì)Value的壓縮: PA-Zip

我們研發(fā)了一種叫做PA-Zip (Point Accessible Zip)的壓縮技術(shù)：每條數(shù)據(jù)關(guān)聯(lián)一個(gè)ID，數(shù)據(jù)壓縮好之后，就可以用相應(yīng)的ID訪問那條數(shù)據(jù)。這里，ID就是那個(gè)Point，所以叫做Point Accessible Zip。

PA-Zip對(duì)整個(gè)數(shù)據(jù)庫中的所有Value(KeyValue數(shù)據(jù)庫中所有Value的集合)進(jìn)行全局壓縮，而不是按block/page進(jìn)行壓縮。這是針對(duì)數(shù)據(jù)庫的需求(KeyValue 模型)，專門設(shè)計(jì)的一個(gè)壓縮算法，用來解決傳統(tǒng)數(shù)據(jù)庫壓縮的問題：

壓縮率更高，沒有雙緩存的問題，只要把壓縮后的數(shù)據(jù)裝進(jìn)內(nèi)存，不需要專用緩存，可以按ID直接讀取單條數(shù)據(jù)，如果把這種讀取單條數(shù)據(jù)看作是一種解壓，那么：

• 按ID順序解壓時(shí)，解壓速度(Throughput)一般在500MB每秒(單線程)，***達(dá)到約7GB/s，適合離線分析性需求，傳統(tǒng)數(shù)據(jù)庫壓縮也能做到這一點(diǎn);
• 按ID隨機(jī)解壓時(shí)，解壓速度一般在300MB每秒(單線程)，***達(dá)到約3GB/s，適合在線服務(wù)需求，這一點(diǎn)完勝傳統(tǒng)數(shù)據(jù)庫壓縮：按隨機(jī)解壓300MB/s算，如果每條記錄平均長(zhǎng)度1K，相當(dāng)于QPS = 30萬;如果每條記錄平均長(zhǎng)度300個(gè)字節(jié)，相當(dāng)于QPS = 100萬;
• 預(yù)熱(warmup)，在某些特殊場(chǎng)景下，數(shù)據(jù)庫可能需要預(yù)熱。因?yàn)槿サ袅藢Ｓ镁彺妫琓erarkDB的預(yù)熱相對(duì)簡(jiǎn)單高效，只要把mmap的內(nèi)存預(yù)熱一下(避免Page Fault即可)，數(shù)據(jù)庫加載成功后就是預(yù)熱好的，這個(gè)預(yù)熱的Throughput就是SSD連續(xù)讀的IO性能(較新的SSD讀性能超過3GB/s)。

與FM-Index相比，PA-Zip解決的是FM-Index的extract操作，但性能和壓縮率都要好得多： 

表2 FM-Index對(duì)比PA-Zip

結(jié)合Key與Value

Key以全局壓縮的形式保存在CO-Index中，Value以全局壓縮的形式保存在 PA-Zip中。搜索一個(gè)Key，會(huì)得到一個(gè)內(nèi)部ID，根據(jù)這個(gè)ID，去PA-Zip中定點(diǎn)訪問該ID對(duì)應(yīng)的Value，整個(gè)過程中只觸碰需要的數(shù)據(jù)，不需要觸碰其他數(shù)據(jù)。

如此無需專用緩存(例如RocksDB中的DBCache)，僅使用mmap，***配合文件系統(tǒng)緩存，整個(gè)DB只有mmap的文件系統(tǒng)緩存這一層緩存，再加上超高的壓縮率，大幅降低了內(nèi)存用量，并且極大簡(jiǎn)化了系統(tǒng)的復(fù)雜性，最終完成數(shù)據(jù)庫性能的大幅提升，從而同時(shí)實(shí)現(xiàn)了超高的壓縮率和超高的隨機(jī)讀性能。

從更高的哲學(xué)層面看，我們的存儲(chǔ)引擎很像是用構(gòu)造法推導(dǎo)出來的，因?yàn)镃O-Index和PA-Zip緊密配合，***匹配KeyValue模型，功能上“剛好夠用”，性能上壓榨硬件極限，壓縮率逼近信息論的下限。相比其他方案：

• 傳統(tǒng)塊壓縮是從通用的流式壓縮衍生而來，流式壓縮的功能非常有限，只有壓縮和解壓兩個(gè)操作，對(duì)太小的數(shù)據(jù)塊沒有壓縮效果，也無法壓縮數(shù)據(jù)塊之間的冗余。把它用到數(shù)據(jù)庫上，需要大量的工程努力，就像給汽車裝上飛機(jī)機(jī)翼，然后要讓它飛起來。
• 相比FM-Index，情況則相反，F(xiàn)M-Index的功能非常豐富，它就必然要為此付出一些代價(jià)——壓縮率和性能。而在KeyValue模型中，我們只需要它那些豐富功能的一個(gè)非常小的子集(還要經(jīng)過適配和轉(zhuǎn)化)，其他更多的功能毫無用武之地，卻仍然要付出那些代價(jià)，就像我們花了很高的代價(jià)造了一架飛機(jī)，卻把它按在地上，只用輪子跑，當(dāng)汽車用。 

圖2 用LOUDS方式表達(dá)的Succinct Tree 

圖3 路徑壓縮與嵌套

附錄

壓縮率&性能測(cè)試比較

數(shù)據(jù)集：Amazon movie data

Amazon movie data (~8 million reviews)，數(shù)據(jù)集的總大小約為9GB, 記錄數(shù)大約為800萬條，平均每條數(shù)據(jù)長(zhǎng)度大約1K。

Benchmark代碼開源：參見Github倉庫(https://github.com/Terark/terarkdb-benchmark/tree/master/doc/movies)。

• 壓縮率(見圖4) 

圖4 壓縮率對(duì)比

• 隨機(jī)讀(見圖5) 

圖5 隨機(jī)讀性能對(duì)比

這是在內(nèi)存足夠的情況下，各個(gè)存儲(chǔ)引擎的性能。

• 延遲曲線(見圖6) 

圖6 延遲曲線對(duì)比

數(shù)據(jù)集：Wikipedia英文版

Wikipedia英文版的所有文本數(shù)據(jù)，109G，壓縮到23G。

數(shù)據(jù)集：TPC-H

在TPC-H的lineitem數(shù)據(jù)上，使用TerarkDB和原版RocksDB(BlockBasedTable)進(jìn)行對(duì)比測(cè)試： 

表3 TerarkDB與原版RocksDB對(duì)比測(cè)試

API 接口

TerarkDB = Terark SSTable + RocksDB

RocksDB最初是Facebook對(duì)Google的LevelDB的一個(gè)fork，編程接口上兼容LevelDB，并增加了很多改進(jìn)。

RocksDB對(duì)我們有用的地方在于其SSTable可以plugin，所以我們實(shí)現(xiàn)了一個(gè)RocksDB的SSTable，將我們的技術(shù)優(yōu)勢(shì)通過RocksDB發(fā)揮出來。

雖然RocksDB提供了一個(gè)相對(duì)完整的KeyValueDB框架，但要完全適配我們特有的技術(shù)，仍有一些欠缺，所以需要對(duì)RocksDB本身也做一些修改。將來可能有一天我們會(huì)將自己的修改提交到RocksDB官方版。

Github鏈接：TerarkDB(https://github.com/Terark/terarkdb)，TerarkDB包括兩部分：

• terark-zip-rocksdb(https://github.com/terark/terark-zip-rocksdb)，(Terark SSTable forrocksdb)
• Terark fork rocksdb(https://github.com/Terark/rocksdb)，(必須使用這個(gè)修改版的rocksdb)

為了更好的兼容性，TerarkDB對(duì)RocksDB的API沒有做任何修改，為了進(jìn)一步方便用戶使用TerarkDB，我們甚至提供了一種方式：程序無需重新編譯，只需要替換 librocksdb.so并設(shè)置幾個(gè)環(huán)境變量，就能體驗(yàn)TerarkDB。

如果用戶需要更精細(xì)的控制，可以使用C++ API詳細(xì)配置TerarkDB的各種選項(xiàng)。

目前大家可以免費(fèi)試用，可以做性能評(píng)測(cè)，但是不能用于production，因?yàn)樵囉冒鏁?huì)隨機(jī)刪掉0.1%的數(shù)據(jù)。

Terark命令行工具集

我們提供了一組命令行工具，這些工具可以將輸入數(shù)據(jù)壓縮成不同的形式，壓縮后的文件可以使用Terark API或(該工具集中的)其他命令行工具解壓或定點(diǎn)訪問。

詳情參見Terark wiki中文版(https://github.com/Terark/terark-wiki-zh_cn)。