數(shù)據(jù)分表小結(jié)

標(biāo)簽： sharding 數(shù)據(jù)表拆分

成都網(wǎng)站建設(shè)哪家好，找成都創(chuàng)新互聯(lián)公司！專注于網(wǎng)頁(yè)設(shè)計(jì)、網(wǎng)站建設(shè)、微信開發(fā)、微信平臺(tái)小程序開發(fā)、集團(tuán)成都定制網(wǎng)站等服務(wù)項(xiàng)目。核心團(tuán)隊(duì)均擁有互聯(lián)網(wǎng)行業(yè)多年經(jīng)驗(yàn)，服務(wù)眾多知名企業(yè)客戶；涵蓋的客戶類型包括：成都辦公空間設(shè)計(jì)等眾多領(lǐng)域，積累了大量豐富的經(jīng)驗(yàn)，同時(shí)也獲得了客戶的一致表?yè)P(yáng)！

• 背景
• 分庫(kù)、分表帶來(lái)的后遺癥
• 分表策略
• 一些注意事項(xiàng)

背景

最近一段時(shí)間內(nèi)結(jié)束了數(shù)據(jù)庫(kù)表拆分項(xiàng)目，這里做個(gè)簡(jiǎn)單的小結(jié)。

本次拆分主要包括訂單和優(yōu)惠券兩大塊，這兩塊都是覆蓋全集團(tuán)所有分子公司所有業(yè)務(wù)線。隨著公司的業(yè)務(wù)飛速發(fā)展，不管是存儲(chǔ)的要求，還是寫入、讀取的性都基本上到了警戒水位。

訂單是交易的核心，優(yōu)惠券是營(yíng)銷的核心，這兩塊基本上是整個(gè)平臺(tái)的正向最核心部分。為了支持未來(lái)三到五年的快速發(fā)展，我們需要對(duì)數(shù)據(jù)進(jìn)行拆分。

數(shù)據(jù)庫(kù)表拆分業(yè)內(nèi)已經(jīng)有很多成熟方案，已經(jīng)不是什么高深的技術(shù)，基本上是純工程化的流程，但是能有機(jī)會(huì)進(jìn)行實(shí)際的操刀一把機(jī)會(huì)還是難得，所以非常有必要做個(gè)總結(jié)。

由于分庫(kù)分表包含的技術(shù)選型和方式方法多種多樣，這篇文章不是羅列和匯總介紹各種方法，而是總結(jié)我們?cè)趯?shí)施分庫(kù)分表過(guò)程中的一些經(jīng)驗(yàn)。

根據(jù)業(yè)務(wù)場(chǎng)景判斷，我們主要是做水平拆分，做邏輯 DB拆分，考慮到未來(lái)數(shù)據(jù)庫(kù)寫入瓶頸可以將一組 sharding表直接遷移進(jìn)分庫(kù)中。

分庫(kù)、分表帶來(lái)的后遺癥

分庫(kù)、分表會(huì)帶來(lái)很多的后遺癥，會(huì)使整個(gè)系統(tǒng)架構(gòu)變的復(fù)雜。分的好與不好最關(guān)鍵就是如何尋找那個(gè) sharding key，如果這個(gè) sharding key剛好是業(yè)務(wù)維度上的分界線就會(huì)直接提升性能和改善復(fù)雜度，否則就會(huì)有各種腳手架來(lái)支撐，系統(tǒng)也就會(huì)變得復(fù)雜。

比如訂單系統(tǒng)中的用戶ID、訂單type、商家ID、渠道ID，優(yōu)惠券系統(tǒng)中的批次ID、渠道ID、機(jī)構(gòu)ID等，這些都是潛在的 sharding key。

如果剛好有這么一個(gè) sharding key存在后面處理路由（routing）就會(huì)很方便，否則就需要一些大而全的索引表來(lái)處理 OLAP的查詢。

一旦 sharding之后首先要面對(duì)的問題就是查詢時(shí)排序分頁(yè)問題。

歸并排序

