異構索引表的作用

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

分庫分表的查詢問題

問題說明

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

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

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

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

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

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

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

性能問題

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

數據聚合問題

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

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

那么如何解決這一痛點？

解決分庫分表的查詢問題

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

引入異構索引表

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

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

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

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

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

引入后的查詢過程

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

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

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

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

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

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

總結

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

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