如何使用PolarDB-X實(shí)現(xiàn)高效靈活的分區(qū)管理

這期內(nèi)容當(dāng)中小編將會(huì)給大家?guī)?lái)有關(guān)如何使用PolarDB-X實(shí)現(xiàn)高效靈活的分區(qū)管理，文章內(nèi)容豐富且以專業(yè)的角度為大家分析和敘述，閱讀完這篇文章希望大家可以有所收獲。

01

Hash分區(qū) vs. Range分區(qū)

用戶在使用分布式數(shù)據(jù)庫(kù)時(shí)，最想要的是既能將計(jì)算壓力均攤到不同的計(jì)算節(jié)點(diǎn)(CN)，又能將數(shù)據(jù)盡量散列在不同的存儲(chǔ)節(jié)點(diǎn)(DN)，讓系統(tǒng)的存儲(chǔ)壓力均攤到不同的DN。對(duì)于將計(jì)算壓力均攤到不同的CN節(jié)點(diǎn)，業(yè)界的方案一般比較統(tǒng)一，通過(guò)負(fù)載均衡調(diào)度，將業(yè)務(wù)的請(qǐng)求均勻地調(diào)度到不同的CN節(jié)點(diǎn)；對(duì)于如何將數(shù)據(jù)打散到DN節(jié)點(diǎn)，不同的數(shù)據(jù)庫(kù)廠商有不同策略，主要是兩種流派：按拆分鍵Hash分區(qū)和按拆分鍵Range分區(qū)，DN節(jié)點(diǎn)和分片之間的對(duì)應(yīng)關(guān)系是由數(shù)據(jù)庫(kù)存儲(chǔ)調(diào)度器來(lái)處理的，一般只要數(shù)據(jù)能均勻打散到不同的分區(qū)，那么DN節(jié)點(diǎn)之間的數(shù)據(jù)基本就是均勻的。如下圖所示，左邊是表A按照列PK做Hash分區(qū)的方式創(chuàng)建4個(gè)分區(qū)，右邊是表A按照列PK的值做Range分區(qū)的方式也創(chuàng)建4個(gè)分區(qū)：

按照Hash分區(qū)的方式，表A的數(shù)據(jù)會(huì)隨機(jī)的散落在4個(gè)分區(qū)中，這四個(gè)分區(qū)的數(shù)據(jù)之間沒(méi)有什么的依賴關(guān)系，這種方式的優(yōu)點(diǎn)是：

1. 只要分區(qū)鍵的區(qū)分度高，數(shù)據(jù)一定能打散；

2. 不管是隨機(jī)寫入/讀取還是按PK順序?qū)懭?讀取，流量都能均勻地分布到這個(gè)4個(gè)分區(qū)中。

Hash分區(qū)的缺點(diǎn)是，范圍查詢非常低效。由于數(shù)據(jù)隨機(jī)打散到不同分片列，所以對(duì)于范圍查詢只能通過(guò)全部掃描才能找到全部所需的數(shù)據(jù)，只有等值查詢才能做分區(qū)裁剪。

按照Range分區(qū)的方式，根據(jù)定義，表A會(huì)被切分成4個(gè)分區(qū)，pk為1～1000范圍內(nèi)的值散落到分區(qū)1，pk為1001～2000范圍內(nèi)的值散落到分區(qū)2，pk為2001～3000范圍內(nèi)的值散落到分區(qū)3，pk為3001～4000范圍內(nèi)的值散落到分區(qū)4，由于數(shù)據(jù)在分區(qū)內(nèi)是連續(xù)的，所以Range分區(qū)有個(gè)很好的特性就是范圍查詢很高效，例如：

select * from A where PK >2 and PK < 500

注：*左右滑動(dòng)閱覽

對(duì)于這個(gè)查詢我們只有掃描分區(qū)1就可以，其他分區(qū)可以裁剪掉。

Range分區(qū)方式的缺點(diǎn)是：

