分片MySQL數據庫的最佳方法

Question

我有大量的用戶，因此需要將數據庫分片為n個分片。 因此，要進行此操作，我有以下選擇-

1. 將我的數據划分為n個分片，基於userId模數n操作。 即如果我有10個分片，則userId 1999將發送到1999％10 =第9個分片
   問題 -這種方法的問題是，如果將來參考以前的分片數量增加，將無法維持。

2. 我可以使用UserId和ShardId維護一個表
   問題-如果我的用戶將來增加到數十億，我將需要共享此映射表，這似乎不是一個好的解決方案。

3. 我可以在碎片1等中的0-10000之類的代碼中維護靜態映射。
   問題-

   • 隨着分片和用戶代碼的增加，需要更頻繁地更改代碼。
   • 如果分片中的任何特定用戶擁有大量數據，將很難分離出分片。

因此，這是我可以找到的三種方法，但是都存在一些問題。 分片MySQL表的替代方法或更好的方法是，將來可以補償增加的分片和用戶數量。

Answer 1

我更喜歡1和2的混合體：

1. 將UserId散列為4096個值。
2. 在其中包含分片編號的“字典”中查找該編號。

如果一個分片太滿，則將具有某個哈希值的所有用戶遷移到另一個分片。

如果添加了分片，請向其遷移一些哈希數-最好從繁忙的分片開始。

這迫使您編寫用於移動用戶的腳本，並使其健壯。 一旦有了這些，許多其他管理任務就會變得“簡單”：

• 退機
• 升級操作系統（跨碎片一一升級）
• 升級計算機上的任何軟件
• 將散列但不忙的哈希數遷移到磁盤較大的舊的，緩慢的碎片中。 同樣，將忙碌的小型遷移到具有更多核心和更快磁盤的分片。

每個分片可以是服務器的HA群集（Galera，組復制等），以實現可靠性和讀取擴展。 （着色使您可以進行寫縮放。

將需要一種將詞典“立即”分發給所有客戶端的方法。

例如，如果您為HA分配了3個不同的分片中的每個散列，則所有這些工作都很好。 3個中的每個都將位於地理位置以提高魯棒性。 該詞典將有4列來說明副本的位置。 遷移期間將使用第4個。