【发布时间】：2020-12-09 22:36:36
【问题描述】：
这是一个奇怪的问题，我知道。但我正在编写一些代码并处理我正在生成的大量平面文件。我不能使用任何类型的数据库（由于各种不相关的原因）。但目前我正在生成大约 4GB 的数据，读取或对这些文件执行某些搜索操作非常慢。
我一直在研究这些结构，并找出了执行搜索操作的最有效方法是，如果我有效地拥有一个文件结构，其中大约有 6000 个目录，每个目录中大约有 6000 个文件。是的，这意味着我总共将拥有 36,000,000 个非常轻量级的文件（比如说 100 KB？）。
我认为像这样构造它们会更有效的原因是我的代码可以相对快速地定位和打开文件，但是如果文件很大，它需要很长时间才能读取并加载到 RAM 中，这使得事情超级慢。
所以我的问题确实是，对我来说，做这个 3600 万个文件结构听起来是个好主意，但是重构代码来设置它对我来说很痛苦，我不想这样做解决新问题，所以想知道是否有人有这方面的经验以及这是否是一个坏主意？
编辑附加信息： 这些文件将有效地存在于文件系统安装到 docker 容器上的 Ubuntu 操作系统上。我还有一个要求（不太重要）将这些文件压缩并将它们发送到另一台服务器（可能是令人讨厌的窗口）。
【问题讨论】：
-
36,000,000 个文件 * 100 KB = 3.6 TB，而不是 4 GB。但是 6000 个条目还不错，尤其是对于执行目录索引或散列的文件系统。您需要确保它实际上具有容纳该数量文件的容量（例如，对于某些 Linux 文件系统，inode 的数量在您创建文件系统时是固定的）。如果您想详细说明操作系统和文件系统设置，您可以获得更详细的答案。
-
抱歉，太晚了，我已经连续编码了 15 个小时，所以请 cba 检查数学。关键是文件数量大致正确，文件重量轻，我们不是在谈论大文件和大量文件，而是在谈论非常小文件和大量文件。
-
作为对比，我的 Firefox 缓存目录包含 30000 个文件，没有问题。
-
您的文件系统共有 250 万个 inode，其中 238,000 个在使用中，其余 230 万个是免费的。这比 3600 万要少得多，因此您必须在另一个分区上使用不同的文件系统，或者使用更多 inode 重新创建这个文件系统（备份所有内容，使用更大的
-N参数执行mkfs.ext4或其他任何操作，然后恢复） . -
“抱歉，来晚了，我已经连续写了 15 个小时了，”——这就是你的问题！