数据库分片策略

Question

针对正在开发中的在线市场产品，我需要实现一个数据库分片解决方案。我对分片不是很熟悉，在阅读了这个论坛中的帖子后，我认为基于目录的业务实体分片策略比较适合。但是我仍然不清楚在这种分片解决方案中采用哪种去规范化和数据同步最佳实践。

有3个核心实体：供应商、客户和订单。我计划根据供应商ID来分片数据库，因为大部分订单数据处理将由供应商管理员完成。这将确保供应商的订单从单个DB实例中获取，消除了跨DB获取的情况。然而，在这种情况下，当客户查看他们的订单信息时，该数据将驻留在多个DB实例中，并且需要进行多数据库获取。在分片解决方案中遇到这种情况时通常会采取什么措施呢？

- cosmos

Answer 1

我认为你不需要分片的概率是99.9%。

如果：

• 你的数据库插入/更新速率接近或超过了你可以成本效益地购买的最高规格服务器的容量，且
• 你已经将大部分读取查询、报告和备份等工作委派给只读副本，
• 你已经进行了功能分区以将任何非必要或无关的更新密集型工作负载从主服务器中移除。

如果你不能对以上三个问题都回答“是”，那么你就不需要进行分片。

阅读：

http://www.mysqlperformanceblog.com/2009/08/06/why-you-dont-want-to-shard/

- MarkR

---

谢谢。我完全同意你的观点。然而，假设我必须进行分片，针对给定问题，什么是适当的策略呢？我的估算显示，如果不考虑历史/过去的数据，数据库大约会有1TB的大小。 - cosmos

我认为没有人能告诉你，如果你没有详细的信息来确定应用程序的哪些部分与数据库争用最多，那么你也无法知道。如果你正在进行分片，则可能已经耗尽了其他大部分途径。根据访问模式，1Tb并不是很大，可能仍然可以在一个盒子上运行（并具备相关故障转移等功能）。 - MarkR

Answer 2

数据库分片技术非常有效，即使在数据库大小还不到多个TB时也是如此。我们发现的主要原因是内存/CPU与磁盘的比例明显改变，而MySQL等DBMS产品非常擅长将最近使用的索引和数据放入内存中。

对于您的数据分片问题，这种技术可能会有所帮助。

并行查询（我们称之为“Go Fish”查询）。通过这个想法，您可以同时从多个分片查询客户订单，并汇总结果。如果做得好，这可以非常高效。

对于那些不经常更改的数据，我们通常建议使用全局表复制来处理常见的查找表，但对于像客户订单这样活跃的数据，这并没有太大帮助。

无论如何，分片可以以非常具有成本效益的方式实现，并且可以根据上述情况进行线性写入缩放，通常可以更好地进行读取缩放。

- dbschwartz

Answer 3

你可能也想尝试一下像mongodb或Cassandra这样的nosql数据库

你还可以使用memcache来缓存数据以实现快速访问

你还可以研究一下多个从库的主从复制。

- Tyuio

Answer 4

对于关系型数据库，Apache ShardingSphere 可以帮助您透明地进行数据分片。

它可以使用内置的分片算法和开发人员定义的自定义算法来进行数据分片。

只需使用 CREATE SHARDING RULE TABLE t_order ... 添加分片规则，其他 SQL 与原始数据库相同。

参考链接：https://shardingsphere.apache.org/document/current/en/features/sharding/

- Liang Zhang

---

虽然这个链接可能回答了问题，但最好在此处包含答案的基本部分并提供参考链接。如果链接页面更改，仅有链接的答案可能会失效。- 来自审查 - Procrastinator