sql - 数据库分片和分区资源

Question

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

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

Answer 1

I agree with the other answers that you should look at your schema and indexes before resorting to sharding. 10 million rows is well within the capabilities of any of the major database engines.

However if you want some resources for learning about the subject of sharding then try these:

• Scalability Best Practices: Lessons from eBay
• Randy Shoup on eBay's Architectural Principles - Video and Presentation
• High Scalability Site
• Mr. Moore gets to punt on sharding (when not to do it)

Answer 2

我同意 Mike Woodhouse 的观点，即当前的规模不应该成为问题——提问者也同意。

大多数商业 DBMS 以某种名称或其他名称提供对碎片表的支持。关键问题之一是是否有一种明智的方式将数据拆分为片段。一种常见的方法是根据日期执行此操作，因此 2008 年 11 月的所有值都放在一个片段中，2008 年 10 月的所有值都放在另一个片段中，依此类推。这在删除旧数据时具有优势。您可能可以删除包含 2001 年 10 月（数据保留七年）的数据的片段，而不会影响其他片段。这种碎片化也有助于“碎片消除”；如果查询显然不需要从给定片段中读取数据，那么它将保持未读状态，这可以为您带来巨大的性能优势。（例如，

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

Answer 3

1000 万行在 DBMS 方面确实不算大，在开始规划带有分片或分区的数据物理分布之前，我会先查看我的索引和查询计划，这在你的表增长之前应该不是必需的几个数量级。

当然，所有恕我直言。

Answer 4

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