我有 1500 万条简单的键/值记录。密钥大小都是单个单词，它们包含的值的大小范围从几个字节到每个 10MB。
需要经常访问随机键。
我认为将这些作为文件存储在目录而不是数据库中会更有效。因此，我不需要一个包含所有这些条目的大型表，而是一个以文件名作为键并在文件中包含值的目录。
这意味着，如果我想要键 azpdk 的值，我只需要在 PHP 中使用 file_get_contents('/my/directory/azpdk')，而不是用这样的请求来困扰 MySQL。
在我看来这是有道理的，我希望为此使用文件系统而不是数据库更有效。我在这个假设中正确吗？如果在一个目录中有 1500 万个文件，这仍然会快速高效吗？
仅供参考，文件系统是 xfs。
【问题讨论】：
标签： database filesystems xfs
您可能出于以下几个原因想要查看数据库（不一定是 MySQL）而不是文件系统来处理这类事情：
一个目录中的更多文件会减慢速度
虽然 XFS 在分配资源方面应该非常聪明，但大多数文件系统的性能会随着单个目录中的文件越多而降低。在命令行上处理它们也变得很头疼。看看这个 (http://oss.sgi.com/projects/xfs/datasheet.pdf)，上面有一个关于查找的图表，每个目录最多只能达到 50k，而且还在下降。
开销
每个文件都有一定的文件系统开销。如果您有很多小文件，您可能会发现最终存储因此而膨胀。
按键清理
您的所有单词都可以安全地放在文件名中吗？你确定吗？那里的一两个斜线真的会毁了你的一天。
NoSQL 可能是一个不错的选择
像 MongoDB/Redis 这样的东西可能是一个不错的选择。 MongoDB 可以存储高达 16mb 的单个文档，并且在文件系统上放置东西并不难使用。如果您要存储 15mb 的文档，那么您可能会因为该限制太接近而无法舒适，但还有其他选择。
这样做的好处是，查找性能很可能一开始就非常好，如果您后来发现它不是，您可以通过创建集群等来扩展性能。任何类似这样的系统也可以很好地智能地管理磁盘上的文件以获得良好的性能。
如果你要使用磁盘
考虑对要存储的单词进行 MD5 哈希，并以此为基础创建文件名。比如azpdk的MD5为：
1c58fb66d5a4d6a1ebe5ec9e217fbbf9
您可以使用它来创建文件名，例如：
my_directory/1c5/8fb/66d5a4d6a1ebe5ec9e217fbbf9
这有一些不错的功能：
希望对您有所帮助。
【讨论】：
我在一个基因组学研究中心工作，那里的生物信息学不是特别有经验的程序员。
其中一些会生成数百万个小文件，而不是使用数据库，直到文件系统停止运行。
【讨论】：