数据库分片策略

Question

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

Answer 1

我认为你有99.9％的可能性不需要分片。

如果符合以下条件，则需要分片：

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

如果您不能对上述所有三个说“是”，则不需要进行分片。

读

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

Answer 2

数据库分片可能非常有效，甚至在您的数据库大小达到多个TB之前。我们发现的主要原因是内存/ CPU与磁盘的比率显着改变，而MySQL等DBMS产品在将最近使用的索引和数据放入内存方面非常出色。

对于数据分片问题，此技术可能有所帮助。

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

对于没有那么多变化的数据，我们经常建议对常见的查找表进行全局表复制，但这对于像客户订单一样活跃的东西也无济于事。

在任何情况下，分片都可以以非常经济的方式实现，并且可以线性地进行写入，并且对于基于上述的读取，通常优于线性。

Answer 3

您可能还想试用nosql数据库，例如mongodb或Cassandra

您还可以使用memcache缓存数据以便快速访问

您还可以查看具有多个从属的主从复制。