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

關(guān)鍵詞：關(guān)系型數(shù)據(jù)庫(kù)；分布式存儲(chǔ)；分布式ID；海量數(shù)據(jù)

中圖分類號(hào)：TP311" " " " 文獻(xiàn)標(biāo)識(shí)碼：A

文章編號(hào)：1009-3044（2022）33-0068-03

1 引言

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

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

2 相關(guān)技術(shù)

2.1 分布式ID生成技術(shù)

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

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

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

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

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

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

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

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

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

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

2.2 分庫(kù)策略

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

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

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

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

3 方案設(shè)計(jì)

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

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

3.1 分布式ID生成

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

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

3.2 索引關(guān)系存儲(chǔ)與查詢

由于業(yè)務(wù)中的查詢鍵值為完全隨機(jī)的字符串，不適合直接用來(lái)做分庫(kù)拆分鍵，因此設(shè)計(jì)首先生成分布式ID作為業(yè)務(wù)主鍵，同時(shí)作為分庫(kù)使用的拆分鍵值，利用MongoDB存儲(chǔ)該拆分鍵值和查詢鍵值的索引關(guān)系，如圖2所示，指定查詢鍵值作為_(kāi)id字段，與拆分鍵值建立唯一對(duì)應(yīng)關(guān)系存儲(chǔ)于MongoDB中。

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

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

3.3 分庫(kù)實(shí)現(xiàn)

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

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

2）讀數(shù)據(jù)沒(méi)有熱點(diǎn)效應(yīng)，所有數(shù)據(jù)訪問(wèn)概率相同，對(duì)讀取數(shù)據(jù)性能要求較高。

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

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

4 總結(jié)

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

參考文獻(xiàn)：

[1] 宋云奎，吳文鵬，趙磊，等.基于Redis的分布式數(shù)據(jù)存儲(chǔ)方法[J].計(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ù)存儲(chǔ)研究[J].中國(guó)新通信，2018，20（22）：63-64.

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

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

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

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