数据库分片策略
对于一个正在建设中的在线市场产品，我有一个需要实现数据库分片解决方案的情况。我刚开始使用分片，在阅读了这个论坛上的帖子后，我觉得使用业务实体的基于目录的分片策略将是合适的。但我仍然不清楚这种分片解决方案所采用的反规范化和数据同步的最佳实践。将有3个核心实体，供应商，客户和订单。我计划基于供应商id对数据库进行分片，因为订单数据的大部分处理将由供应商管理员执行。这将确保供应商的订单是从单个数据库实例中获取的，从而消除了交叉数据库获取。然而，在这种情况下，当客户查看他们的订单信息时，该数据将驻留在多个数据库实例中，并且将需要多个数据库获取。在分片解决方案中出现此类场景时通常会执行什么操作。
回答 4
Stack Overflow用户
发布于 2009-11-30 04:03:08
我认为有99.9%的可能性你不需要分片。
如果满足以下条件，则需要分片：
- 您的数据库insert /update rate接近或正在超过您可以经济高效地购买的最高规格服务器的容量
- 您已经将大部分读取查询、报告、备份等分包到只读复制从服务器
- 您已经进行了功能分区，以便将任何不必要或不相关的繁重更新工作负载从主服务器
如果以上三种情况你都不能肯定回答“是”，你就不需要分片了。
朗读
http://www.mysqlperformanceblog.com/2009/08/06/why-you-dont-want-to-shard/
Stack Overflow用户
发布于 2010-08-22 05:37:22
数据库分片可能非常有效，甚至在数据库达到数TB大小之前也是如此。我们发现的主要原因是内存/CPU/磁盘的比率发生了显著变化，而MySQL等数据库管理系统产品在将最近使用的索引和数据放入内存方面非常出色。
对于您的数据分片问题，此技术可能会有所帮助。
- 并行查询(我们称之为"Go
- “查询)。使用此思路，您可以同时从多个分片查询客户订单，并合并结果。如果处理得当，这将是非常有效的。
对于变化不大的数据，我们通常建议对通用查找表使用全局表复制，但这不会对像客户订单这样活跃的数据有太大帮助。
在任何情况下，分片都可以以非常经济高效的方式实现，并且可以针对写入进行线性扩展，并且通常比针对基于上述内容的读取进行线性扩展更好。
Stack Overflow用户
发布于 2010-08-22 05:45:12
您可能还想尝试使用nosql DB，如mongodb或Cassandra
您还可以使用memcache缓存数据以进行快速访问
您还可以研究具有多个从设备的主从复制。
https://stackoverflow.com/questions/1815061
复制相似问题
腾讯云开发者