1. 如果各個(gè)分區(qū)范圍的數(shù)據(jù)不均衡，例如pk為[1,1000]的數(shù)據(jù)只有10條，而pk為[1001,2000]的數(shù)據(jù)有1000條，就會(huì)發(fā)生數(shù)據(jù)傾斜。所以數(shù)據(jù)能不能均衡散列跟數(shù)據(jù)的分布性有關(guān)。

2. 對(duì)于按照拆分列（如例子中的PK列）順序讀取或者寫入，那么讀或許寫的流量永遠(yuǎn)都在最后一個(gè)分區(qū)，最后一個(gè)分片將成為熱點(diǎn)分片。

02

默認(rèn)拆分方式

為了讓用戶能用較小代價(jià)從單機(jī)數(shù)據(jù)庫(kù)到分布式數(shù)據(jù)庫(kù)的演進(jìn)，將原有數(shù)據(jù)表的schema結(jié)構(gòu)導(dǎo)入到分布式數(shù)據(jù)系統(tǒng)中，再將數(shù)據(jù)導(dǎo)入就可以將現(xiàn)有表的數(shù)據(jù)打散到不同的DN節(jié)點(diǎn)，而不需要像我們前面例子中一樣，額外添加 partition by hash/range 這樣的語(yǔ)句，一般的分布式數(shù)據(jù)都會(huì)按照某種默認(rèn)策略將數(shù)據(jù)打散。業(yè)界有默認(rèn)兩種策略，一種是默認(rèn)按主鍵Hash拆分（如yugabyteDB），一種是默認(rèn)按主鍵Range拆分(如TiDB)。這兩種拆分方式各有什么優(yōu)缺點(diǎn)，在PolarDB-X中我們采取什么樣的策略？我們一起來(lái)探索一下。

2.1 主鍵Hash拆分

默認(rèn)按主鍵Hash拆分，意味著用戶在創(chuàng)建表的時(shí)候不需要顯式指定拆分方式，會(huì)自動(dòng)將插入數(shù)據(jù)庫(kù)每一行的主鍵通過(guò)hash散列后得到一個(gè)HashKey，再根據(jù)一定的策略將這個(gè)HashKey映射到特定的DN節(jié)點(diǎn)，從而實(shí)現(xiàn)將數(shù)據(jù)散列到不同的DN節(jié)點(diǎn)的目的。

常見的HashKey和DN的映射策略有兩種方式，按Hash得到的結(jié)果取模 (hashKey % n) 和 一致性Hash（將hashKey劃分成不同的range，每個(gè)range和不同的DN對(duì)應(yīng)）。

按Hash結(jié)果(hashKey % n)取模

這里的n是存儲(chǔ)節(jié)點(diǎn)的數(shù)量，這個(gè)方法很簡(jiǎn)單，就是將拆分鍵的值按照hash function計(jì)算出一個(gè)hashKey后，將這個(gè)hashKey對(duì)存儲(chǔ)節(jié)點(diǎn)數(shù)量n取模得到一個(gè)值，這個(gè)值就是存儲(chǔ)節(jié)點(diǎn)的編號(hào)。所以數(shù)據(jù)和DN節(jié)點(diǎn)的具體的映射關(guān)系如下：

DN = F(input) ==> DN = Hash(pk) % n

例如系統(tǒng)中有4個(gè)DN節(jié)點(diǎn)，假如插入的行的pk=1，hash(1)的結(jié)果為200，那么這一行最終將落在第0個(gè)DN節(jié)點(diǎn)（200%4=0）。

按hash key取模的方法優(yōu)點(diǎn)是：用戶能夠根據(jù)hashkey的值和DN的數(shù)量可以精準(zhǔn)計(jì)算出數(shù)據(jù)落在哪個(gè)DN上，可以靈活地通過(guò)hint控制從哪個(gè)DN讀寫數(shù)據(jù)。

按hash key取模的方法缺點(diǎn)是，當(dāng)往集群增加或者減少DN節(jié)點(diǎn)的時(shí)候，由于DN的數(shù)目就是hash取模的n的值，所以只要發(fā)生DN節(jié)點(diǎn)的變化都需要將原有的數(shù)據(jù)rehash 重新打散到現(xiàn)有的DN節(jié)點(diǎn)，代價(jià)是非常大的。同時(shí)這種分區(qū)方式對(duì)于范圍查詢不友好，因?yàn)閿?shù)據(jù)按hashKey散列到不同的DN，只有全表掃描之后才能找到所需數(shù)據(jù)。

