余丹萍

摘要：傳統(tǒng)的基于關系型數(shù)據(jù)庫的分布式存儲主要通過引入中間件對數(shù)據(jù)進行水平或垂直拆分來實現(xiàn)，這類中間件主要適用查詢主鍵存在單調(diào)遞增或單調(diào)遞減的情況，針對查詢主鍵不符合該要求的，該文設計并實現(xiàn)了一種分布式數(shù)據(jù)存儲方案，基于數(shù)據(jù)庫號段模式生成單調(diào)遞增的分布式ID作為關系型數(shù)據(jù)庫的拆分主鍵，借助MongoDB存儲查詢鍵值和拆分主鍵的關聯(lián)信息。實驗結果表明，該方法可以有效實現(xiàn)海量數(shù)據(jù)的分布式存儲。

關鍵詞：關系型數(shù)據(jù)庫；分布式存儲；分布式ID；海量數(shù)據(jù)

中圖分類號：TP311? ? ? ? 文獻標識碼：A

文章編號：1009-3044（2022）33-0068-03

1 引言

目前比較常用的分布式數(shù)據(jù)存儲[1]方案，主要是在關系型數(shù)據(jù)庫中間加一層數(shù)據(jù)庫分庫中間件，通過將查詢鍵值作為拆分字段，用一定的路由算法，將原始SQL進行解析后構建出新的SQL路由到指定的分節(jié)點，最后對結果集進行歸并。比較常用的中間件有dble[2]、Sharding-sphere[3]等。dble是基于MySQL的高可擴展性的分布式中間件，是基于開源項目MyCat[4]的，但取消了許多其他數(shù)據(jù)庫的支持，專注于MySQL，對兼容性、復雜查詢和分布式事務的行為進行了深入的改進和優(yōu)化，修復了MyCat的一些bug。ShardingSphere是一套開源的分布式數(shù)據(jù)庫中間件解決方案組成的生態(tài)圈，它由Sharding-JDBC、Sharding-Proxy和Sharding-Sidecar這3款相互獨立的產(chǎn)品組成。他們均提供標準化的數(shù)據(jù)分片、分布式事務和數(shù)據(jù)庫治理功能，可適用于如Java同構、異構語言、容器、云原生等各種多樣化的應用場景。這些中間件都有一個特點，主要適用于電商交易、金融交易等查詢主鍵單調(diào)遞增或單調(diào)遞減的場景，選取這類主鍵作為拆分鍵，易于實現(xiàn)數(shù)據(jù)的均勻拆分。對于查詢主鍵不具有單調(diào)遞增或單調(diào)遞減特性，一般通過一致性hash算法[5]進行路由分庫，能做到數(shù)據(jù)的大致均勻拆分，但是當節(jié)點增加時，仍然需要重新遷移一部分數(shù)據(jù)以適應節(jié)點數(shù)量變化帶來的路由結果改變。

針對上述問題，設計了一種分布式數(shù)據(jù)存儲方案，基于高性能非關系型數(shù)據(jù)庫MongoDB [6]存儲查詢鍵值和拆分鍵值的索引信息，實現(xiàn)針對查詢鍵值為完全隨機無序字符串的數(shù)據(jù)存儲的均勻分布，有效降低海量數(shù)據(jù)[7]對單節(jié)點的壓力，提升數(shù)據(jù)的讀寫效率，同時當節(jié)點增加時無須動態(tài)遷移數(shù)據(jù)，實現(xiàn)節(jié)點輕松擴容。

2 相關技術

2.1 分布式ID生成技術

分布式ID在業(yè)務系統(tǒng)中很常用，如電商交易、金融交易等業(yè)務系統(tǒng)中的訂單號，這個ID往往就是數(shù)據(jù)庫中的唯一主鍵，通常需要滿足唯一性、有序性、可用性、安全性等特性：

唯一性：生成的ID全局唯一；

有序性：生成的ID按照某種規(guī)則有序，便于數(shù)據(jù)庫插入和排序；

可用性：在高并發(fā)情況下能正確生成ID；

安全性：不暴露系統(tǒng)和業(yè)務的信息。

常見的分布式ID生成技術主要有數(shù)據(jù)庫自增ID、UUID、REDIS[7]生成ID、SNOWFLAKE雪花算法等。

數(shù)據(jù)庫自增ID使用數(shù)據(jù)庫的ID自增策略，如MYSQL的AUTO_INCREMENT，該方案簡單，生成的ID有序，缺點是在單個數(shù)據(jù)庫或讀寫分離或一主多從的情況下，存在單點故障風險。

UUID通常根據(jù)平臺提供的生成API，按照開放軟件基金會（OSF）制定的標準計算，生成的ID性能非常好，全球唯一，產(chǎn)生重復的概率非常低。缺點是UUID無法保證趨勢遞增，并且往往是使用字符串存儲，查詢效率比較低、存儲空間比較大、傳輸數(shù)據(jù)量大。

