使用数据库而不是成千上万的小文件答案

【问题标题】：Using database instead of thousands of small files使用数据库而不是成千上万的小文件
【发布时间】：2011-07-16 17:59:33
【问题描述】：

在工作中，我开始研究一个每小时可能生成数十万个大部分是小文件的程序。我的前辈发现处理许多小文件会变得非常缓慢，因此他们采用了一些（在我看来）粗略的方法来缓解这个问题。

所以我问我的老板为什么我们不使用数据库，他给了我他那非常有名的我比你更了解的样子并告诉我显然一个数据库这么大不会有好的表现。

我的问题是，真的是这样吗？在我看来，数据库引擎应该能够比文件系统更好地处理这些数据。以下是我们具备的条件：

程序主要是写入数据。查询的频率要低得多，它们的性能也不是很重要。
每天可以生成数百万个文件。其中大部分都很小（几千字节），但有些可能很大。

如果您认为我们应该选择数据库解决方案，您认为哪种开源数据库系统效果最好？（如果我认为数据库肯定会更好地工作，那么无论老板说什么，我都会推动改变！）

【问题讨论】：

您的老板可以非常确定，数据库开发人员已经优化了数据库插入和检索，至少与您的前辈优化了对数千个小文件的访问一样多。许多用户发誓 MySQL 是一个开源数据库。许多这些用户运行着数十万条记录的数据库。性能比使用裸文件系统要好得多，部分原因是数据库表通常可以保存在内存中（您看，这只是其中一种优化技术）。 显然！ :-)

标签： database

【解决方案1】：

这是另一个“视情况而定”类型的问题。

如果您只是写入数据（一次写入，几乎不读取），那么只需使用文件系统。也许使用哈希目录的方法来创建很多子目录（在一个目录中有很多文件，事情往往进展缓慢。

如果您要编写数十万个事件以供以后查询（例如，查找 X > 10 和 Y

如果您正在编写数十万位非关系数据（例如简单的键值对），那么可能值得研究 NoSQL 方法。

最好的方法可能是将您能想到、衡量和比较的所有想法都制作成原型！

【讨论】：

谢谢。这可能就是我将要做的。我将特别关注 NoSQL 数据库，因为我们的数据大多类似于简单的键值对（带有一些不会在查询中经常使用的注释）。文件系统的一个问题是当我们有这么多文件时，有时甚至打开一个要写入的新文件也会很慢。也许文档存储或类似的东西会有所帮助。
对于 NoSQL 方法，请查看 MongoDB（以及对于大文件的 GridFS）。您需要针对您的用例测试性能，但这至少是一个相对简单的解决方案。

【解决方案2】：

作为一项影响最小的改进，我会将您的数百万个小文件拆分为一系列目录。所以假设你使用 uuids 作为文件名，我会在前面去掉多余的 urn:uuid:，然后根据第一个字母创建 16 个目录，并在其中根据第二个字母创建 16 个子目录，然后如果需要，可以添加更多级别。仅此一项就可以大大加快访问速度。此外，每当目录变空时，我都会将其删除，以确保目录条目本身不会变得越来越大。

【讨论】：