一致性Hash

一致性Hash是一種特殊的Hash算法，先根據(jù)拆分鍵（主鍵）的值按照hash function計(jì)算一個(gè)hashKey，然后再將hashKey定位到對(duì)應(yīng)的分片的分區(qū)方式，效果上類似于  Range By (hashFunction(pk)) 。假設(shè)計(jì)算出來(lái)的HashKey的大小全部都是落在[0x0,0xFFFF]區(qū)間內(nèi)，當(dāng)前系統(tǒng)有4個(gè)DN節(jié)點(diǎn)，建表可以默認(rèn)創(chuàng)建4個(gè)分區(qū)，那么每個(gè)分區(qū)就可以分配到不同的DN節(jié)點(diǎn)，每個(gè)分區(qū)對(duì)應(yīng)的區(qū)間如下圖：

0x～0x4000(左開右合區(qū)間)0x4000～0x80000x8000~0xc0000xc000~0x10000

分區(qū)和DN之間的對(duì)應(yīng)關(guān)系作為表結(jié)構(gòu)的元數(shù)據(jù)保存起來(lái)，這樣我們得到主鍵的HashKey之后，根據(jù)這個(gè)HashKey的值的范圍和分區(qū)的元數(shù)據(jù)信息做個(gè)二分查找，就可以計(jì)算出該主鍵所在的行落在哪個(gè)區(qū)分，具體的計(jì)算公式如下：

DN = F(input) ==> DN = BiSearch(Hash(pk))

一致性Hash的方法優(yōu)點(diǎn)是，當(dāng)添加DN節(jié)點(diǎn)時(shí)，我們可以將部分分片數(shù)據(jù)通過(guò)分裂或者遷移的方式挪到新的DN，同時(shí)更新一下表的元數(shù)據(jù)，其他的分片數(shù)據(jù)無(wú)需變化；當(dāng)減少DN節(jié)點(diǎn)時(shí)，也只需要將待刪除的DN節(jié)點(diǎn)上的數(shù)據(jù)遷移到其他節(jié)點(diǎn)同時(shí)更新一下元數(shù)據(jù)即可，非常靈活。一致性Hash的方法缺點(diǎn)是對(duì)范圍查詢也不友好。

2.2 主鍵Range拆分

主鍵Range拆分的方式和一致性Hash的本質(zhì)區(qū)別在于，一致性Hash是對(duì)拆分鍵的Hash后得到HashKey，按這個(gè)HashKey的取值范圍切分成不同的分區(qū)，主鍵Range拆分是按將拆分鍵的實(shí)際值的取值范圍拆分不同的分區(qū)。對(duì)按照主鍵拆分的表，優(yōu)點(diǎn)是范圍查詢非常高效，因?yàn)镻K相鄰的數(shù)據(jù)分區(qū)也是相同或者相鄰的；還可以實(shí)現(xiàn)快速刪除，例如對(duì)于是基于時(shí)間range分區(qū)的表，我們可以很輕松地將某個(gè)時(shí)間點(diǎn)之前的數(shù)據(jù)全部刪掉，因?yàn)橹恍枰獙?duì)應(yīng)的分區(qū)刪除就可以了，其他分區(qū)的數(shù)據(jù)可以保持不變，這些特性都是按hash分區(qū)無(wú)法做到的；缺點(diǎn)是在使用自增主鍵并且連續(xù)插入的場(chǎng)景下，最后一個(gè)分片一定會(huì)成為寫入熱點(diǎn)。

2.3 PolarDB-X的默認(rèn)拆分方式

