数据库分片和分区资源

Question

我正在使用遇到可扩展性问题的数据库模式。该架构中的一个表已增长到大约 1000 万行，我正在探索分片和分区选项，以允许该架构扩展到更大的数据集（例如，10 亿到 1000 亿行）。我们的应用程序还必须可部署到多种数据库产品上，包括但不限于 Oracle、MS SQL Server 和 MySQL。

一般来说，这是一个大问题，我想了解一下可用的选项。有哪些关于数据库分片和分区策略的资源（书籍、白皮书、网站）？

Answer 1

我同意其他答案，即您应该在采用分片之前查看您的架构和索引。1000 万行完全在任何主要数据库引擎的能力范围内。

但是，如果您需要一些资源来了解分片主题，请尝试以下操作：

• 可扩展性最佳实践：易趣的教训
• Randy Shoup 谈 eBay 的架构原则 - 视频和演示
• 高可扩展性站点
• 先生。摩尔开始押注于分片（何时不这样做）

Answer 2

我同意Mike Woodhouse的观点，即目前的规模不应成为问题 - 提问者同意。

大多数商业DBMS在一些名称或其他名称下为某些或另一些提供了对碎片表的支持。其中一个关键问题是，是否有一种将数据分割成片段的合理方法。一种常见的方法是根据日期这样做，所以2008年11月的所有值都放在一个片段中，2008年10月放到另一个片段中，依此类推。当需要删除旧数据时，这具有优势。您可以从2001年10月（七年数据保留）中删除包含数据的片段，而不会影响其他片段。这种碎片化也有助于“消除碎片”;如果查询显然不需要从给定的片段中读取数据，那么它将保持未读状态，这可以为您带来惊人的性能优势。 （例如，如果优化器知道查询是针对2008年10月的日期，则它将忽略除包含2008年10月数据的片段之外的所有片段。）

还有其他碎片技术 - 循环法将负载分配到多个磁盘上，但意味着您无法从碎片消除中受益。

Answer 3

在DBMS术语中，1000万行真的不大，在开始使用分片或分区来规划数据的物理分布之前，我首先要查看我的索引和查询计划，在您的表格之前不应该这样做。增长了几个数量级。

当然，所有恕我直言。

Answer 4

根据我的经验，大型表总是在I / O端遇到你。最便宜的解决方案是添加足够的多列索引，以便所有查询都可以直接从索引获取数据，而无需加载主数据页。这使您的插入和更新更加I / O密集，但这可能没问题。 下一个简单的选项，它可以最大化服务器中的RAM。如果你的数据库很大，没理由少于32GB。 但最终你仍然会发现自己的I / O受限，而且你会考虑购买大量的硬盘并维护一个复杂的分区方案，这需要硬件和劳动力之间的财富。我希望现在有一个更好的选择 - 将数据库从旋转硬盘驱动器转移到SLC固态驱动器 - 这应该使您的随机读写速度比SAS驱动器顶部快一百倍，并删除I / O瓶颈。固态硬盘的起价为10美元/千兆字节，因此您需要花费一些时间，但它仍然比SAN等便宜得多。