原來(lái)在一個(gè)數(shù)據(jù)庫(kù)表中處理排序分頁(yè)是比較方便的，sharding之后就會(huì)存在多個(gè)數(shù)據(jù)源，這里我們將多個(gè)數(shù)據(jù)源統(tǒng)稱為分片。

想要實(shí)現(xiàn)多分片排序分頁(yè)就需要將各個(gè)片的數(shù)據(jù)都匯集起來(lái)進(jìn)行排序，就需要用到 歸并排序算法。這些數(shù)據(jù)在各個(gè)分片中可以做到有序的（輸出有序），但是整體上是無(wú)序的。

我們看個(gè)簡(jiǎn)單的例子：

shard node 1: {1、3、5、7、9}
shard node 2: {2、4、6、8、10}

這是做 奇偶 sharding的兩個(gè)分片，我們假設(shè)分頁(yè)參數(shù)設(shè)置為每頁(yè)4條，當(dāng)前第1頁(yè)，參數(shù)如下：

pageParameter：pageSize：4、currentPage：1

最樂觀情況下我們需要分別讀取兩個(gè)分片節(jié)點(diǎn)中的前兩條：

shard node 1: {1、3}
shard node 2: {2、4}

排序完剛好是 {1、2、3、4}，但是這種場(chǎng)景基本上不太可能出現(xiàn)，假設(shè)如下分片節(jié)點(diǎn)數(shù)據(jù)：

shard node 1: {7、9、11、13、15}
shard node 2: {2、4、6、8、10、12、14}

我們還是按照讀取每個(gè)節(jié)點(diǎn)前兩條肯定是錯(cuò)誤的，因?yàn)樽畋^情況下也是最真實(shí)的情況就是排序完后所有的數(shù)據(jù)都來(lái)自一個(gè)分片。所以我們需要讀取每個(gè)節(jié)點(diǎn)的 pageSize大小的數(shù)據(jù)出來(lái)才有可能保證數(shù)據(jù)的正確性。

這個(gè)例子只是假設(shè)我們的查詢條件輸出的數(shù)據(jù)剛好是均等的，真實(shí)的情況一定是各種各樣的查詢條件篩選出來(lái)的數(shù)據(jù)集合，此時(shí)這個(gè)數(shù)據(jù)一定不是這樣的排列方式，最真實(shí)的就是最后者這種結(jié)構(gòu)。

我們以此類推，如果我們的 currentPage:1000那么會(huì)出現(xiàn)什么問題，我們需要每個(gè) sharding node讀取 4000(1000*4=4000)條數(shù)據(jù)出來(lái)排序，因?yàn)樽畋^情況下有可能所有的數(shù)據(jù)均來(lái)自一個(gè) sharding node。

這樣無(wú)限制的翻頁(yè)下去，處理排序分頁(yè)的機(jī)器肯定會(huì)內(nèi)存撐爆，就算不撐爆一定會(huì)觸發(fā)性能瓶頸。

這個(gè)簡(jiǎn)單的例子用來(lái)說(shuō)明分片之后，排序分頁(yè)帶來(lái)的現(xiàn)實(shí)問題，這也有助于我們理解分布式系統(tǒng)在做多節(jié)點(diǎn)排序分頁(yè)時(shí)為什么有最大分頁(yè)限制。

深分頁(yè)性能問題-改變查詢條件重新分頁(yè)

一個(gè)龐大的數(shù)據(jù)集會(huì)通過(guò)多種方式進(jìn)行數(shù)據(jù)拆分，按機(jī)構(gòu)、按時(shí)間、按渠道等等，拆分在不同的數(shù)據(jù)源中。一般的深分頁(yè)問題我們可以通過(guò)改變查詢條件來(lái)平滑解決，但是這種方案并不能解決所有的業(yè)務(wù)場(chǎng)景。

比如，我們有一個(gè)訂單列表，從C端用戶來(lái)查詢自己的訂單列表數(shù)據(jù)量不會(huì)很大，但是運(yùn)營(yíng)后臺(tái)系統(tǒng)可能面對(duì)全平臺(tái)的所有訂單數(shù)據(jù)量，所以數(shù)據(jù)量會(huì)很大。

