Fusion-NewSQL是由滴滴自研的在分布式KV存儲(chǔ)基礎(chǔ)上構(gòu)建的NewSQL存儲(chǔ)系統(tǒng)。Fusion-NewSQ兼容了MySQL協(xié)議，支持二級(jí)索引功能，提供超大規(guī)模數(shù)據(jù)持久化存儲(chǔ)和高性能讀寫。

滴滴的業(yè)務(wù)快速持續(xù)發(fā)展，數(shù)據(jù)量和請(qǐng)求量急劇增長，對(duì)存儲(chǔ)系統(tǒng)等壓力與日俱增。雖然分庫分表在一定程度上可以解決數(shù)據(jù)量和請(qǐng)求增加的需求，但是由于滴滴多條業(yè)務(wù)線（快車、專車、兩輪車等）的業(yè)務(wù)快速變化，數(shù)據(jù)庫加字段加索引的需求非常頻繁，分庫分表方案對(duì)于頻繁的Schema變更操作并不友好，會(huì)導(dǎo)致DBA任務(wù)繁重，變更周期長，并且對(duì)巨大的表操作還會(huì)對(duì)線上有一定影響。同時(shí)，分庫分表方案對(duì)二級(jí)索引支持不友好或者根本不支持。鑒于上述情況，NewSQL數(shù)據(jù)庫方案就成為我們解決業(yè)務(wù)問題的一個(gè)方向。

最開始，我們調(diào)研了開源的分布式NewSQL方案TiDB。雖然TiDB是非常優(yōu)秀的NewSQL產(chǎn)品，但是對(duì)于我們的業(yè)務(wù)場(chǎng)景來說，TiDB并不是非常適合，原因如下：

基于以上原因，我們開啟了自研符合自己業(yè)務(wù)需求的NewSQL之路。

我們并沒有打算從0開發(fā)一個(gè)完備的NewSQL系統(tǒng)，而是在自研的分布式KV存儲(chǔ)Fusion的基礎(chǔ)上構(gòu)建一個(gè)能滿足我們業(yè)務(wù)場(chǎng)景的NewSQL。Fusion是采用了Codis架構(gòu)，兼容Redis協(xié)議和數(shù)據(jù)結(jié)構(gòu)，使用RocksDB作為存儲(chǔ)引擎的NoSQL數(shù)據(jù)庫。Fusion在滴滴內(nèi)部已經(jīng)有幾百個(gè)業(yè)務(wù)在使用，是滴滴主要的在線存儲(chǔ)之一。

Fusion的架構(gòu)圖如下：

我們采用hash分片的方式來做數(shù)據(jù)sharding。從上往下看，用戶通過Redis協(xié)議的客戶端就可以訪問Fusion，用戶的訪問請(qǐng)求發(fā)到proxy，再由proxy轉(zhuǎn)發(fā)數(shù)據(jù)到后端Fusion的數(shù)據(jù)節(jié)點(diǎn)。proxy到后端數(shù)據(jù)節(jié)點(diǎn)的轉(zhuǎn)發(fā)，是根據(jù)請(qǐng)求的key計(jì)算hash值，然后對(duì)slot分片數(shù)取余，得到一個(gè)固定的slotid，每個(gè)slotid會(huì)固定的映射到一個(gè)存儲(chǔ)節(jié)點(diǎn)，以此解決數(shù)據(jù)路由問題。

有了一個(gè)高并發(fā)，低延遲，大容量的存儲(chǔ)層后，我們要做的就是在之上構(gòu)建MySQL協(xié)議以及二級(jí)索引。那么如何將MySQL的數(shù)據(jù)格式轉(zhuǎn)成Redis的數(shù)據(jù)結(jié)構(gòu)存儲(chǔ)就是我們必須面臨的問題，后面會(huì)詳細(xì)說。

綜合考慮大多數(shù)用戶對(duì)需求，我們整理了我們的NewSQL需要提供的幾個(gè)核心能力：

Fusion-NewSQL由下面幾個(gè)部分組成：

架構(gòu)圖如下：

MySQL的表結(jié)構(gòu)數(shù)據(jù)如何轉(zhuǎn)成Redis的數(shù)據(jù)結(jié)構(gòu)是我們面臨的第一個(gè)問題。

如下圖：

我們將MySQL表的一行記錄轉(zhuǎn)成Redis的一個(gè)Hashmap結(jié)構(gòu)。Hashmap的key由表名+主鍵值組成，滿足了全局唯一的特性。下圖展示了MySQL通過主鍵查詢轉(zhuǎn)換為Redis協(xié)議的方式：