REDIS生成ID是利用REDIS的原子操作INCR和INCRBY來實現(xiàn)，性能優(yōu)于數(shù)據(jù)庫，ID有序，缺點是需要編碼和配置的工作量比較大，增加系統(tǒng)復雜度。

SNOWFLAKE雪花算法是Twitter開源的分布式ID生成算法，在生成ID中引入了時間戳，按照時間在單機上是遞增的，性能非常好，缺點是在分布式環(huán)境中，依賴于系統(tǒng)時間的一致性，可能會出現(xiàn)ID沖突。

2.2 分庫策略

在分庫策略的選擇上，比較常用的分庫策略有范圍分片、has取模分片、一致性hash分片等。每種分片策略都有其自身的優(yōu)缺點。

范圍分片：拆分鍵值為自增ID，指定一個數(shù)據(jù)范圍來進行分庫，每一定數(shù)量條記錄分為一個庫，這種分片策略優(yōu)點是擴容非常方便，只需增加新節(jié)點，創(chuàng)建數(shù)據(jù)庫和表即可，不需要對舊的數(shù)據(jù)進行分片遷移。缺點是可能存在IO瓶頸，當業(yè)務的大部分數(shù)據(jù)讀寫都在新節(jié)點的時候，會對新節(jié)點造成比較大的壓力。

hash取模分片：根據(jù)拆分鍵值的hash值mod一個特定的數(shù)值得到的結果即為對應的庫，這種分片策略優(yōu)點是能保證數(shù)據(jù)比較均勻地分散在不同的庫中，減輕數(shù)據(jù)庫的IO壓力。缺點是擴容麻煩，每次擴容的時候都需要對所有數(shù)據(jù)按照新的路由規(guī)則重新計算分片進行遷移分配到不同的庫中。

一致性hash分片：一致性hash算法是將整個hash值空間映射成一個虛擬的圓環(huán)，整個hash空間的取值范圍為0～232-1，將拆分鍵值使用hash算法算出對應的hash值，然后根據(jù)hash值的位置沿圓環(huán)順時針查找，第一個遇到的節(jié)點就是所對應的庫。這種分片策略克服了hash取模分片的不足，當擴容的時候，只需要重定位環(huán)空間中的一小部分數(shù)據(jù)。

3 方案設計

一種分布式數(shù)據(jù)存儲方案基于數(shù)據(jù)庫發(fā)號算法實現(xiàn)生成分布式ID作為數(shù)據(jù)庫拆分鍵，利用MongoDB存儲查詢鍵值和拆分鍵值的索引信息，實現(xiàn)針對查詢鍵值為完全隨機無序字符串的數(shù)據(jù)在關系型數(shù)據(jù)庫存儲的均勻分布。

該方案有3個關鍵之處：一是生成全局分布式ID，二是利用MongoDB存儲與查詢索引信息，三是分庫實現(xiàn)。

3.1 分布式ID生成

設計一種分布式ID生成方案，簡單來說就是數(shù)據(jù)庫中保存了可用的ID號段，系統(tǒng)將可用的號段加載到內(nèi)存中，之后生成的ID會直接從內(nèi)存中產(chǎn)生，當內(nèi)存中的ID用完時，更新數(shù)據(jù)庫可用ID號段，如此反復。為了解決數(shù)據(jù)庫單點問題，可以配置多節(jié)點，每個節(jié)點指定一個不重復的起始ID，按照指定的偏移梯度生成ID。

圖1為分布式ID生成架構圖，有3個數(shù)據(jù)庫節(jié)點發(fā)號，節(jié)點1起始ID設置1，節(jié)點2起始ID設置2，節(jié)點3起始ID設置3，每個節(jié)點按照3的梯度進行ID生成，那么節(jié)點1生成的ID為1、4、7、10、13……，節(jié)點2生成的ID為2、5、8、11、14……，節(jié)點3生成的ID為3、6、9、12、15……，這樣可以保證每個節(jié)點生成的ID都不重復，并且當有節(jié)點宕機的時候生成的ID仍然趨勢遞增。

3.2 索引關系存儲與查詢

由于業(yè)務中的查詢鍵值為完全隨機的字符串，不適合直接用來做分庫拆分鍵，因此設計首先生成分布式ID作為業(yè)務主鍵，同時作為分庫使用的拆分鍵值，利用MongoDB存儲該拆分鍵值和查詢鍵值的索引關系，如圖2所示，指定查詢鍵值作為_id字段，與拆分鍵值建立唯一對應關系存儲于MongoDB中。