改變查詢條件有兩種方式，一種是顯示的設(shè)置，盡量縮小查詢范圍，這種設(shè)置一般都會(huì)優(yōu)先考慮，比如時(shí)間范圍、支付狀態(tài)、配送狀態(tài)等等，通過(guò)多個(gè)疊加條件就可以橫豎過(guò)濾出很小一部分?jǐn)?shù)據(jù)集。

那么第二種條件為隱式設(shè)置。比如訂單列表通常是按照訂單創(chuàng)建時(shí)間來(lái)排序，那么當(dāng)翻頁(yè)到限制的條件時(shí)，我們可以改變這個(gè)時(shí)間。

sharding node 1:
orderID     createDateTime
100000      2018-01-10 10:10:10
200000      2018-01-10 10:10:11
300000      2018-01-10 10:10:12
400000      2018-01-10 10:10:13
500000      2018-01-20 10:10:10
600000      2018-01-20 10:10:11
700000      2018-01-20 10:10:12

sharding node 2:
orderID     createDateTime
110000      2018-01-11 10:10:10
220000      2018-01-11 10:10:11
320000      2018-01-11 10:10:12
420000      2018-01-11 10:10:13
520000      2018-01-21 10:10:10
620000      2018-01-21 10:10:11
720000      2018-01-21 10:10:12

我們假設(shè)上面是一個(gè)訂單列表，orderID訂單號(hào)大家就不要在意順序性了。因?yàn)?sharding之后所有的 orderID都會(huì)由發(fā)號(hào)器統(tǒng)一發(fā)放，多個(gè)集群多個(gè)消費(fèi)者同時(shí)獲取，但是創(chuàng)建訂單的速度是不一樣的，所以順序性已經(jīng)不存在了。

上面的兩個(gè) sharding node基本上訂單號(hào)是交叉的，如果按照時(shí)間排序 node 1和 node 2是要交替獲取數(shù)據(jù)。

比如我們的查詢條件和分頁(yè)參數(shù)：

where createDateTime>'2018-01-11 00:00:00'

pageParameter：pageSize：5、currentPage：1

獲取的結(jié)果集為：

orderID     createDateTime
100000      2018-01-10 10:10:10
200000      2018-01-10 10:10:11
300000      2018-01-10 10:10:12
400000      2018-01-10 10:10:13
110000      2018-01-11 10:10:10

前面 4 條記錄來(lái)自 node 1后面 1 條數(shù)據(jù)來(lái)自 node 2，整個(gè)排序集合為：

sharding node 1:
orderID     createDateTime
100000      2018-01-10 10:10:10
200000      2018-01-10 10:10:11
300000      2018-01-10 10:10:12
400000      2018-01-10 10:10:13
500000      2018-01-20 10:10:10

sharding node 2:
orderID     createDateTime
110000      2018-01-11 10:10:10
220000      2018-01-11 10:10:11
320000      2018-01-11 10:10:12
420000      2018-01-11 10:10:13
520000      2018-01-21 10:10:10

按照這樣一直翻頁(yè)下去每翻頁(yè)一次就需要在 node 1 、node 2多獲取 5 條數(shù)據(jù)。這里我們可以通過(guò)修改查詢條件來(lái)讓整個(gè)翻頁(yè)變?yōu)橹匦虏樵儭?/p>

where createDateTime>'2018-01-11 10:10:13'

因?yàn)槲覀兛梢源_定在 ‘2018-01-11 10:10:13’ 時(shí)間之前所有的數(shù)據(jù)都已經(jīng)查詢過(guò)，但是為什么時(shí)間不是從 ‘2018-01-21 10:10:10’ 開始，因?yàn)槲覀円紤]并發(fā)情況，在 1s 內(nèi)會(huì)有多個(gè)訂單進(jìn)來(lái)。