了解了這兩種默認(rèn)的主鍵拆分方式后我們來(lái)談?wù)凱olarDB-X是如何取舍的。本質(zhì)上范圍查詢和順序?qū)懭胧莻€(gè)矛盾點(diǎn)，如果要支持高效的范圍查詢，那么在按主鍵遞增順序?qū)懭刖鸵欢〞?huì)成為熱點(diǎn)，畢竟范圍查詢之所以高效是因?yàn)橄噜彽闹麈I在存儲(chǔ)物理位置也是相鄰的，存儲(chǔ)位置相鄰意味著按主鍵順序?qū)懭胍欢〞?huì)只寫最后一個(gè)分片。對(duì)于OLAP的場(chǎng)景，可能問(wèn)題不大， 畢竟數(shù)據(jù)主要的場(chǎng)景是讀，但對(duì)于OLTP場(chǎng)景，就不一樣了，很多業(yè)務(wù)需要快速生成一個(gè)唯一的ID，通過(guò)業(yè)務(wù)系統(tǒng)生成一個(gè)UUID的方式是低效的，存儲(chǔ)代價(jià)也比AUTO_INCREMENT列大。

對(duì)一個(gè)主鍵做范圍查詢場(chǎng)景不是很常見，除非這個(gè)主鍵是時(shí)間類型，例如某訂單表按照創(chuàng)建一個(gè)主鍵為gmt_create的時(shí)間類型，為了高效查找某段時(shí)間范圍內(nèi)的訂單，可能會(huì)有范圍查詢的訴求。

基于以上分析，在PolarDB-X中我們是默認(rèn)按主鍵Hash拆分，在Hash算法的選擇中，我們選用的是一致性Hash的路由策略，因?yàn)槲覀冋J(rèn)為在分布式數(shù)據(jù)庫(kù)系統(tǒng)，節(jié)點(diǎn)的變更、分區(qū)的分裂合并是很常見的。前面分析過(guò)使用Hash取模的方式對(duì)于這種操作代價(jià)太大了，一致性Hash能保證我們分區(qū)的分裂合并，增刪DN節(jié)點(diǎn)的代價(jià)做到和Range分區(qū)一樣，能做到按需移動(dòng)數(shù)據(jù)，而不需要全部的rehash。

特別的，對(duì)于主鍵是時(shí)間類型，我們默認(rèn)是按時(shí)間取YYYYDD表達(dá)式作用于pk后再按一致性Hash打散，這樣做的目的是同一天的數(shù)據(jù)會(huì)落在同一個(gè)分區(qū)，數(shù)據(jù)能以天為單位打散，這種方式對(duì)于按主鍵（時(shí)間）做范圍查詢是高效的，前面我們提到過(guò)，對(duì)于以時(shí)間為主鍵的表，范圍查詢是個(gè)強(qiáng)訴求，同時(shí)能更高效將歷史數(shù)據(jù)（例如，一年前的數(shù)據(jù)）歸檔。

03

table group

在PolarDB-X中，為加速SQL的執(zhí)行效率，優(yōu)化器會(huì)將分區(qū)表之間Join操作優(yōu)化為Partition-Wise Join來(lái)做計(jì)算下推。但是，當(dāng)分區(qū)表的拓?fù)浒l(fā)生變更后，例如分區(qū)發(fā)生分裂或者合并后，原本分區(qū)方式完全相同的兩張分區(qū)表，就有可能出現(xiàn)分區(qū)方式不一致，這導(dǎo)致這兩張表之間的計(jì)算下推會(huì)出現(xiàn)失效，進(jìn)而對(duì)業(yè)務(wù)產(chǎn)生直接影響。

對(duì)于以下的兩個(gè)表t1和t2，由于它們的分區(qū)類型/拆分鍵類型/分區(qū)的數(shù)目等都是一致，我們認(rèn)為這兩個(gè)表的分區(qū)規(guī)則是完全一致的。

create table t1 (c1 int auto_increment, c2 varchar(20), c3 int, c4 date, primary key(c1))    PARTITION BY HASH (c1) partition 4create table t2 (c2 int auto_increment, c2 varchar(20), primary key(c2))    PARTITION BY HASH (c2) partition 4

注：*左右滑動(dòng)閱覽

