访问速度，perl 二进制哈希文件 vs mySQL答案

【问题标题】：access speed, perl binary hash file vs mySQL访问速度，perl 二进制哈希文件 vs mySQL
【发布时间】：2011-02-15 21:32:26
【问题描述】：

我目前使用大量存储在多个文件位置的 perl 二进制哈希文件来将数据加载到这个 cgi 网站。我正在争论如果我决定将数据存储在那里，mySQL 会更快还是更慢。

有什么见解吗？我了解 perl 哈希已完全加载到内存中。

戈登

【问题讨论】：

“二进制哈希文件”是什么意思？您是否在使用带有 DB_File 之类的绑定哈希？
注意“开箱即用” MySQL 通常为非常旧的硬件提供默认配置设置，并且可以大幅调整到缓存中大多数数据站点的位置。我正在查看我最近在 deb6 上安装的 mysql 5.1。开场评论“以下值假设您至少有 32M 内存”！在线文档稍微好一点，但仍然过时了几年：dev.mysql.com/doc/refman/5.0/en/server-parameters.html
@snoopy：也许它“过时几年”的原因是因为您正在查看 MySQL 5.0 文档。尝试将 URL 中的 5.0 切换到 5.5 以获得更新的内容：dev.mysql.com/doc/refman/5.5/en/server-parameters.html
二进制哈希文件使用search.cpan.org/~ams/Storable-2.25/Storable.pm

标签： mysql perl

【解决方案1】：

使用数据库意味着您的查找速度会变慢，但您的脚本会使用更少的内存。

使用内存中的哈希意味着您的查找速度会更快，但您的脚本会使用更多内存。

如果您没有内存问题并且您的哈希值永远不会变大，那么请继续使用它们。

如果您没有内存问题并且您的哈希值会变大，请考虑使用数据库。

如果您遇到内存问题，请使用数据库。

如果您想使用数据库来使用数据库（即学习新技能），那么请使用数据库。

【讨论】：

关于数据库的另一点要提到的是，如果您曾经扩展到单台机器之外，那么数据库比尝试在多台机器上保持多个 db 文件同步更容易。

【解决方案2】：

如果 Perl 哈希处理您的数据需求，您可能不需要完整的 SQL 数据库的开销。键-> 值存储有很多存储替代方案，例如 Berkley DB 和整个“NOSQL”运动。谷歌这些，你会发现很多信息。 CPAN 中存在许多 Perl 接口。

【讨论】：

MySQL（使用 MyISAM）是一个非常快速的键值存储。而且您还可以使用 SQL 让普通人无需编写代码即可查询它。
@mpeters：当然，如果您要执行任意用户提供的 SQL，您需要实现可靠的用户身份验证和（可能）一些严格的输入清理。而且你对“正常人”的定义和我的有些不同……

【解决方案3】：

严格来说速度方面，除非您的数据适合放入数组中，否则在直接的内存哈希中找到单个、完全匹配的键几乎是最好的。（即，它将仅由一系列数字键访问，这些数字键形成从 0 开始的大部分连续范围。）

如果您有多个可能需要搜索的键（例如，姓名和员工 ID），或者如果您需要进行并非严格基于平等的搜索（例如，“查找所有员工的最后一个name 'Smith'")，那么你会因为需要搜索哈希键而显着减慢速度，并且数据库开始看起来好多了。

整体性能的另一个因素是您提到您的哈希“存储在多个文件位置”。如果您只进行一次或几次查找，则将这些文件中的哈希值读入内存也需要时间，这再次使事情倾向于使用数据库，这将最大限度地减少从磁盘读取的不需要的数据量。

因此，这在很大程度上取决于您需要如何访问数据和访问模式。

【讨论】：

【解决方案4】：

除了已经提到的内容之外，您还可以通过数据库获得更大的可扩展性，因为它可以卸载到另一台服务器上。 MySQL 多年来一直致力于使复杂的查找更快，这是您不必编写的代码。使用二进制哈希，您可以在不减慢应用程序速度的情况下担心同步到磁盘，确保磁盘写入、维护和优化的原子性，以及在多个进程同时访问数据时处理同步。使用数据库可以为您处理所有这些问题。

另一方面，数据库意味着 I/O 的额外延迟，因为查询是通过网络或本地套接字发送和接收的结果。不要低估您可以在这里花费的时间，尤其是随着数据集的增长。

在哈希驱动程序上编写通用 API 通常是个好主意。然后，当可伸缩性或并发性成为问题时，您只需添加一个 MySQL 驱动程序并迁移您的数据。诚然，这是一个很大的“公正”，但这是一种快速而简单的前进方式，可以在需要更改时限制对软件其余部分的影响

【讨论】：