這種方式是實(shí)現(xiàn)最簡(jiǎn)單，不需要借助外部的計(jì)算來(lái)支撐。這種方式有一個(gè)問題就是要想重新計(jì)算分頁(yè)的時(shí)候不丟失數(shù)據(jù)就需要保留原來(lái)一條數(shù)據(jù)，這樣才能知道開始的時(shí)間在哪里，這樣就會(huì)在下次的分頁(yè)中看到這條時(shí)間。但是從真實(shí)的深分頁(yè)場(chǎng)景來(lái)看也可以忽略，因?yàn)楹苌儆腥藭?huì)一頁(yè)一頁(yè)一直到翻到500頁(yè)，而是直接跳到最后幾頁(yè)，這個(gè)時(shí)候就不存在那個(gè)問題。

如果非要精準(zhǔn)控制這個(gè)偏差就需要記住區(qū)間，或者用其他方式來(lái)實(shí)現(xiàn)了，比如全量查詢表、sharding 索引表、最大下單 tps值之類的，用來(lái)輔助計(jì)算。

（可以利用數(shù)據(jù)同步中間件建立單表多級(jí)索引、多表多維度索引來(lái)輔助計(jì)算。我們使用到的數(shù)據(jù)同步中間件有 datax、yugong、otter、canal可以解決全量、增量同步問題）。

分表策略

分表有多種方式，mod、rang、presharding、自定義路由，每種方式都有一定的側(cè)重。

我們主要使用 mod + presharding的方式，這種方式帶來(lái)的最大的一個(gè)問題就是后期的節(jié)點(diǎn)變動(dòng)數(shù)據(jù)遷移問題，可以通過(guò)參考一致性 hash算法的虛擬節(jié)點(diǎn)來(lái)解決。

數(shù)據(jù)表拆分和 cache sharding有一些區(qū)別，cache能接受 cache miss，通過(guò)被動(dòng)緩存的方式可以維護(hù)起 cache數(shù)據(jù)。但是數(shù)據(jù)庫(kù)不存在 select miss這種場(chǎng)景。

在 cache sharding場(chǎng)景下一致性 hash可以用來(lái)消除減少、增加 sharding node時(shí)相鄰分片壓力問題。 但是數(shù)據(jù)庫(kù)一旦出現(xiàn)數(shù)據(jù)遷移一定是不能接受數(shù)據(jù)查詢不出來(lái)的。所以我們?yōu)榱藢?lái)數(shù)據(jù)的平滑遷移，做了一個(gè) 虛擬節(jié)點(diǎn) + 真實(shí)節(jié)點(diǎn) mapping。

physics node : node 1 node 2 node 3 node 4
virtual node : node 1 node 2 node 3.....node 20

node mapping :
virtual node 1 ~ node 5 {physics node 1}
virtual node 6 ~ node 10 {physics node 2}
virtual node 11 ~ node 15 {physics node 3}
virtual node 16 ~ node 20 {physics node 4}

為了減少將來(lái)遷移數(shù)據(jù)時(shí) rehash的成本和延遲的開銷，將 hash后的值保存在表里，將來(lái)遷移直接查詢出來(lái)快速導(dǎo)入。

hash 片 2 的次方問題

在我們熟悉的 hashmap里，為了減少?zèng)_突和提供一定的性能將 hash桶的大小設(shè)置成 2 的 n 次方，然后采用 hash&(legnth-1)位與的方式計(jì)算，這樣主要是大師們發(fā)現(xiàn) 2 的 n 次方的二進(jìn)制除了高位是 0 之外所有地位都是 1，通過(guò)位與可以快速反轉(zhuǎn)二進(jìn)制然后地位加 1 就是最終的值。

我們?cè)谧鰯?shù)據(jù)庫(kù) sharding的時(shí)候不需要參考這一原則，這一原則主要是為了程序內(nèi)部 hash表使用，外部我們本來(lái)就是要 hash mod確定 sharding node。

通過(guò) mod取模的方式會(huì)出現(xiàn)不均勻問題，在此基礎(chǔ)上可以做個(gè) 自定義奇偶路由，這樣可以均勻兩邊的數(shù)據(jù)。

一些注意事項(xiàng)

1.在現(xiàn)有項(xiàng)目中集成 sharding-JDBC 有一些小問題，sharding-jdbc 不支持批量插入，如果項(xiàng)目中已經(jīng)使用了大量的批量插入語(yǔ)句就需要改造，或者使用 輔助hash計(jì)算物理表名，在批量插入。