所以在這兩個(gè)表上，執(zhí)行sql1：select t1.c1, t2.c1 from t1, t2 on t1.c1 = t2.c2，對(duì)于這種按照分區(qū)鍵做equi-join的sql，PolarDB-X會(huì)優(yōu)化為Partition-Wise Join將其下推到存儲(chǔ)節(jié)點(diǎn)將join的結(jié)果直接返回給CN，而無(wú)需將數(shù)據(jù)拉取到CN節(jié)點(diǎn)再做join，從而大大降低join的代價(jià)（io和計(jì)算的代價(jià)都大大得減少）。

但是如果t1表的p1發(fā)生了分裂，分區(qū)數(shù)目將從4個(gè)變成了5個(gè)，這時(shí)候sql1就不能再下推了，因?yàn)閠1和t2的分區(qū)方式不完整一致了，左右表join所需的數(shù)據(jù)發(fā)生在多個(gè)DN節(jié)點(diǎn)，必須將數(shù)據(jù)從DN節(jié)點(diǎn)拉取到CN節(jié)點(diǎn)才能做join了。

為了解決分區(qū)表在分裂或合并過(guò)程中導(dǎo)致的計(jì)算下推失效的問(wèn)題，我們創(chuàng)造性地引入了表組（Table Group）和分區(qū)組（partition group）的概念，允許用戶將兩張及以上的分區(qū)表分區(qū)定義一致的表劃分到同一個(gè)表組內(nèi)，在同一個(gè)表組的所有表的分區(qū)規(guī)則都是一致的，相同規(guī)則的分區(qū)屬于同一個(gè)分區(qū)組，在一個(gè)分區(qū)組的所有分區(qū)都在同一個(gè)DN節(jié)點(diǎn)（join下推的前提），屬于同一個(gè)表組的分區(qū)表的分裂合并遷移都是以分區(qū)組為基本單位，要么同時(shí)分裂，要么同時(shí)合并，要么同時(shí)遷移，總是保持同步，即使表組內(nèi)的分區(qū)表的分區(qū)出現(xiàn)變更，也不會(huì)對(duì)表組內(nèi)原來(lái)能下推的join產(chǎn)生影響。

特別的，為了減少用戶的學(xué)習(xí)成本，一開始用戶并不需要關(guān)注表組，我們會(huì)默認(rèn)將每個(gè)表都單獨(dú)放到一個(gè)表組里，用戶并不用感知它。只有在需要性能調(diào)優(yōu)或者業(yè)務(wù)中某些表需要穩(wěn)定地做join下推時(shí)，作為一種最佳實(shí)踐，這時(shí)候用戶才需要考慮表組。

對(duì)于表組我們支持如下的管理方式有：
表組分區(qū)組分裂：

一般的，在PolarDB-X中，一個(gè)分區(qū)表的大小建議維持在500W以內(nèi)，當(dāng)一個(gè)分區(qū)的數(shù)據(jù)量太大，我們可以對(duì)分區(qū)進(jìn)行分裂操作，

alter tablegroup split partition p1 to p10, p11

注：*左右滑動(dòng)閱覽

表組分區(qū)組合并：

當(dāng)一個(gè)分區(qū)表的某些分區(qū)的行數(shù)大小遠(yuǎn)小于500W時(shí)，我們可以對(duì)分區(qū)進(jìn)行合并操作，

alter tablegroup merge partition p1,p2 to p10

注：*左右滑動(dòng)閱覽

表組分區(qū)組的遷移：

前面我們提到在分布式數(shù)據(jù)庫(kù)系統(tǒng)中，節(jié)點(diǎn)的增加或者減少是很常見的事情，例如某商家為了線上促銷，會(huì)臨時(shí)增加一批節(jié)點(diǎn)，在促銷結(jié)束后希望將節(jié)點(diǎn)縮容回平時(shí)正常的量。PolarDB-X中我們是如何支持這種訴求的？
PolarDB-X的CN節(jié)點(diǎn)是無(wú)狀態(tài)的，增刪過(guò)程只需往系統(tǒng)注冊(cè)，不涉及數(shù)據(jù)移動(dòng)。這里主要討論增刪DN節(jié)點(diǎn)，當(dāng)用戶通過(guò)升配增加DN節(jié)點(diǎn)后，這個(gè)DN節(jié)點(diǎn)一開始是沒(méi)有任何數(shù)據(jù)的，我們?cè)趺纯焖僮屵@個(gè)新的DN節(jié)點(diǎn)能分?jǐn)傁到y(tǒng)的流量呢？在DN節(jié)點(diǎn)準(zhǔn)備好后，我們后臺(tái)的管控系統(tǒng)可以通過(guò)PolarDB-X提供的分區(qū)遷移命令按需批量將數(shù)據(jù)從老DN節(jié)點(diǎn)遷移到新的DN，具體命令如下：

