mysql– 数据库分片策略

概述对于正在建设的在线市场产品,我有一种情况需要实施数据库分片解决方案.我是分享新手,在阅读本论坛的帖子后,我觉得使用商业实体的基于目录的分片策略将是合适的.但我仍然不清楚采用这种分片解决方案的非规范化和数据同步最佳实践.将有3个核心实体,供应商,客户和订单.我打算根据供应商ID对数据库进行分片,因为订单数据的大多数处理都将由供应商管理员执行.这将确保从单个数据

对于正在建设的在线市场产品,我有一种情况需要实施数据库分片解决方案.我是分享新手,在阅读本论坛的帖子后,我觉得使用商业实体的基于目录的分片策略将是合适的.但我仍然不清楚采用这种分片解决方案的非规范化和数据同步最佳实践.
将有3个核心实体,供应商,客户和订单.我打算根据供应商ID对数据库进行分片,因为订单数据的大多数处理都将由供应商管理员执行.这将确保从单个数据库实例中获取供应商的订单,从而消除交叉数据包提取.但是,在这种情况下,当客户查看其订单信息时,数据将驻留在多个数据库实例中,并且需要多数据库提取.当这种情况出现在分片解决方案中时,通常会采取什么措施.最佳答案我认为有99.9％的可能性你不需要分片.

您需要分片,如果：

>您的数据库插入/更新速率接近或超过了您可以经济高效地购买AND的最高规格服务器的容量
>您已经将大多数读取查询,报告,备份等工作转移到只读复制的从属服务器上
>您已完成功能分区,以从主服务器移出任何不必要或不相关的更新大量工作负载

如果您不能对上述所有三个说“是”,那么您不需要进行分片.

读

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

以上是内存溢出为你收集整理的mysql – 数据库分片策略全部内容，希望文章能够帮你解决mysql – 数据库分片策略所遇到的程序开发问题。

如果觉得内存溢出网站内容还不错，欢迎将内存溢出网站推荐给程序员好友。