2.原有項(xiàng)目數(shù)據(jù)層使用 Druid + MyBatis，集成了 sharding-JDBC 之后 sharding-JDBC包裝了 Druid ，所以一些 sharding-JDBC 不支持的sql語(yǔ)句基本就過(guò)不去了。

3.使用 springboot 集成 sharding-JDBC 的時(shí)候，在bean加載的時(shí)候我需要設(shè)置 IncrementIdGenerator ，但是出現(xiàn)classloader問題。

IncrementIdGenerator incrementIdGenerator = this.getIncrementIdGenerator(dataSource);

ShardingRule shardingRule = shardingRuleConfiguration.build(dataSourceMap);
((IdGenerator) shardingRule.getDefaultKeyGenerator()).setIncrementIdGenerator(incrementIdGenerator);

private IncrementIdGenerator getIncrementIdGenerator(DataSource druidDataSource) {
...
    }

后來(lái)發(fā)現(xiàn) springboot的類加載器使用的是 restartclassloader，所以導(dǎo)致轉(zhuǎn)換一直失敗。只要去掉 spring-boot-devtools package即可，restartclassloader 是為了熱啟動(dòng)。

4.dao.xml 逆向工程問題，我們使用的很多數(shù)據(jù)庫(kù)表mybatis生成工具生成的時(shí)候都是物理表名，一旦我們使用了sharding-JDCB之后都是用的邏輯表名，所以生成工具需要提供選項(xiàng)來(lái)設(shè)置邏輯表名。

5.為 mybatis 提供的 SqlSessionFactory 需要在Druid的基礎(chǔ)上用shading-JDCB包裝下。

6.sharding-JDBC DefaultkeyGenerator 默認(rèn)采用是 snowflake 算法，但是我們不能直接用我們需要根據(jù) datacenterid-workerid 自己配合zookeeper來(lái)設(shè)置 workerId 段。
（snowflake workId 10 bit 十進(jìn)制 1023，dataCenterId 5 bit 十進(jìn)制 31 、WorkId 5 bit 十進(jìn)制 31）

7.由于我們使用的是 MySQL com.mysql.jdbc.ReplicationDriver 自帶的實(shí)現(xiàn)讀寫分離，所以處理讀寫分離會(huì)方便很多。如果不是使用的這種就需要手動(dòng)設(shè)置 Datasource Hint 來(lái)處理。

8.在使用 mybatis dao mapper 的時(shí)候需要多份邏輯表，因?yàn)橛行?shù)據(jù)源數(shù)據(jù)表是不需要走sharding的，自定義shardingStragety 來(lái)處理分支邏輯。

9 全局id幾種方法
9.1 如果使用 zookeeper 來(lái)做分布式ID，就要注意 session expired 可能會(huì)存在重復(fù) workid 問題，加鎖或者接受一定程度的并行（有序列號(hào)保證一段時(shí)間空間）。

9.2.采用集中發(fā)號(hào)器服務(wù)，在主DB中采用預(yù)生成表+incrment 插件（經(jīng)典取號(hào)器實(shí)現(xiàn)，innodb 存儲(chǔ)引擎中的 TRX_SYS_TRX_ID_STORE 事務(wù)號(hào)也是這種方式）

9.3.定長(zhǎng)發(fā)號(hào)器、業(yè)務(wù)規(guī)則發(fā)號(hào)器，這種需要業(yè)務(wù)上下文的發(fā)號(hào)器實(shí)現(xiàn)都需要預(yù)先配置，然后每次請(qǐng)求帶上獲取上下文來(lái)說(shuō)明獲取業(yè)務(wù)類型

10.在項(xiàng)目中有些地方使用了自增id排序，數(shù)據(jù)表拆分之后就需要進(jìn)行改造，因?yàn)镮D大小順序已經(jīng)不存在了。根據(jù)數(shù)據(jù)的最新排序時(shí)使用了id排序需要改造成用時(shí)間字段排序。

作者：王清培 （滬江集團(tuán)資深JAVA架構(gòu)師）