作者介紹

李鑫，滴滴資深軟件開發(fā)工程師，多年分布式存儲領域設計及開發(fā)經(jīng)驗。曾參與NoSQL/NewSQL數(shù)據(jù)庫Fusion、分布式時序數(shù)據(jù)庫sentry、NewSQL數(shù)據(jù)庫SDB等系統(tǒng)的設計開發(fā)工作。

一、背景

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

我們的問題

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

開源產(chǎn)品調(diào)研

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

• 我們需要一款高吞吐，低延遲的數(shù)據(jù)庫解決方案，但是TiDB由于要滿足事務，2pc方案天然無法滿足低延遲(100ms以內(nèi)的99rt，甚至50ms內(nèi)的99rt)。

• 我們的多數(shù)業(yè)務，并不真正需要分布式事務，或者說可以通過其他補償機制，繞過分布式事務。這是由于業(yè)務場景決定的。

• TiDB三副本的存儲空間成本相對比較高。

• 我們內(nèi)部一些離線數(shù)據(jù)導入在線系統(tǒng)的場景，不能直接和TiDB打通。

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

我們的基礎

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

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

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

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

二、需求

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

• 高吞吐，低延遲，大容量。

• 兼容MySQL協(xié)議及下游生態(tài)。

• 支持主鍵查詢和二級索引查詢。

• Schema變更靈活，不影響線上服務穩(wěn)定性。

三、架構(gòu)設計

Fusion-NewSQL由下面幾個部分組成：

• 解析MySQL協(xié)議的DiseServer；

• 存儲數(shù)據(jù)的Fusion集群-Data集群；

• 存儲索引信息的Fusion集群-Index集群；

• 負責Schema的管理配置中心-ConfigServer；

• 異步構(gòu)建索引程序-Consumer負責消費Data集群寫到MQ中的MySQL-Binlog格式數(shù)據(jù)，根據(jù)schema信息，生成索引數(shù)據(jù)寫入Index集群；

• 外部依賴，MQ，Zookeeper。

架構(gòu)圖如下：

四、詳細設計

存儲結(jié)構(gòu)

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

如下圖：

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

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

唯一索引：

Key:?

table_indexname_indexColumnsValue?

Value: Rowkey

非唯一索引：

Key:?

table_indexname_indexColumnsValue_Rowkey?

Value：null

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

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

數(shù)據(jù)讀寫流程

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

• 用戶通過MySQL-sdk將協(xié)議發(fā)給dise-server；

• dise-server根據(jù)schema對用戶寫入的SQL做校驗；

• dise-server將校驗通過的SQL轉(zhuǎn)成Redis的Hashmap結(jié)構(gòu)，通過Redis協(xié)議發(fā)給Data集群；

• Data集群將數(shù)據(jù)寫入wal文件，并將數(shù)據(jù)存儲rocksdb；

• Data集群后臺線程將wal文件消費，轉(zhuǎn)成MySQL-Binlog格式。將數(shù)據(jù)發(fā)到MQ；

• 異步索引模塊消費MQ，將MySQL-Binlog根據(jù)操作類型(insert，update,delete)配合schema信息，構(gòu)建索引信息，并將索引數(shù)據(jù)寫入index集群。

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

2)查詢

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

• dise-server接收到SQL查詢，根據(jù)條件，選擇索引，如果沒有命中任何索引，給用戶返回錯誤(Fusion-NewSQL不能以非索引字段作為查詢條件)。

• 根據(jù)選中的索引，構(gòu)建查詢范圍，通過scan命令遍歷Index集群，獲取符合條件的主鍵集合。下圖以一個SQL查詢，展示使用scan遍歷二級索引的例子：

• 根據(jù)主鍵，通過hgetall命令向Data集群查詢符合條件的結(jié)果集。

• 將結(jié)果集構(gòu)建成MySQL的結(jié)果返回給用戶。

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

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

select * from student where age > 20 and name >‘W’;

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

Schema變更

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

字段變更：

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

新增索引分為兩步處理：

• 新增索引，歷史數(shù)據(jù)不處理，增量數(shù)據(jù)立刻走索引構(gòu)建流程。

• 通過歷史索引構(gòu)建工具，掃描歷史數(shù)據(jù)，構(gòu)建新索引的KV，將歷史數(shù)據(jù)完成索引構(gòu)建。這里有個優(yōu)化點，掃描slave而不是master，避免對線上產(chǎn)生影響。

