performance - 拥有 6000 个目录，每个目录包含 6000 个文件是不是一个坏主意？

这是一个奇怪的问题，我知道。但我正在编写一些代码并处理我正在生成的大量平面文件。我不能使用任何类型的数据库（由于各种不相关的原因）。但是目前我正在生成大约 4GB 的数据，并且在这些文件上读取或执行某些搜索操作非常慢。

我一直在研究这些结构，并找出执行搜索操作的最有效方法是，如果我有效地拥有一个文件结构，其中大约有 6000 个目录，每个目录中大约有 6000 个文件。是的，这意味着我总共将拥有 36,000,000 个非常轻量级的文件（比如说 100 KB？）。

我认为像这样构造它们会更有效的原因是我的代码可以相对快速地定位和打开文件，但是如果文件很大，它需要很长时间才能读取并加载到 RAM 中，这使得事情变得超级慢.

所以我的问题真的是，对我来说，做这个 3600 万个文件结构听起来是个好主意，但是重构代码来设置它对我来说很痛苦，我不想这样做来实现新的问题，所以想知道是否有人有这方面的经验，以及这是否是一个坏主意？

编辑附加信息：这些文件将有效地存在于文件系统安装到 docker 容器上的 Ubuntu 操作系统上。我还有一个要求（不太重要）将这些文件压缩并将它们发送到另一台服务器（可能是令人讨厌的窗口）。

标签： performancelarge-files

你说你can't use any kind of database，但你能做一个吗？你的文件有长度限制吗？假设 100K 是最大大小。然后，您可以拥有 6,000 个文件，其中每个文件包含 6,000 个 JSON 数据片段，开始于 100K 标记。

这听起来有点局限。或者，您可以在每个文件中构建一个索引：每个 JSON 有 6,000 个 int 偏移量。

这些方法提供对您的“文件”的随机访问。

如果您需要修改这些 JSON，第一种方法更容易。