自拍偷在线精品自拍偷,亚洲欧美中文日韩v在线观看不卡

從分庫分表后遺癥，總結(jié)數(shù)據(jù)庫表拆分策略

作者：王清培（滬江）
數(shù)據(jù)庫
本文將主要從背景、分庫分表帶來的后遺癥、分表策略以及一些注意事項(xiàng)等方面對數(shù)據(jù)庫分表來進(jìn)行小結(jié)。

從分庫分表后遺癥，總結(jié)數(shù)據(jù)庫表拆分策略

本文將主要從背景、分庫分表帶來的后遺癥、分表策略以及一些注意事項(xiàng)等方面對數(shù)據(jù)庫分表來進(jìn)行小結(jié)。

一、背景

最近一段時(shí)間內(nèi)結(jié)束了數(shù)據(jù)庫表拆分項(xiàng)目，本次拆分主要包括訂單和優(yōu)惠券兩大塊，這兩塊都是覆蓋全集團(tuán)所有分子公司所有業(yè)務(wù)線。隨著公司的業(yè)務(wù)飛速發(fā)展，不管是存儲的要求，還是寫入、讀取的性能都基本上到了警戒水位。

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

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

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

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

二、分庫、分表帶來的后遺癥

分庫、分表會(huì)帶來很多的后遺癥，會(huì)使整個(gè)系統(tǒng)架構(gòu)變的復(fù)雜。分的好與不好最關(guān)鍵就是如何尋找那個(gè)Sharding key，如果這個(gè)Sharding key剛好是業(yè)務(wù)維度上的分界線就會(huì)直接提升性能和改善復(fù)雜度，否則就會(huì)有各種腳手架來支撐，系統(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ì)很方便，否則就需要一些大而全的索引表來處理OLAP的查詢。

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

1、歸并排序

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

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

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

 

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

 

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

 

  1. pageParameter：pageSize：4、currentPage：1 

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

 

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

 

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

 

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

 

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

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

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

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

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

2、深分頁性能問題

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

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

改變查詢條件有兩種：

  • ***種條件是顯示設(shè)置，盡量縮小查詢范圍，這種設(shè)置一般都會(huì)優(yōu)先考慮如時(shí)間范圍、支付狀態(tài)、配送狀態(tài)等等，通過多個(gè)疊加條件就可以橫豎過濾出很小一部分?jǐn)?shù)據(jù)集；
  • 第二種條件為隱式設(shè)置，比如訂單列表通常是按照訂單創(chuàng)建時(shí)間來排序，那么當(dāng)翻頁到限制的條件時(shí)，我們可以改變這個(gè)時(shí)間。

 

  1. Sharding node 1:orderID     createDateTime  
  2. 100000      2018-01-10 10:10:10  
  3. 200000      2018-01-10 10:10:11  
  4. 300000      2018-01-10 10:10:12  
  5. 400000      2018-01-10 10:10:13  
  6. 500000      2018-01-20 10:10:10  
  7. 600000      2018-01-20 10:10:11  
  8. 700000      2018-01-20 10:10:12  
  9. Sharding node 2:orderID     createDateTime  
  10. 110000      2018-01-11 10:10:10  
  11. 220000      2018-01-11 10:10:11  
  12. 320000      2018-01-11 10:10:12  
  13. 420000      2018-01-11 10:10:13  
  14. 520000      2018-01-21 10:10:10  
  15. 620000      2018-01-21 10:10:11  
  16. 720000      2018-01-21 10:10:12 

 

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

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

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

 

  1. where createDateTime>'2018-01-11 00:00:00'  
  2. pageParameter：pageSize：5、currentPage：1 

 

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

 

  1. orderID     createDateTime  
  2. 100000      2018-01-10 10:10:10  
  3. 200000      2018-01-10 10:10:11  
  4. 300000      2018-01-10 10:10:12  
  5. 400000      2018-01-10 10:10:13  
  6. 110000      2018-01-11 10:10:10 

 

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

 

  1. Sharding node 1:orderID     createDateTime  
  2. 100000      2018-01-10 10:10:10  
  3. 200000      2018-01-10 10:10:11  
  4. 300000      2018-01-10 10:10:12  
  5. 400000      2018-01-10 10:10:13  
  6. 500000      2018-01-20 10:10:10  
  7.  
  8. Sharding node 2:orderID     createDateTime  
  9. 110000      2018-01-11 10:10:10  
  10. 220000      2018-01-11 10:10:11  
  11. 320000      2018-01-11 10:10:12  
  12. 420000      2018-01-11 10:10:13  
  13. 520000      2018-01-21 10:10:10 

 

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

 

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

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

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

