真实世界数据库分片技术

Question

我试图了解现实世界中数据库分片的一些好方法。如果您使用的是Gmail系统，那么分片的理想方式是什么？

我看了here，它提到了3种分片方法。似乎有两个似乎是电子邮件系统的理想选择：

基于查找的分片，您在前端机器上有一个查找表，可以将您转到包含查询数据的后端。

基于散列的分片，在输入查询中使用散列函数来标识包含数据的后端计算机。

Lookup表的问题在于它可能会快速增长，也可能需要进行分片。如果我们分析用于查找包含数据的分片的查找表，那么它似乎不是一个好的设计。

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

那么，当你必须开发像Gmail这样的可扩展系统时，使用什么是一个很好的分片技术呢？

Answer 1

我更喜欢妥协。我们今天说我有十几个分片。我可能会使用包含1024个条目的哈希表。每个条目都会说出这些用户所在的十几个分片中的哪一个。

优点：

• 可管理的表格大小（1024）。
• 通过将一个哈希值从一个分片移动到另一个分片来实现负载平衡。甚至在添加新分片时使用它。