alter tablegroup move partition p1,p2 to DNi

注：*左右滑動(dòng)閱覽

將表D加入表組tg1：

alter tablegroup tg1 add D

將表D加入表組tg1有個(gè)前提條件，就是表D的分區(qū)方式要和tg1里的表完全一致，同時(shí)如果對(duì)應(yīng)分區(qū)的數(shù)據(jù)和tg1對(duì)應(yīng)的分區(qū)組不在同一個(gè)DN節(jié)點(diǎn)，會(huì)觸發(fā)表D的數(shù)據(jù)遷移。

將表B從表組tg中移除：

alter tablegroup tg1 remove B

04

其他分區(qū)方式

前面我們對(duì)比了一致性Hash和Range的區(qū)別，并且我們采用默認(rèn)按主鍵拆分的策略，盡管如此我們還是實(shí)現(xiàn)了Range分區(qū)和List分區(qū)以滿足客戶不同場(chǎng)景的不同訴求

4.1 Range分區(qū)

特別提一下，range分區(qū)除了上面提到的范圍查詢優(yōu)化的優(yōu)點(diǎn)外，在PolarDB-X中，我們的存儲(chǔ)引擎不光支持Innodb，還有我們自研的X-Engine，X-Engine的LSM-tree的分層結(jié)構(gòu)支持混合存儲(chǔ)介質(zhì)，通過(guò)range分區(qū)可以按需將業(yè)務(wù)任務(wù)的是“老分區(qū)”的數(shù)據(jù)遷移到X-Engine，對(duì)于遷移過(guò)來(lái)的冷數(shù)據(jù)，可以保存在比較廉價(jià)的HDD硬盤中，對(duì)于熱數(shù)據(jù)可以存儲(chǔ)在SSD，從而實(shí)現(xiàn)冷熱數(shù)據(jù)的分離。

4.2 List分區(qū)

List分區(qū)是實(shí)現(xiàn)按照離散的值劃分分區(qū)的一種策略，有了list分區(qū)的支持，那么在PolarDB-X中就可以實(shí)現(xiàn)Geo Partition的方案，例如對(duì)于某個(gè)系統(tǒng)，里面有全球各個(gè)國(guó)家的數(shù)據(jù)，那么就可以按照歐美-亞太-非洲等區(qū)域維度拆分，將不同的分區(qū)部署在不同地域的物理機(jī)房，將數(shù)據(jù)放在離用戶更近的地域，減少訪問(wèn)延遲。

CREATE TABLE users （ country varchar, id int, name varchar, …)PARTITION BY LIST (country) (    PARTITION Asia VALUES IN ('CN', 'JP', …),    PARTITION Europe VALUES IN ('GE','FR',..),    ....)

注：*左右滑動(dòng)閱覽

4.3 組合分區(qū)

前面提到，在PolarDB-X中我們支持Hash/Range/List分區(qū)方式，同時(shí)我們也支持這三種分區(qū)任意兩兩組合的二級(jí)分，以滿足不同業(yè)務(wù)的不同訴求。下面舉幾個(gè)常見的例子來(lái)闡述，如何通過(guò)這三種分區(qū)的組合解決不同的問(wèn)題。

