真实世界数据库切分技术
我试图了解在现实世界中，数据库分片的一些好做法是什么。如果你有一个像Gmail这样的系统，那么做切分的理想方法是什么？
我看过这里，它提到了3种进行切分的方法。其中两个似乎是电子邮件系统的理想选择：
基于查找的分片，其中在前端机器上有一个查找表，将您路由到包含查询数据的后端。
基于哈希的切分，在输入查询中使用哈希函数标识包含数据的后端机器。
Lookup表的问题是它可能会快速增长，而且可能也需要分片。如果我们正在分割用于查找包含数据的碎片的查找表，这似乎不是一个好的设计。
当您必须向系统添加更多服务器时，基于哈希的切分将产生问题。典型的哈希函数将使用服务器数量来计算源碎片。因此，增加服务器数量将改变给定输入的哈希函数的结果。是否只想出一个不依赖于服务器数量的散列函数的诀窍？如果是的话，电子邮件系统的例子是什么？
那么，当您必须开发一个可伸缩的系统(如Gmail )时，应该使用什么好的切分技术呢？
回答 2
Stack Overflow用户
发布于 2016-04-26 00:13:00
我更喜欢妥协。假设我今天有一打碎片。我可能使用一个包含1024个条目的哈希表。每个条目都会显示用户居住的十几个碎片中的哪一个。
优势：
- 可管理的表大小(1024)。
- 通过将一个散列值从一个碎片移动到另一个碎片来实现负载平衡。或者在添加新的碎片时使用它。
Stack Overflow用户
发布于 2021-10-13 15:29:14
这可能会导致Lookup based sharding的性能问题，查询需要交叉两次。如果查找表也需要分块，问题也是一样的。Hash based sharding更好，但是当存储节点增加时，需要迁移数据。
我更喜欢Hash based sharding。但是我们需要一个迁移工具来管理自动扩展的数据。
也许Apache ShardingSphere可以解决数据迁移问题。有用于自动迁移的ShardingSphere-Sacling模块.系统不需要在数据迁移期间停止。
另外，该方案也可以解决透明切分问题。
ShardingSphere的FYI：https://shardingsphere.apache.org/document/current/en/user-manual/shardingsphere-scaling/
源代码：https://github.com/apache/shardingsphere/tree/master/shardingsphere-scaling
https://stackoverflow.com/questions/36851995
复制相似问题
腾讯云开发者
