MySQL 分区/分片/分割——该走哪条路？
https://stackoverflow.com/questions/45879
-
09-06-2019 - |
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
Russian题
我们有一个大约 70 GB 的 InnoDB 数据库，我们预计它会在未来 2 到 3 年内增长到几百 GB。大约 60% 的数据属于单个表。目前数据库运行得很好，因为我们有一台 64 GB RAM 的服务器，所以几乎整个数据库都可以装入内存，但我们担心未来数据量会相当大。现在我们正在考虑某种方式来拆分表格（尤其是占数据最大部分的表格），我现在想知道最好的方法是什么。
我目前知道的选项是
- 使用MySQL 5.1版本自带的分区
- 使用某种封装数据分区的第三方库（如 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。
当前硬件设置：
- 惠普 ProLiant DL 580
- 4 个英特尔(R) 至强(R) CPU E7-4830
- 256 GB 内存
此设置的性能很好。
解决方案
如果您认为您将受到 IO/内存限制，我认为分区不会有帮助。像往常一样，首先进行基准测试将帮助您找出最佳方向。如果您没有 64GB 内存的备用服务器，您可以随时向供应商索要“演示单元”。
如果您不期望 1 个查询聚合报告，我会倾向于分片。我假设您会分片整个数据库，而不仅仅是您的大表：最好将整个实体保持在一起。好吧，无论如何，如果你的模型分裂得很好。
其他提示
一旦 42 GB 表不再适合内存，您肯定会开始遇到问题。事实上，一旦它不再适合内存，性能就会急剧下降。一种测试方法是将该表放在另一台 RAM 较少的计算机上，看看它的性能有多差。
首先，除非您还将某些表移动到单独的物理卷，否则拆分表并不重要。
这是不正确的。即使表位于同一驱动器上，分区（通过 MySQL 5.1 中的功能，或使用 MERGE 表的相同功能）也可以提供显着的性能优势。
举个例子，假设您正在使用日期范围对大表运行 SELECT 查询。如果表是完整的，则查询将被迫扫描整个表（在这种大小下，即使使用索引也会很慢）。分区的优点是您的查询只会在绝对必要的分区上运行。如果每个分区的大小为 1 GB，并且您的查询只需要访问 5 个分区即可完成查询，那么对于 MySQL 来说，合并的 5 GB 表比庞大的 42 GB 版本更容易处理。
您需要问自己的一件事是您如何查询数据。如果您的查询有可能只需要访问某些数据块（即日期范围或 ID 范围），某种类型的分区将被证明是有益的。
我听说 MySQL 5.1 分区仍然存在一些错误，特别是与 MySQL 选择正确的密钥有关。MERGE 表可以提供相同的功能，尽管它们需要稍多的开销。
希望有帮助...祝你好运！
这是一个很好的例子，说明了 MySql 分区在巨大数据流的现实示例中可以做什么：
希望对您的案例有所帮助。
不久前，在 Microsoft ArcReady 活动中，我看到了一个有关扩展模式的演示，可能对您有用。你可以 查看幻灯片 在线获取它。
我会选择 MariaDB InnoDB + 分区（按键或按日期，具体取决于您的查询）。
我这样做了，现在我不再有任何数据库问题了。
MySQL 可以在几秒钟内替换为 MariaDB...所有数据库文件保持不变。
首先，除非您还将某些表移动到单独的物理卷，否则拆分表并不重要。
其次，您想要移动的不一定是物理尺寸最大的桌子。您可能有一个较小的表，但它具有更多的活动，而您的大表则保持相当不变或仅附加数据。
无论你做什么，都不要自己实施。让数据库系统来处理它。
大桌子有什么作用。
如果您要拆分它，您有以下几种选择：
- 使用数据库系统拆分它（对此不太了解）
- 按行分割。
- 按列拆分。
只有当您的数据可以轻松地分成块时，才可以按行拆分它。例如就像是 大本营 拥有多个完全独立的帐户。您可以将 50% 的帐户保留在一张表中，将 50% 的帐户保留在另一台计算机上的不同表中。
按列拆分适用于行大小包含大文本字段或 BLOBS 的情况。如果您有一个包含（例如）用户图像和大量文本的表，您可以将图像放入完全不同的表中。（在不同的机器上）
你在这里打破了标准化，但我认为这不会造成太多问题。
像往常一样，首先进行基准测试将帮助您找出最佳方向。
这是大多数人告诉我的，所以我想我最终不得不服用那颗药......
您最终可能希望拆分那个大表。在考虑第二台服务器之前，您可能希望将其放在单独的硬盘上。使用 MySQL 进行此操作是最方便的选择。如果有能力，那就去吧。
但
实际上，一切都取决于您的数据库的使用方式。统计数据。