場(chǎng)景1：用顯式的創(chuàng)建list分區(qū)表，例如將省份作為拆分鍵，將不同省份的數(shù)據(jù)保存在不同的分片，進(jìn)而可以將不同身份的分片保存在不同的DN，這樣做的好處是可以做到按省份數(shù)據(jù)隔離，然后可以按照區(qū)域?qū)⒉煌》莸臄?shù)據(jù)保存在就近的數(shù)據(jù)中心（如華南/華北數(shù)據(jù)中心）。但是這種分區(qū)有個(gè)缺點(diǎn)，就是力度太粗了，每個(gè)省份一個(gè)分區(qū)，很容易就產(chǎn)生一個(gè)很大的分區(qū)，而且還沒(méi)發(fā)直接分裂，對(duì)于這種場(chǎng)景，可以采用list+hash的組合，一級(jí)分區(qū)用list劃分后，分區(qū)內(nèi)再根據(jù)主鍵hash，就可以將數(shù)據(jù)打散的非常均勻，如：

create table AA (pk bigint, provinceName varchar,...) PARTITION BY LIST (provinceName)SUBPARTITION BY HASH (pk)SUBPARTITIONS 2( PARTITION p1 VALUES ('Guangdong','Fujian'),  PARTITION p2 VALUES ('Beijing','HeBei','Tijin'));

注：*左右滑動(dòng)閱覽

一級(jí)分區(qū)p1/p2是采用list分區(qū)形式，可以將p1的子分區(qū)固定在region1，p2的子分區(qū)固定在region2，如下圖所示：

場(chǎng)景2：單key熱點(diǎn)，當(dāng)一個(gè)key的數(shù)據(jù)很多時(shí)，該key所在的分片會(huì)很大，造成該分片可能成為一個(gè)熱點(diǎn)，PolarDB-X中默認(rèn)按主鍵拆分，并不會(huì)出現(xiàn)此類熱點(diǎn)，因此熱點(diǎn)key來(lái)自二級(jí)索引，因?yàn)橹鞅聿捎冒粗麈IHash拆分，二級(jí)索引表的拆分鍵就會(huì)選擇和主表不一樣的列，對(duì)于按非主鍵列拆分就可能產(chǎn)生熱點(diǎn)key。對(duì)于熱點(diǎn)key，PoalrDB-X首先會(huì)將熱點(diǎn)key通過(guò)分裂的方式，放到一個(gè)單獨(dú)的分片內(nèi)，隨著該分片的負(fù)載變大，PolarDB-X會(huì)將該分片所在的DN上的其他分片逐步遷移到其他DN上，最終，這個(gè)分片將獨(dú)占一個(gè)DN節(jié)點(diǎn)。如果該分片獨(dú)占一個(gè)DN節(jié)點(diǎn)后，依然無(wú)法滿足要求，PolarDB-X會(huì)對(duì)這個(gè)分區(qū)二級(jí)散列成多個(gè)分片，進(jìn)而這個(gè)熱點(diǎn)key就可以遷移到多臺(tái)DN上。當(dāng)分片被打散后，對(duì)該key的查詢需要聚合來(lái)自多個(gè)DN的多個(gè)分片的數(shù)據(jù)，在查詢上會(huì)有一定的性能損失。PolarDB-X對(duì)分片的管理比較靈活，對(duì)同一個(gè)表的不同分片，允許使用不同打散策略。例如對(duì)p1分片打散成2個(gè)分片，對(duì)p2分片打散成3個(gè)分片，對(duì)p4分片不做打散，避免熱點(diǎn)分片對(duì)非熱點(diǎn)分片的影響。

05 小結(jié)

PolarDB-X提供了默認(rèn)按主鍵Hash分區(qū)的分區(qū)管理策略，同時(shí)為了滿足不同業(yè)務(wù)的需求也支持了Range和List分區(qū)，這三種分區(qū)策略可以靈活組合，支持二級(jí)分區(qū)。為了計(jì)算下推，引入了表組的概念，滿足不同業(yè)務(wù)的需求。

上述就是小編為大家分享的如何使用PolarDB-X實(shí)現(xiàn)高效靈活的分區(qū)管理了，如果剛好有類似的疑惑，不妨參照上述分析進(jìn)行理解。如果想知道更多相關(guān)知識(shí)，歡迎關(guān)注億速云行業(yè)資訊頻道。