如果非要精準(zhǔn)控制這個(gè)偏差就需要記住區(qū)間，或者用其他方式來實(shí)現(xiàn)了，比如全量查詢表、Sharding索引表、***下單tps值之類的，用來輔助計(jì)算。（可以利用數(shù)據(jù)同步中間件建立單表多級索引、多表多維度索引來輔助計(jì)算。我們使用到的數(shù)據(jù)同步中間件有datax、yugong、otter、canal可以解決全量、增量同步問題）。

三、分表策略

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

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

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

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

 

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

 

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

Hash片2的次方問題

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

我們在做數(shù)據(jù)庫Sharding的時(shí)候不需要參考這一原則，這一原則主要是為了程序內(nèi)部Hash表使用，外部我們本來就是要Hash mod確定Sharding node 。

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

四、一些注意事項(xiàng)

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

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

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

  1. IncrementIdGenerator incrementIdGenerator = this.getIncrementIdGenerator(dataSource); 
  2.  
  3. ShardingRule ShardingRule = ShardingRuleConfiguration.build(dataSourceMap); 
  4.  
  5. ((IdGenerator) ShardingRule.getDefaultKeyGenerator()).setIncrementIdGenerator(incrementIdGenerator); 
  6.  
  7. private IncrementIdGenerator getIncrementIdGenerator(DataSource druidDataSource) { 
  8.  
  9. ... 
  10.  
  11.     } 

 

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

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

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

6、Sharding-JDBC DefaultkeyGenerator默認(rèn)采用是snowflake算法，但是我們不能直接用我們需要根據(jù)datacenterid-workerid自己配合Zookeeper來設(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來處理。

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

9、全局ID幾種方法：

  • 如果使用 Zookeeper來做分布式ID，就要注意session expired可能會(huì)存在重復(fù)workid問題，加鎖或者接受一定程度的并行（有序列號保證一段時(shí)間空間）。
  • 采用集中發(fā)號器服務(wù)，在主DB中采用預(yù)生成表+incrment 插件（經(jīng)典取號器實(shí)現(xiàn)，InnoDB存儲引擎中的TRX_SYS_TRX_ID_STORE 事務(wù)號也是這種方式）。
  • 定長發(fā)號器、業(yè)務(wù)規(guī)則發(fā)號器，這種需要業(yè)務(wù)上下文的發(fā)號器實(shí)現(xiàn)都需要預(yù)先配置，然后每次請求帶上獲取上下文來說明獲取業(yè)務(wù)類型。

 

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

責(zé)任編輯：龐桂玉 來源： DBAplus社群
數(shù)據(jù)庫分庫分表表拆分
相關(guān)推薦

2024-08-02 15:47:28

數(shù)據(jù)庫分庫分表

2019-01-16 14:00:54

數(shù)據(jù)庫分庫分表

2023-11-03 14:50:14

2017-07-19 15:19:19

數(shù)據(jù)庫DB分庫實(shí)施策略

2019-03-06 14:42:01

數(shù)據(jù)庫分庫分表

2021-04-01 05:40:53

分庫分表數(shù)據(jù)庫MySQL

2022-06-15 07:32:24

數(shù)據(jù)庫分庫分表

2011-12-31 10:19:36

2018-06-01 14:00:00

數(shù)據(jù)庫MySQL分庫分表

2022-12-05 07:51:24

數(shù)據(jù)庫分庫分表讀寫分離

2009-03-05 09:28:00

VPN連接Vista系統(tǒng)局域網(wǎng)

2011-09-29 17:13:08

通信展2011通信展

2024-12-04 13:02:34

數(shù)據(jù)庫分庫分表

2019-01-29 15:25:11

阿里巴巴數(shù)據(jù)庫分庫分表

2016-08-12 10:28:14

云計(jì)算混合云網(wǎng)絡(luò)架構(gòu)

2023-08-11 08:59:49

分庫分表數(shù)據(jù)數(shù)據(jù)庫

2018-05-29 08:39:26

DBA數(shù)據(jù)庫案例

2013-03-11 13:08:06

戴爾私有化客戶

2014-04-11 13:41:34

即刻搜索即刻合并

2019-08-16 10:19:01

NewSQL數(shù)據(jù)庫分庫分表
點(diǎn)贊
收藏

51CTO技術(shù)棧公眾號