五、生態(tài)構(gòu)建

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

Fusion-NewSQL到其他存儲系統(tǒng)

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

Hive到Fusion-NewSQL

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

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

• MySQL-client將寫請求發(fā)給DiseServer。

• DiseServer將MySQL寫做解析，轉(zhuǎn)成hashmap將轉(zhuǎn)換后的數(shù)據(jù)以Redis協(xié)議發(fā)給Data集群。

• Data集群的存儲節(jié)點收到數(shù)據(jù)，將數(shù)據(jù)寫到wal文件。

• Data集群的存儲節(jié)點走RocksDB的寫流程，這里包括了寫memtable，還有可能memtable寫滿，發(fā)生flush以及觸發(fā)后臺的compact。

• 異步線程消費wal，將數(shù)據(jù)構(gòu)建MySQL-Binlog格式發(fā)到MQ。

• 異步索引程序消費MySQL-Binlog，構(gòu)建Index集群需要的數(shù)據(jù)，向Index集群發(fā)送寫入請求。

• Index集群的存儲節(jié)點寫wal。

• Index集群的存儲節(jié)點進入RocksDB的寫流程。

從上面的流程可以看出這種遷移方式有幾個痛點：

• 有這種Hive到Fusion-NewSQL數(shù)據(jù)導入需求的用戶都需要開發(fā)一套相同邏輯的代碼，維護成本高。

• 每條Hive數(shù)據(jù)都要經(jīng)過較長鏈路，數(shù)據(jù)導入耗時較長。

• 離線平臺的數(shù)據(jù)量大，吞吐高，直接大幅提升在線系統(tǒng)的QPS，對在線系統(tǒng)的穩(wěn)定性有較大影響。

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

• 用戶填寫工單，選中將指定Hive表的某些字段映射為Fusion-NewSQL表的字段(這里可以Hive中多個字段組成一個Fusion-NewSQL字段)。

• Hadoop遍歷Hive表，并且通過Zookeeper獲取數(shù)據(jù)應該存放在Data集群和Index集群的路由信息。

• 通過上面的遍歷，計算，之后，將數(shù)據(jù)直接構(gòu)建成、Rocksdb能識別的sst，并且其中存的數(shù)據(jù)已經(jīng)是按DISE的表結(jié)構(gòu)信息組成的KV數(shù)據(jù)。

• 將sst文件直接發(fā)送到指定的存儲節(jié)點，存儲節(jié)點或通過Rocksdb提供的ingest功能，直接將sst文件加載到Fusion-NewSQL中，用戶可以讀到。

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

通過ElasticSearch實現(xiàn)復雜查詢

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

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

架構(gòu)圖如下：

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

六、總結(jié)

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

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

七、后續(xù)工作

• 有限制的事物支持，比如讓業(yè)務規(guī)劃落在一個節(jié)點的數(shù)據(jù)可以支持單機跨行事務。

• 實時索引替代異步索引，滿足即寫即讀。目前已經(jīng)有一個寫穿+補償機制的方案，在沒有分布式事務的前提下滿足正常狀態(tài)的實時索引，異常情況下保證數(shù)據(jù)索引最終一致的方案。

• 更多的SQL協(xié)議和功能支持。

作者丨李鑫來源丨滴滴技術(ID：didi_tech)

參與相關討論，請在公眾號回復關鍵詞：讀者群。

參與相關討論，請在公眾號回復關鍵詞：讀者群。

往期推薦

? ??? ?架構(gòu)師技術領導力成長之路

• 初創(chuàng)型公司，如何選擇技術方案？

• 單機和分布式場景下，流控方案大全

• 干貨 | 攜程容器偶發(fā)性超時問題案例

• DDD如何講清楚，做出來？

? ? ???……

? ?關注本公眾號，歡迎訂閱。

技術瑣話?

以分布式設計、架構(gòu)、體系思想為基礎，兼論研發(fā)相關的點點滴滴，不限于代碼、質(zhì)量體系和研發(fā)管理。本號由坐館老司機技術團隊維護。

總結(jié)

以上是生活随笔為你收集整理的select选择框必输校验_轮子这么多，我们为什么选择自研NewSQL的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

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