我们拥有一个大约70 GB的InnoDB数据库，我们希望在未来2到3年内它将增长到数百GB。大约60％的数据属于单个表。当前，数据库运行良好，因为我们有一台具有64 GB RAM的服务器，因此几乎整个数据库都可以装入内存，但担心将来数据量会大大增加。现在，正在考虑某种拆分表的方法(尤其是占数据最大部分的表)，而Im现在想知道，什么是最好的方法。

我目前知道的选项是

• 使用版本5.1附带的MySQL分区
• 使用某种第三方库来封装数据的分区(例如休眠分片)
• 在我们的应用程序中自己实现

我们的应用程序基于J2EE和EJB 2.1构建(希望有一天会切换到EJB 3)。

你有什么建议？

编辑(2011-02-11)：
只是更新：当前数据库的大小为380 GB，"大"表的数据大小为220 GB，其索引的大小为36 GB。因此，尽管整个表不再适合内存使用，但索引却适合。
系统仍然运行良好(仍在相同的硬件上)，并且我们仍在考虑对数据进行分区。

编辑(2014-06-04)：
再更新一次：整个数据库的大小为1.5 TB，我们的"大"表的大小为1.1 TB。我们将服务器升级到了具有128 GB RAM的4处理器机器(Intel Xeon E7450)。
系统仍然运行良好。
我们下一步要做的是将大表放在单独的数据库服务器上(我们已经对软件进行了必要的更改)，同时升级到具有256 GB RAM的新硬件。

此设置应持续两年。然后，我们将不得不最终开始实施分片解决方案，或者仅购买具有1 TB RAM的服务器，这将使我们继续运行一段时间。

编辑(2016-01-18)：

此后，我们已将大表放入单独服务器上自己的数据库中。当前，该数据库的大小约为1.9 TB，其他数据库(除"大"表以外的所有表)的大小为1.1 TB。

当前的硬件设置：

• 惠普ProLiant DL 580
• 4个Intel(R)Xeon(R)CPU E7- 4830
• 256 GB内存

此设置的性能很好。

解决方案

回答

首先，拆分表并不重要，除非我们还将某些表移到单独的物理卷上。

其次，不一定要移动最大物理尺寸的表。我们可能有一个较小的表，可以进行更多活动，而大表保持相当恒定或者仅添加数据。

无论我们做什么，都不要自己实施。让数据库系统处理它。

回答

前不久在Microsoft ArcReady事件中，我看到了有关缩放模式的演示，该演示可能对我们有用。我们可以在线查看幻灯片。

回答

大桌子做什么？

如果要拆分它，则有几种选择：
使用数据库系统对其进行拆分(对此了解不多)
按行拆分。
按列拆分。

仅当数据可以轻松地分成多个块时，才可以按行拆分它。例如诸如Basecamp之类的东西有多个完全独立的帐户。我们可以将50％的帐户保留在一个表中，而将50％的帐户保留在另一台计算机上的另一个表中。

按行拆分适用于行大小包含大文本字段或者BLOBS的情况。如果我们有一个包含(例如)用户图像和大量文本的表，则可以将该图像存储到一个完全不同的表中。 (在另一台机器上)

我们在这里破坏了规范化，但是我认为这不会引起太多问题。

回答

如果我们认为自己将受到IO /内存的限制，那么我认为分区将无济于事。像往常一样，首先进行基准测试将找出最佳方向。如果我们没有配备64GB内存的备用服务器，则可以随时向供应商索取"演示单元"。

如果我们不希望有1个查询汇总报告，则我倾向于分片。我假设我们将分片整个数据库，而不仅仅是大表：最好将整个实体保持在一起。好吧，无论如何，如果模型能够很好地拆分。

回答

As usual, benchmarking first will help you figure out the best direction.

那就是大多数人告诉我的，所以我认为我最终将不得不服用该药...

回答

我们可能最终希望拆分大表。在考虑第二台服务器之前，我们可能希望将其放在单独的硬盘上。使用MySQL进行操作是最方便的选择。如果有能力，那就去做。

但

实际上，一切都取决于数据库的使用方式。统计数据。

回答

一旦该42 GB的表不再适合内存，我们肯定会开始遇到问题。实际上，一旦它不再适合内存，性能就会迅速下降。一种测试方法是将该表放在内存较少的另一台计算机上，并查看其性能如何。

First of all, it doesn't matter as much splitting out tables unless you also move some of the tables to a separate physical volume.

这是不正确的。分区(通过MySQL 5.1的功能，或者使用MERGE表的相同方法)可以提供显着的性能优势，即使这些表位于同一驱动器上也是如此。

例如，假设我们正在使用日期范围在大表上运行SELECT查询。如果表是完整的，查询将被迫扫描整个表(以这种大小，即使使用索引也可能很慢)。分区的优点是查询将仅在绝对必要的分区上运行。如果每个分区的大小为1 GB，而查询只需要访问5个分区即可满足要求，那么合并的5 GB表对于MySQL而言要比42 GB的怪物版本容易得多。

我们需要问自己的一件事是如何查询数据。如果查询有可能只需要访问某些数据块(即日期范围或者ID范围)，则进行某种分区将被证明是有益的。

我听说MySQL 5.1分区仍然存在一些问题，特别是与MySQL选择正确的密钥有关。 MERGE表可以提供相同的功能，尽管它们需要更多的开销。

希望对我们有帮助...祝我们好运！

回答

这是一个在大型数据流的真实示例中MySql分区可以做什么的一个很好的例子：

http://web.archive.org/web/20101125025320/http://www.tritux.com/blog/2010/11/19/partitioning-mysql-database-with-high-load-solutions/11/1

希望对情况有所帮助。