余丹萍

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

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

針對上述問題，設(shè)計(jì)了一種分布式數(shù)據(jù)存儲(chǔ)方案，基于高性能非關(guān)系型數(shù)據(jù)庫MongoDB [6]存儲(chǔ)查詢鍵值和拆分鍵值的索引信息，實(shí)現(xiàn)針對查詢鍵值為完全隨機(jī)無序字符串的數(shù)據(jù)存儲(chǔ)的均勻分布，有效降低海量數(shù)據(jù)[7]對單節(jié)點(diǎn)的壓力，提升數(shù)據(jù)的讀寫效率，同時(shí)當(dāng)節(jié)點(diǎn)增加時(shí)無須動(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ù)庫中的唯一主鍵，通常需要滿足唯一性、有序性、可用性、安全性等特性：

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

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

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

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

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

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

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

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

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

2.2 分庫策略

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

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

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

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

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

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

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

3.1 分布式ID生成

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

圖1為分布式ID生成架構(gòu)圖，有3個(gè)數(shù)據(jù)庫節(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仍然趨勢遞增。

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

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

關(guān)系型數(shù)據(jù)庫中存儲(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ǔ)成功后，再對該主鍵ID按照分庫算法，將業(yè)務(wù)數(shù)據(jù)路由到指定的關(guān)系型數(shù)據(jù)庫中進(jìn)行存儲(chǔ)。當(dāng)通過查詢鍵值查詢該條業(yè)務(wù)數(shù)據(jù)的時(shí)候，首先在MongoDB的索引表中查找出與該查詢鍵值對應(yīng)的拆分鍵值，再對該拆分鍵值按照與插入時(shí)一致的分庫算法，將業(yè)務(wù)數(shù)據(jù)從路由到的關(guān)系型數(shù)據(jù)庫中查詢出來。同樣的，當(dāng)需要根據(jù)查詢鍵值更新或刪除業(yè)務(wù)數(shù)據(jù)的時(shí)候，先根據(jù)該查詢鍵值在MongoDB中查詢得到對應(yīng)的拆分鍵值，然后根據(jù)同樣的分庫算法路由到對應(yīng)的關(guān)系型數(shù)據(jù)庫中，對對應(yīng)的業(yè)務(wù)數(shù)據(jù)進(jìn)行更新或刪除。

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

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

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

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

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

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

4 總結(jié)

文中設(shè)計(jì)了一種分布式數(shù)據(jù)存儲(chǔ)方案，實(shí)現(xiàn)針對查詢鍵值為完全隨機(jī)無序字符串的業(yè)務(wù)數(shù)據(jù)在關(guān)系型數(shù)據(jù)庫的均勻拆分存儲(chǔ)，結(jié)果表明該方案能有效降低海量數(shù)據(jù)對單節(jié)點(diǎn)的壓力，提升數(shù)據(jù)的讀寫效率，當(dāng)節(jié)點(diǎn)增加時(shí)無須動(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].中國新通信，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)編輯：梁書】