真实世界数据库分片技术

Question

我想了解在真实世界中数据库分片的一些好的做法。如果你有像Gmail这样的系统，分割的理想方式是什么？我看了here，它提到了3种分片方法。看起来其中2个似乎是电子邮件系统的理想选择：

基于查找的分片其中您的前端机器上有一个查找表，用于将您路由到包含查询数据的后端。

基于哈希的分片在输入查询中使用哈希函数来标识包含数据的后端机器。

查找表的问题是它可能会快速增长，也可能需要分割。如果我们分解查找表来查找包含我们数据的碎片，它看起来不是一个好设计。

当您必须将更多服务器添加到您的系统时，基于散列的散列会产生问题。典型的散列函数将使用服务器的数量来计算源分片。因此，增加服务器的数量会改变给定输入的散列函数的结果。窍门是想出一个不依赖于服务器数量的散列函数？如果是这样，一个电子邮件系统会是什么样的例子？

那么，当您需要开发一个可扩展的系统（如Gmail）时，使用什么样的分片技术呢？

Answer 1

我更喜欢妥协。假设我今天有十几块碎片。我可能会用1024个条目的散列表。每个条目都会说出这些用户所在的十几个碎片中的哪一个。

优点：

• 甲管理表的大小（1024）。
• 通过将一个散列值从一个碎片移动到另一个碎片进行负载平衡。甚至在添加新分片时使用它。