除了數(shù)據(jù)，索引也需要存儲(chǔ)在Fusion-NewSQL中，和數(shù)據(jù)存成hashmap不同，索引存儲(chǔ)成key-value結(jié)構(gòu)。根據(jù)索引類型不同，組成key-value的格式還有一點(diǎn)細(xì)微的差別(下面的格式為了看起來直觀，實(shí)際上分隔符，indexname都是做過編碼的)：

唯一索引：

Key:?

table_indexname_indexColumnsValue?

Value: Rowkey

非唯一索引：

Key:?

table_indexname_indexColumnsValue_Rowkey?

Value：null

造成這種差異的原因就是非唯一索引在加入Rowkey之前的部分是有可能重復(fù)的，無法全局唯一。另外，唯一索引不將Rowkey編碼在key中，是因?yàn)樵诓樵冋Z句是單純的“=”查詢的時(shí)候直接get操作就可以找到對(duì)應(yīng)的Rowkey內(nèi)容，而不需要通過scan，這樣的效率更高。

后面會(huì)在查詢流程中重點(diǎn)講述如何通過二級(jí)索引查詢到數(shù)據(jù)。

1）數(shù)據(jù)寫入

通過上面的鏈路，用戶的一條MySQL寫操作就完成了數(shù)據(jù)存儲(chǔ)和索引構(gòu)建。由于通過數(shù)據(jù)構(gòu)建索引這一步是通過MQ異步完成，所以會(huì)存在數(shù)據(jù)和索引有一定的時(shí)間差的情況。

2）查詢

下面是一個(gè)使用二級(jí)索引查詢數(shù)據(jù)的案例：

根據(jù)上面索引數(shù)據(jù)的格式可以看到，scan范圍的時(shí)候，前綴必須固定，映射到SQL語句到時(shí)候，意味著where到條件中，范圍查詢只能有一個(gè)字段，而不能多個(gè)字段。比如：

索引是age和name兩個(gè)字段的聯(lián)合索引。如果查詢語句如下：

scan就沒有辦法確定前綴，也就無法通過index_age_name這個(gè)索引查詢到滿足條件的數(shù)據(jù)，所以使用KV形式存儲(chǔ)到索引只能滿足where條件中有一個(gè)字段是范圍查詢。當(dāng)然可以通過將聯(lián)合索引分開存放，多次交互搜索取交集的方式解決，但是這就和我們降低RPC次數(shù)，降低延遲的設(shè)計(jì)初衷相違背了。為了解決這個(gè)問題，我們引入了Elastic Search搜索引擎，這部分后面會(huì)詳細(xì)說明。

用戶涉及Schema變更時(shí)，會(huì)以工單形式發(fā)給管控系統(tǒng)。管控系統(tǒng)審批過后，會(huì)將變更請(qǐng)求推給配置中心，配置中心進(jìn)行安全性檢查后，將新的Schema寫入到存儲(chǔ)中，并給各個(gè)節(jié)點(diǎn)推送變更。

字段變更：

節(jié)點(diǎn)接收到推送，更新本地的Schema。對(duì)于歷史數(shù)據(jù)，并不真正去修改數(shù)據(jù)，而是在查詢的時(shí)候，根據(jù)Schema信息匹配字段，如果數(shù)據(jù)比Schema缺失某些字段，就使用默認(rèn)值代替;如果數(shù)據(jù)比Schema多了字段，就隱藏掉多余字段不展示。

新增索引分為兩步處理：

一個(gè)單獨(dú)的存儲(chǔ)產(chǎn)品解決所有問題的時(shí)代早已經(jīng)過去，數(shù)據(jù)孤島是沒有辦法很好服務(wù)業(yè)務(wù)的，F(xiàn)usion-NewSQL從設(shè)計(jì)的那天起就考慮了和其他存儲(chǔ)系統(tǒng)的打通。

Fusion-NewSQL通過兼容MySQL的Binlog格式，將數(shù)據(jù)發(fā)到MQ中。下游各個(gè)系統(tǒng)凡是能接入MySQL數(shù)據(jù)的，都可以通過消費(fèi)MQ中相同格式的Fusion-NewSQL數(shù)據(jù)，將數(shù)據(jù)存到其他系統(tǒng)中。這樣的方式用最小的工作量最大程度做到了兼容。

Fusion-NewSQL還支持將離線的Hive表中的數(shù)據(jù)通過Fusion-NewSQL提供的FastLoad（DTS）工具，將Hive表數(shù)據(jù)轉(zhuǎn)入到Fusion-NewSQL，滿足離線數(shù)據(jù)到在線的數(shù)據(jù)流動(dòng)。

