Ala*_*air 3 database filesystems xfs
我有 1500 万条简单的键/值记录。密钥大小都是单个字，它们包含的值的大小范围从每个字节几个字节到 10MB。
需要经常访问随机密钥。
我认为将它们作为文件存储在目录中而不是数据库中会更有效。因此，我不需要包含所有这些条目的庞大表，而是需要一个以文件名作为键和文件内的值的目录。
这意味着如果我想要 key 的值，azpdk我只需要file_get_contents('/my/directory/azpdk')在 PHP 中获取，而不是用这样的请求来麻烦 MySQL。
在我看来，这是有道理的，我希望使用文件系统而不是数据库来实现这一点会更有效。我的这个假设正确吗？当一个目录中有 1500 万个文件时，这仍然是快速和高效的吗？
仅供参考，文件系统是 xfs。
对于此类事情，您可能希望查看数据库（不一定是 MySQL）而不是文件系统，有几个原因：
一个目录中的文件过多会降低速度
尽管 XFS 在资源分配方面应该非常聪明，但大多数文件系统在单个目录中拥有的文件越多，性能就会下降。在命令行上处理它们也变得很头疼。看看这个（http://oss.sgi.com/projects/xfs/datasheet.pdf），上面有一个关于查找的图表，每个目录最多只能查找 50k，而且还在下降。
高架
每个文件都有一定量的文件系统开销。如果您有很多小文件，您可能会发现最终的存储因此而膨胀。
钥匙清洁
您的所有文字都可以安全地放入文件名中吗？你确定吗？那里的一两处斜线真的会毁了你的一天。
NoSQL 可能是一个不错的选择
像 MongoDB/Redis 这样的东西可能是一个不错的选择。MongoDB 可以存储最大 16mb 的单个文档，并且使用起来并不比把东西放在文件系统上难多少。如果您要存储 15mb 的文档，您可能会觉得有点太接近这个限制了，但还有其他选择。
这样做的好处是，查找性能可能会非常好，如果您后来发现它不是，您可以通过创建集群等来扩展性能。任何像这样的系统也能做得很好智能管理磁盘上的文件以获得良好的性能。
如果您要使用磁盘
考虑对要存储的单词进行 MD5 哈希，并以此为基础创建文件名。例如MD5为azpdk：
1c58fb66d5a4d6a1ebe5ec9e217fbbf9
您可以使用它来创建文件名，例如：
my_directory/1c5/8fb/66d5a4d6a1ebe5ec9e217fbbf9
这有一些不错的功能：
希望有帮助。