1

我有 1500 万条简单的键/值记录。密钥大小都是单个单词，它们包含的值的大小范围从几个字节到每个 10MB。

随机键需要经常访问。

我认为将这些作为文件存储在目录而不是数据库中会更有效。因此，我不需要拥有包含所有这些条目的大量表，而是一个以文件名作为键和文件内的值的目录。

这意味着如果我想要 key 的值，azpdk我只需要file_get_contents('/my/directory/azpdk')在 PHP 中而不是用这样的请求来困扰 MySQL。

在我看来，这是有道理的，我希望为此使用文件系统而不是数据库更有效。我在这个假设中正确吗？在一个目录中包含 1500 万个文件时，这仍然会快速高效吗？

仅供参考，文件系统是 xfs。

4

2 回答 2

4

您可能出于以下几个原因想要查看数据库（不一定是 MySQL）而不是文件系统来处理这类事情：

一个目录中的更多文件会减慢速度

尽管 XFS 在分配资源方面应该非常聪明，但大多数文件系统的性能会随着单个目录中的文件越多而降低。在命令行上处理它们也变得很头疼。看看这个（http://oss.sgi.com/projects/xfs/datasheet.pdf）有一个关于查找的图表，每个目录最多只能达到 50k，而且它正在下降。

高架

每个文件都有一定数量的文件系统开销。如果您有很多小文件，您可能会发现最终存储因此而膨胀。

钥匙清洁

您的所有单词都可以安全地放入文件名吗？你确定吗？那里的一两个斜线真的会毁了你的一天。

NoSQL 可能是一个不错的选择

像 MongoDB/Redis 这样的东西可能是一个不错的选择。MongoDB 可以存储高达 16mb 的单个文档，并且在文件系统上放置东西并不难使用。如果您要存储 15mb 的文档，那么您可能会因为该限制太接近而无法舒适，但还有其他选择。

这样做的好处是，查找性能很可能一开始就非常好，如果你后来发现它不是，你可以通过创建集群等来扩展性能。任何像这样的系统也会做得很好智能管理磁盘上的文件以获得良好的性能。

如果你要使用磁盘

考虑获取您要存储的单词的 MD5 哈希，并以此为基础您的文件名。例如 MD5azpdk为：

1c58fb66d5a4d6a1ebe5ec9e217fbbf9

您可以使用它来创建文件名，例如：

my_directory/1c5/8fb/66d5a4d6a1ebe5ec9e217fbbf9

这有一些不错的功能：

  • 哈希处理可怕的角色
  • 目录分散了数据，所以没有目录有超过 4096 个条目
  • 这意味着查找性能应该相对不错

希望有帮助。

于 2014-05-01T19:42:19.607 回答
0

我在一个基因组学研究中心工作，那里的生物信息学不是特别有经验的程序员。

其中一些不会使用数据库，而是会生成数百万个小文件，直到文件系统停止运行。

于 2014-05-14T12:59:13.317 回答