大型数据集的最佳数据库引擎答案

【问题标题】：Best database engine for huge datasets大型数据集的最佳数据库引擎
【发布时间】：2010-11-22 05:15:15
【问题描述】：

我从事数据挖掘工作，我的工作涉及将 +1GB 的数据库转储文件加载和卸载到 MySQL 中。我想知道在大型数据库上是否有任何其他免费数据库引擎比 MySQL 更好？ PostgreSQL 在性能方面更好吗？

我只使用基本的 SQL 命令，所以速度是我选择数据库的唯一因素

【问题讨论】：

1) 您使用什么样的数据挖掘工具？该工具是否需要 JDBC 访问权限？ 2) 为什么需要进行装载/卸载？ 3）性能通常涉及改进硬件，您当前的配置是什么，您有升级预算吗？
您目前使用的是什么数据库引擎？ InnoDB、MyISAM 等...？
1GB 的数据库很难达到“巨大”的境界。甚至 SQLite 也可以轻松管理多达 3.5GB 的数据库。在这里，设计和优化技术是最重要的。

标签： mysql database postgresql mysqldump data-mining

【解决方案1】：

替换不同的数据库引擎不太可能显着提高性能。您提到的减速更可能与您的架构设计和数据访问模式有关。也许您可以提供更多有关此的信息？例如，数据是否存储为时间序列？记录是顺序写入一次还是任意插入/更新/删除？

【讨论】：

【解决方案2】：

如果您正在进行数据挖掘，也许您可以使用面向文档的数据库。如果你不使用我的 SQL，这些比关系数据库更快。

MongoDB 和CouchDB 都是不错的选择。我更喜欢 MongoDB，因为我不懂 Java，而且发现 CouchDB 更容易启动和运行。

这里有一些关于该主题的文章：

【讨论】：

【解决方案3】：

您的问题含糊不清，无法有效回答。 “性能”对不同的人意味着许多不同的东西。我可以评论 MySQL 和 PostgreSQL 在一些可能很重要的领域中的比较，但是如果没有信息，很难说出其中哪些对你来说真正重要。我在Why PostgreSQL Instead of MySQL: Comparing Reliability and Speed 上写了更多关于这个主题的背景信息。哪个更快当然取决于你在做什么。

是不是加载数据到数据库太慢的问题？这是 PostgreSQL 不太擅长的一个领域，Postgres 中的 COPY 命令并不是一种特别快速的批量加载机制。

是查询运行太慢的问题吗？是吗，它们有多复杂？在复杂的查询中，PostgreSQL 优化器可以比 SQL 中的优化器做得更好，特别是在涉及许多表连接的情况下。小型、简单的查询往往在 MySQL 中运行得更快，因为它没有在开始之前考虑如何执行查询；更智能的执行会产生一些开销。

涉及多少客户？ MySQL 可以在少量客户端上做得很好，在更高的客户端数量下，PostgreSQL 中的锁定机制可能会做得更好。

您关心交易完整性吗？如果没有，在 MySQL 中关闭更多这些功能会更容易，这与 PostgreSQL 相比具有显着的速度优势。

【讨论】：

【解决方案4】：

如果您的数据挖掘工具支持它，请考虑使用平面文件源。这应该可以节省您的大部分导入/导出操作。不过，它确实有一些警告：

您可能需要精通 Perl 或 Python 之类的脚本语言才能进行数据处理（假设您还不熟悉）。
如果您需要更多内存，您可能需要扩展计算机上的内存或转至 64 位平台。
您的数据挖掘工具可能不支持以这种方式处理平面数据文件，在这种情况下您会遇到麻烦。

现代磁盘 - 甚至 SATA 磁盘 - 将在顺序读取中从磁盘上拉出 100MB/秒左右的速度。这意味着某些东西可以相当快地吸入一个 1GB 的文件。

或者，您可以尝试在您的机器上安装 SSD，看看这是否会提高您的 DBMS 的性能。

【讨论】：

或者只是将你的内存升级到 8GB，创建一个足够大的 tmpfs RAM 磁盘，然后在随机访问友好的介质中进行与操作相关的所有随机访问？这可能是最便宜的方式，因为 2GB 内存条要 20 欧元。

【解决方案5】：

只要在插入大量数据之前删除索引，这两者之间应该没有太大区别。

【讨论】：

【解决方案6】：

我在当前项目中使用 PostgreSQL，并且还必须经常转储/恢复数据库。恢复 400Mb 压缩转储只需不到 20 分钟。您可以尝试一下，尽管需要调整一些服务器配置参数以符合您的硬件配置。这些参数包括但不限于：

shared_buffers
work_mem
temp_buffers
maintenance_work_mem
commit_delay
有效缓存大小

【讨论】：

temp_buffers 或 commit_delay 对大多数人都无效。涉及的整个功能 commit_delay 并没有真正起作用，并且 temp_buffers 的默认大小已经足够好，除非您真的严重依赖临时数据。现在最好的 PostgreSQL 服务器参数调整指南是wiki.postgresql.org/wiki/Tuning_Your_PostgreSQL_Server

【解决方案7】：

HDF 是例如 NASA 地球观测系统的存储选择。它并不完全是传统意义上的数据库，它也有自己的怪癖，但就纯粹的性能而言，它很难被击败。

【讨论】：