如果用戶自己完成數(shù)據(jù)流轉(zhuǎn)，一般會(huì)掃描Hive表，然后構(gòu)建MySQL的寫入語句，一條條將數(shù)據(jù)寫入到Fusion-NewSQL，流程如下面這樣：

從上面的流程可以看出這種遷移方式有幾個(gè)痛點(diǎn)：

基于上述的痛點(diǎn)，我們?cè)O(shè)計(jì)了Fastload數(shù)據(jù)導(dǎo)入平臺(tái)，通過約定Hive到Fusion-NewSQL的表格式，使用Hadoop并發(fā)處理數(shù)據(jù)，并構(gòu)建RocksDB能識(shí)別的sst存儲(chǔ)文件，繞過復(fù)雜的DISE寫鏈路，直接將數(shù)據(jù)導(dǎo)入到Fusion-NewSQL中，流程如下：

這個(gè)方案避免了冗長復(fù)雜的寫鏈路，同時(shí)不會(huì)增加系統(tǒng)的QPS，在磁盤和網(wǎng)絡(luò)IO沒有達(dá)到瓶頸的情況下對(duì)線上訪問幾乎是沒有任何影響；同時(shí)，用戶只需要填寫Hive到Fusion-NewSQL的Schema映射關(guān)系即可，不必再關(guān)心實(shí)現(xiàn)。

在業(yè)務(wù)使用MySQL或Fusion-NewSQL的過程中，我們發(fā)現(xiàn)有這樣一種場(chǎng)景：業(yè)務(wù)的查詢條件很復(fù)雜，涉及的字段數(shù)，條件，聚合都比較多，這種場(chǎng)景下，業(yè)務(wù)會(huì)選擇將ElasticSearch作為MySQL或Fusion-NewSQL的下游，將數(shù)據(jù)導(dǎo)入Elastic Search，然后通過ElasticSearch豐富的搜索能力，先從ElasticSearch中獲取數(shù)據(jù)在MySQL或Fusion-NewSQL的主鍵，然后再根據(jù)主鍵獲取全部數(shù)據(jù)。

根據(jù)上面的場(chǎng)景，F(xiàn)usion-NewSQL提供一個(gè)特殊的索引類型：ES。用戶在創(chuàng)建索引的時(shí)候，可以將需要做復(fù)雜查詢的字段勾選出來，共同構(gòu)建成一個(gè)ES索引，這樣既滿足了業(yè)務(wù)需求，避免了每個(gè)業(yè)務(wù)都需要開發(fā)一套和ElasticSearch交互的復(fù)雜邏輯，又統(tǒng)一了數(shù)據(jù)庫使用接口都為MySQL。同時(shí)，還彌補(bǔ)了前面提到的Fusion-NewSQL的KV二級(jí)索引不能支持多個(gè)字段范圍檢索的能力。

架構(gòu)圖如下：

ES索引只是在上圖紅4處，將ES索引中包含的字段信息和主鍵寫入到ElasticSearch中。在查詢時(shí)綠1如果選中了ES類型的索引，就根據(jù)where條件中涉及的字段，組裝成ElasticSearch的DSL語句，從ElasticSearch獲取主鍵，再從Data集群獲取。由于ElasticSearch查詢的延遲比較慢，F(xiàn)usion-NewSQL可以支持一張表的多個(gè)索引采用KV索引和ES索引并存，對(duì)于延遲要求高，查詢條件相對(duì)簡(jiǎn)單的使用KV索引；對(duì)于查詢條件復(fù)雜，延遲要求不高的使用ES索引。

Fusion-NewSQL當(dāng)前已經(jīng)接入訂單、預(yù)估、賬單、用戶中心、交易引擎等70個(gè)核心業(yè)務(wù)，總QPS超過200W，總數(shù)據(jù)超過600TB。

當(dāng)然，F(xiàn)usion-New不是一個(gè)通用完備的NewSQL方案，而是在已有的NoSQL數(shù)據(jù)庫基礎(chǔ)上，通過對(duì)SQL協(xié)議的支持以及組合各種組件，構(gòu)建一個(gè)對(duì)外表達(dá)的數(shù)據(jù)庫，但是這種方式，可以以最小的開發(fā)代價(jià)，滿足大多數(shù)的業(yè)務(wù)場(chǎng)景，具備較高的投入產(chǎn)出比。?

歷史推薦


再見！RxJava
愛奇藝視頻如何使用微服務(wù)的？
知乎1.3萬億條數(shù)據(jù)查詢毫秒級(jí)響應(yīng)，如何做到的？
為什么程序員都不喜歡使用switch，而是大量的 if……else if ？
PG Vs MySQL ，到底誰更強(qiáng)？
好文點(diǎn)個(gè)在看吧！