mysql - 用于超大数据集的 RDBMS——人们在使用什么？

Question

我必须对存储在 MySQL 数据库中的非常大的数据集执行一些严肃的数据挖掘。然而，需要比基本 SELECT * FROM X WHERE ... 多一点的查询往往变得相当低效，因为它们返回大约 10e6 或更多的结果，尤其是当 JOIN 引入了一个或多个表 - 考虑连接包含数千万行的 2 个或多个表(过滤数据后)，这几乎在每个查询中都会发生。我们经常希望对这些(sum、avg、count 等)运行聚合函数，但这是不可能的，因为 MySQL简直窒息。

我应该注意到，为优化当前性能付出了很多努力——所有表都已正确索引并调整了查询​​，硬件是一流的，存储引擎已配置等等。然而，每个查询仍然需要很长时间 - 以至于“让我们在回家之前运行它并希望明天上类时最好”。不好。

这必须是一个可以解决的问题——许多大公司进行非常数据和计算密集型的挖掘，并且处理得很好(无需编写自己的存储引擎，谷歌)。我愿意接受时间惩罚来完成工作，但以小时为单位，而不是几天。我的问题是——人们用什么来解决这样的问题？我听说过针对这类问题的存储引擎(greenplum 等)，但我想听听通常是如何解决这个问题的。我们当前的数据存储显然是相关的，并且可能应该保持这种状态，但欢迎提出任何想法或建议。谢谢。

Answer 1

我建议使用 PostgreSQL，我已经在 ~0.5B 行的表上成功地使用了它，这些表需要一些复杂的连接操作。 Oracle 也应该对此有好处，但我没有太多经验。

应该注意的是，切换 RDBMS 并不是一个神奇的解决方案，如果你想扩展到那些规模，那么在优化你的查询、优化数据库结构和索引、微调数据库配置，根据您的使用情况使用正确的硬件，复制，使用物化 View (正确使用时非常强大。参见 here 和 here - 它特定于 postgres，但也适用于其他 RDBMS)...有些时候，你只需要在这个问题上投入更多的钱。

已编辑 修复了一些奇怪的拼写错误(无用的 android 自动更正...)并添加了一些关于物化 View 的资源