關系型數(shù)據(jù)庫中存儲的業(yè)務數(shù)據(jù)如圖3所示，拆分鍵值作為業(yè)務數(shù)據(jù)表的主鍵，其他字段則存儲查詢鍵值和其他業(yè)務數(shù)據(jù)。

當存儲業(yè)務數(shù)據(jù)的時候，首先獲取分布式ID作為業(yè)務數(shù)據(jù)關系數(shù)據(jù)表的主鍵（拆分鍵值），同時建立該主鍵ID與業(yè)務數(shù)據(jù)查詢鍵值的索引關系表存儲于MongoDB中，當索引表在MongoDB中存儲成功后，再對該主鍵ID按照分庫算法，將業(yè)務數(shù)據(jù)路由到指定的關系型數(shù)據(jù)庫中進行存儲。當通過查詢鍵值查詢該條業(yè)務數(shù)據(jù)的時候，首先在MongoDB的索引表中查找出與該查詢鍵值對應的拆分鍵值，再對該拆分鍵值按照與插入時一致的分庫算法，將業(yè)務數(shù)據(jù)從路由到的關系型數(shù)據(jù)庫中查詢出來。同樣的，當需要根據(jù)查詢鍵值更新或刪除業(yè)務數(shù)據(jù)的時候，先根據(jù)該查詢鍵值在MongoDB中查詢得到對應的拆分鍵值，然后根據(jù)同樣的分庫算法路由到對應的關系型數(shù)據(jù)庫中，對對應的業(yè)務數(shù)據(jù)進行更新或刪除。

3.3 分庫實現(xiàn)

結合我們的業(yè)務特點，我們選擇范圍分片對我們的業(yè)務數(shù)據(jù)進行水平拆分。因為范圍分片擴容簡單，而且擴容的時候不需要對原有數(shù)據(jù)做任何遷移，只需要創(chuàng)建新的節(jié)點數(shù)據(jù)庫和數(shù)據(jù)表就可以，并且由于我們的業(yè)務數(shù)據(jù)和電商交易、金融交易的數(shù)據(jù)特點不同，電商交易、金融交易等業(yè)務大部分讀和寫都會訪問新數(shù)據(jù)，會造成新的數(shù)據(jù)節(jié)點的壓力過大，而我們的業(yè)務數(shù)據(jù)主要特點為：

1）數(shù)據(jù)體量大，單庫單表不做拆分的話，數(shù)據(jù)量能達到上億條，這對關系型數(shù)據(jù)庫的壓力非常大。

2）讀數(shù)據(jù)沒有熱點效應，所有數(shù)據(jù)訪問概率相同，對讀取數(shù)據(jù)性能要求較高。

3）寫數(shù)據(jù)的壓力不如電商交易等平臺，最大瞬時壓力單節(jié)點完全可以支撐。

綜合考量，范圍分片可以作為這種業(yè)務數(shù)據(jù)特點的首選，如圖4所示，拆分鍵值為分布式自增ID，每1000萬條記錄分為一個庫，那么主鍵為1到10000000對應的業(yè)務數(shù)據(jù)在節(jié)點1，主鍵為10000001到20000000對應的業(yè)務數(shù)據(jù)在節(jié)點2，依此類推。

4 總結

文中設計了一種分布式數(shù)據(jù)存儲方案，實現(xiàn)針對查詢鍵值為完全隨機無序字符串的業(yè)務數(shù)據(jù)在關系型數(shù)據(jù)庫的均勻拆分存儲，結果表明該方案能有效降低海量數(shù)據(jù)對單節(jié)點的壓力，提升數(shù)據(jù)的讀寫效率，當節(jié)點增加時無須動態(tài)遷移數(shù)據(jù)，實現(xiàn)節(jié)點輕松擴容。

參考文獻：

[1] 宋云奎，吳文鵬，趙磊，等.基于Redis的分布式數(shù)據(jù)存儲方法[J].計算機產(chǎn)品與流通，2020（8）：106.

[2] DBLE分布式中間件[EB/OL]. https：//github.com/actiontech/dble-docs-cn

[3] ShardingSphere概覽[EB/OL].https：//shardingsphere.apache.org/document/legacy/3.x/document/cn/ove-riew

[4] 陳宇收.基于Mycat的分布式數(shù)據(jù)存儲研究[J].中國新通信，2018，20（22）：63-64.

[5] 李寧.基于一致性Hash算法的分布式緩存數(shù)據(jù)冗余[J].軟件導刊，2016，15（1）：47-50.

[6] MongoDB[EB/OL]. https：//www.mongodb.com/docs/

[7] 王艷松，張琦，莊澤巖，等.面向海量數(shù)據(jù)的存儲技術發(fā)展分析[J].通信管理與技術，2021（5）：12-15.

【通聯(lián)編輯：梁書】