我们有一个大约70 GB的InnoDB数据库,我们预计它会在未来2到3年内增长到几百GB.大约60%的数据属于一个表.目前数据库运行良好,因为我们有一个64 GB RAM的服务器,所以几乎整个数据库都适合内存,但我们担心未来数据量会大得多.现在我们正在考虑某种方式来分割表格(尤其是占据数据最大部分的表格),我现在想知道,最好的方法是什么.
我目前知道的选项是
使用5.1版附带的MySQL分区
使用某种封装数据分区的第三方库(如hibernate分片)
在我们的应用程序中自己实现它
我们的应用程序基于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.
当前硬件设置:
HP ProLiant DL 580
4 x Intel(R)Xeon(R)CPU E7- 4830
256 GB RAM
此设置的性能很好.
一旦它不再适合内存,你肯定会开始遇到42 GB表上的问题.事实上,只要它不再适合内存,性能就会迅速降低.测试的一种方法是将该表放在具有较少RAM的另一台机器上,并查看它的执行效果有多差.
首先,除非您将某些表移动到单独的物理卷,否则切换表并不重要.
这是不正确的.分区(通过MySQL 5.1中的功能,或使用MERGE表的相同功能)可以提供显着的性能优势,即使表位于同一驱动器上也是如此.
例如,假设您使用日期范围在大表上运行SELECT查询.如果表是完整的,则将强制查询扫描整个表(并且在该大小时,即使使用索引也可能很慢).分区的优点是您的查询只能在绝对必要的分区上运行.如果每个分区的大小为1 GB,并且您的查询只需要访问5个分区就可以实现自己,那么组合的5 GB表比MySQL 42 GB版更容易处理.
您需要问自己的一件事是您如何查询数据.如果您的查询有可能只需要访问某些数据块(即日期范围或ID范围),那么某种分区将证明是有益的.
我听说MySQL 5.1分区还存在一些问题,特别是与MySQL选择正确密钥有关.MERGE表可以提供相同的功能,但它们需要稍多的开销.
希望有所帮助......祝你好运!
如果您认为您将受IO /内存限制,我认为分区不会有所帮助.像往常一样,首先进行基准测试将帮助您找出最佳方向.如果您没有备用64GB内存的备用服务器,您可以随时向供应商询问"演示单元".
如果你不期望1个查询汇总报告,我会倾向于分片.我假设你要整个数据库而不仅仅是你的大桌子:最好将整个实体保持在一起.好吧,无论如何,如果你的模型分裂得很好.
这是MySql分区在巨大数据流的实际示例中可以做什么的一个很好的例子:
http://web.archive.org/web/20101125025320/http://www.tritux.com/blog/2010/11/19/partitioning-mysql-database-with-high-load-solutions/11/1
希望它对您的案例有所帮助.
京公网安备 11010802040832号 | 京ICP备19059560号-6 