分片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个。