異構索引表的作用

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

分庫分表的查詢問題

問題說明

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

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

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

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

對于用戶來講，這個場景可以說是非常頻繁的。

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

整個查詢過程大概是這樣的

性能問題

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

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

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

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

那么如何解決這一痛點？

解決分庫分表的查詢問題

本文重點：“異構索引表”是可以解決這個問題的。

引入異構索引表

簡單來說，“異構索引表”是一個拿空間換時間的設計。具體如下：

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

引入“異構索引表”后，因為同一個uid經(jīng)過哈希取模運算后得到的結果是一致的，所以，該uid所有的訂單id也一定會被分布到同一張user_order表中。

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

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

引入后的查詢過程

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

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

看上去引入“異構索引表”之后，多了一個查詢步驟，但換來的是：

1. 根據(jù)訂單ID準確路由到訂單表，避免了全庫掃描。
2. 在user_order表進行了排序、分頁等操作，避免大量數(shù)據(jù)回到中間件去計算。

異構索引表解決不了的場景

“異構索引表”只適合簡單的分庫分表查詢場景，如果存在復雜的查詢場景，還是需要借助搜索引擎來實現(xiàn)。

總結

異構索引表作為一種巧妙的設計，避免了分庫分表查詢存在的兩個問題：全庫掃描和不必要的計算資源消耗。

但是，異構索引表并不適用所有場景，對于復雜的查詢場景可能需要結合其他技術或策略來解決問題。