MySQL的分区/分片/分裂 – 要走哪条路?

我们有一个大约70GB的InnoDB数据库,我们预计在未来的2到3年内它会增长到几百GB。 大约60%的数据属于一个表格。 目前数据库运行良好,因为我们有一个64 GB RAM的服务器,所以几乎整个数据库都适合内存,但是当数据量会大得多时,我们担心未来。 现在我们正在考虑某种方式来分割表格(特别是那些占据最大部分数据的表格),现在我想知道,最好的办法是什么。

我目前知道的选项是

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

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

你会build议什么?

编辑(2011-02-11):
只是更新:目前数据库的大小是380 GB,我们的“大”表的数据大小是220 GB,其索引的大小是36 GB。 所以当整个表格不再适合记忆的时候,索引就是这样。
系统仍然运行良好(仍然在同一个硬件上),我们仍然在考虑对数据进行分区。

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

这种设置应该持续两年。 然后,我们要么终于开始实施分片解决scheme,要么只购买带有1TB内存的服务器,这将使我们保持一段时间。

编辑(2016-01-18):

我们已经把自己的数据库放在一个单独的服务器上。 目前该数据库的大小约为1.9TB,其他数据库的大小(除“大”之外的所有表)为1.1TB。

当前硬件设置:

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

这个设置的性能很好。

如果你认为你将是IO /内存绑定,我不认为分区将是有帮助的。 像往常一样,标杆首先会帮助你找出最佳的方向。 如果您没有配备64GB内存的备用服务器,您可以随时向供应商索取“演示单元”。

如果不期望1个查询汇总报告,我会倾向于分片。 我假设你会分解整个数据库,而不仅仅是你的大桌子:最好把整个实体放在一起。 那么,如果你的模型很好地分裂,反正。

一旦它不再适合内存,你肯定会开始遇到这个42 GB表的问题。 事实上,一旦它不再适应内存,性能将会非常快地降低。 testing的一种方法是将该表放在另一台RAM较less的机器上,并查看其性能如何差。

首先,除非你将一些表格移动到一个单独的物理卷上,否则分开表格并不重要。

这是不正确的。 分区(通过MySQL 5.1中的function,或使用MERGE表格的function)可以提供显着的性能优势,即使这些表位于同一个驱动器上。

作为一个例子,假设您正在使用date范围在大表上运行SELECT查询。 如果表是完整的,则查询将被迫遍历整个表(并且在这个尺寸下,即使使用索引也可以很慢)。 分区的优势在于您的查询只能在绝对有必要的分区上运行。 如果每个分区的大小为1 GB,并且查询只需要访问5个分区以实现自身function,则合并的5 GB表比MySQL更容易处理,而不是42 GB的怪兽版本。

有一件事你需要问自己是如何查询数据。 如果您的查询有可能只需访问某些数据块(即date范围或ID范围),则某种分区将certificate是有益的。

我听说MySQL 5.1分区还存在一些问题,特别是与MySQLselect正确密钥有关的问题。 MERGE表可以提供相同的function,尽pipe它们需要稍微多一点的开销。

希望有帮助…祝你好运!

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

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

希望能对你的情况有所帮助。

回到Microsoft ArcReady事件,我看到了一个关于缩放模式的演示文稿,可能对您有用。 您可以在线查看幻灯片 。

我会去MariaDB的InnoDB +分区(按键或按date,根据您的查询)。

我做了这个,现在我没有任何数据库问题了。

MySQL可以在几秒钟内被MariaDB取代…所有的数据库文件保持不变。

首先,除非你将一些表格移动到一个单独的物理卷上,否则分开表格并不重要。

其次,它不一定是你想要移动的最大物理尺寸的桌子。 你可能有一个小得多的表,得到更多的活动,而你的大表保持相当不变或只附加数据。

不pipe你做什么,都不要自己去实现。 让数据库系统处理它。

大桌子做什么?

如果你要拆分它,你有几个select:
– 使用数据库系统进行分割(对此不太了解)
– 按行分割。
– 按列分割。

如果你的数据可以很容易地分成块,那么只能将它按行分割。 像Basecamp这样的东西有多个帐户是完全分开的。 您可以将50%的账户保留在一张表中,50%保留在另一台不同的计算机上。

按列拆分适用于行大小包含大型文本字段或BLOBS的情况。 如果你有一个表格(例如)一个用户图像和一个巨大的文本块,你可以把图像放到一个完全不同的表格中。 (在不同的机器上)

你在这里打破标准化,但我不认为这会造成太多的问题。

像往常一样,标杆首先会帮助你找出最佳的方向。

这是大多数人告诉我的,所以我想我终于要吃那个药了。

你可能想要最终分割那个大表。 在考虑第二台服务器之前,您可能需要将其放在单独的硬盘上。 用MySQL做是最方便的select。 如果有能力的话,就去做吧。

一切都取决于你的数据库如何被使用,真的。 统计。