異構(gòu)索引表的作用

如果《面試官：分庫(kù)分表有什么好的方案？》說的是分庫(kù)分表的方法和策略，那么本文所探討的“異構(gòu)索引表”，則是在實(shí)施分庫(kù)分表過程中一個(gè)非常巧妙的設(shè)計(jì)，用來解決分庫(kù)分表的查詢問題。

分庫(kù)分表的查詢問題

問題說明

在哈希分庫(kù)分表時(shí)，為了避免分布不均勻造成的“數(shù)據(jù)傾斜”，通常會(huì)選擇一些數(shù)據(jù)唯一的字段進(jìn)行哈希操作，比如ID。

以訂單表為例，通常有（id、uid、status、amount）等字段，通過id進(jìn)行哈希取模運(yùn)算分庫(kù)分表之后，效果如下圖

這樣分庫(kù)分表的方法沒有問題，但是，在后期的開發(fā)和維護(hù)過程中，可能會(huì)存在潛在的問題。

舉個(gè)例子：現(xiàn)在要查詢uid為1的記錄，應(yīng)該去哪個(gè)表或庫(kù)去查詢？

對(duì)于用戶來講，這個(gè)場(chǎng)景可以說是非常頻繁的。

這個(gè)時(shí)候就會(huì)發(fā)現(xiàn)，要想查詢uid為1的記錄，只能去所有的庫(kù)或分表上進(jìn)行查詢，也就是所謂的“廣播查詢”。

整個(gè)查詢過程大概是這樣的

性能問題

顯然，整個(gè)查詢過程需要進(jìn)行全庫(kù)掃描，涉及到多次的網(wǎng)絡(luò)數(shù)據(jù)傳輸，一定會(huì)導(dǎo)致查詢速度的降低和延遲的增加。

數(shù)據(jù)聚合問題

另外，當(dāng)這個(gè)用戶有成千上萬條數(shù)據(jù)時(shí)，不得已要在一個(gè)節(jié)點(diǎn)進(jìn)行排序、分頁(yè)、聚合等計(jì)算操作，需要消耗大量的計(jì)算資源和內(nèi)存空間。對(duì)系統(tǒng)造成的負(fù)擔(dān)也會(huì)影響查詢性能。

這是一個(gè)非常典型的“事務(wù)邊界大”的案例，即“一條SQL到所有的數(shù)據(jù)庫(kù)去執(zhí)行”。

那么如何解決這一痛點(diǎn)？

解決分庫(kù)分表的查詢問題

本文重點(diǎn)：“異構(gòu)索引表”是可以解決這個(gè)問題的。

引入異構(gòu)索引表

簡(jiǎn)單來說，“異構(gòu)索引表”是一個(gè)拿空間換時(shí)間的設(shè)計(jì)。具體如下：

添加訂單數(shù)據(jù)時(shí)，除了根據(jù)訂單ID進(jìn)行哈希取模運(yùn)算將訂單數(shù)據(jù)維護(hù)到對(duì)應(yīng)的表中，還要對(duì)uid進(jìn)行哈希取模運(yùn)算，將uid和訂單id維護(hù)在另一張表中，如圖所示。

引入“異構(gòu)索引表”后，因?yàn)橥粋€(gè)uid經(jīng)過哈希取模運(yùn)算后得到的結(jié)果是一致的，所以，該uid所有的訂單id也一定會(huì)被分布到同一張user_order表中。

當(dāng)查詢uid為1的訂單記錄時(shí)，就可以有效地解決數(shù)據(jù)聚合存在的計(jì)算資源消耗和全庫(kù)掃描的低效問題了。

接下來，通過查詢過程，看看這兩個(gè)問題是怎么解決的。

引入后的查詢過程

引入“異構(gòu)索引表”后，查詢uid為1的訂單記錄時(shí)，具體過程分為以下幾步：

應(yīng)用向中間件發(fā)送select * from order where uid = 1，請(qǐng)求查詢uid為1的訂單記錄。
中間件根據(jù)uid路由到“異構(gòu)索引表”：user_order，獲得該uid相關(guān)的訂單ID列表（排序、分頁(yè)可以在此sql操作）。
中間件根據(jù)返回的訂單ID，再次準(zhǔn)確路由到對(duì)應(yīng)的訂單表：order。
中間件將分散的訂單數(shù)據(jù)進(jìn)行聚合返回給應(yīng)用。