访问速度，Perl二进制哈希文件 vs MySQL

Question

访问速度，Perl二进制哈希文件 vs MySQL

mysqlperl

4

我目前使用很多Perl二进制哈希文件存储在多个文件位置，用于将数据加载到这个CGI网站中。我正在考虑如果我决定将我的数据存储在MySQL中，它是否会更快或更慢。

有什么见解吗？我知道Perl哈希完全加载到内存中。

Gordon

- Gordon

1

“二进制哈希文件”是什么意思？你是否使用了类似于DB_File的绑定哈希表？ - cjm

1

请注意，“开箱即用”的MySQL通常具有非常旧的硬件的默认配置设置，并且可以进行大幅度调整，以至于大多数数据站点都在缓存中。我正在查看我最近在deb6上安装的mysql 5.1。开头的评论是：“以下值假定您至少有32M内存”！在线文档稍微好一些，但仍然过时了几年：http://dev.mysql.com/doc/refman/5.0/en/server-parameters.html - dwarring

@snoopy：也许它“已经过时几年”是因为你正在查看MySQL 5.0文档。尝试将URL中的5.0切换为5.5，以获取更加当前的内容：http://dev.mysql.com/doc/refman/5.5/en/server-parameters.html - Dave Sherohman

二进制哈希文件是使用 http://search.cpan.org/~ams/Storable-2.25/Storable.pm 完成的。 - Gordon

4个回答

2

如果Perl哈希可以处理您的数据需求，那么您可能不需要完整的SQL数据库开销。对于键值存储，有许多存储替代方案，例如Berkley DB和整个“NOSQL”运动。请搜索相关信息，您会找到很多资料。对于这些内容，CPAN中存在许多Perl接口。

- Bill Ruppert

MySQL（使用MyISAM）是一个非常快速的键值存储。您还可以获得使用SQL的好处，让普通人查询它而无需编写代码。 - mpeters

@mpeters：当然，如果你要执行任意用户提供的SQL语句，你需要实现可靠的用户身份验证和（可能）一些严格的输入过滤。而你对“普通人”的定义与我有些不同... - Dave Sherohman

1

就速度而言，直接在内存哈希表中查找单个完全匹配的键是最好的方法，除非您的数据可以放入数组中（即，它将仅由一系列数字键访问，这些键形成从0开始的大多连续范围）。

如果您有多个可能需要搜索的键（例如，姓名和员工ID），或者如果您需要进行不严格基于相等性的搜索（例如，“查找所有姓氏为'Smith'的员工”），那么您将因需要搜索哈希键而显著减慢速度，此时使用数据库会更好。

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

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

- Dave Sherohman

0

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

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

通常编写一个通用的API覆盖哈希驱动器是一个好主意。然后，当可扩展性或并发性成为问题时，您只需添加一个MySQL驱动程序并迁移数据即可。当然，这是一个很大的“只是”，但如果需要进行更改，这是一种快速简单的前进方式，可以限制对其余软件的影响。

- Jeff Ober

网页内容由stack overflow 提供, 点击上面的

可以查看英文原文，
原文链接

- CanSpice · Accepted Answer

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

使用内存哈希表意味着您的查找将会更快，但是脚本将会使用更多的内存。

如果您没有内存问题，并且您的哈希表永远不会变得更大，则继续使用它们。

如果您没有内存问题，但是您的哈希表会变得更大，则考虑使用数据库。

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

如果您想为了学习新技能而使用数据库，则使用数据库。