在单个文件系统上，我需要存储10亿个1KB文本文件。每个文件都有一个唯一的id字符串，应该进行性能优化。 什么是最好的？
EXT4 :(文件名的示例文件结构：kdWqpGQ1）
/kd/Wq/pG/Q1.file
或
/kdWqpGQ1.file
或者我应该避免这种情况并使用某种非关系型数据库吗？
此外，我总是可以将5TB的音量共享到5 * 1TB硬盘中，每个硬盘的容量超过200M。我想补充说1B文件是一个极限情况，我很可能只达到500M。
谢谢！
答案 0 :(得分：5)
“或者我应该避免这种情况并使用某种非关系型数据库？”
是的，当然。由于文件系统的工作方式，将数据放入十亿个不同的文件是一个非常糟糕的主意。可以把它想象成在一个大容器中以四分之一的形式储存10亿美元的财富。没有办法让存储方案“性能优化”。
Windows上常见的NTFS文件系统的理论限制约为40亿个文件。默认情况下，NTFS上的最小文件大小为4 kB，这意味着您的1 TB数据库只会因此而立即增长到4 TB。
你应该看一下像 sql 或 sqlite 这样的数据库系统。这些优点是您不必考虑命名方案和其他实际细节。您还可以设计一种自定义格式，将所有数据存储在几个文件中。 如果您提供有关您正在处理的数据类型的详细信息，可能有人会为您提供更具体的建议！
答案 1 :(得分：2)
你的第一个选择要快得多。
将文件系统中的目录视为文本文件，其中包含此目录中所有文件的未排序列表，其中包含在磁盘上查找文件的地址。要读取文件，您需要知道磁盘上文件的地址。如果你有一个像'/ myfilename'这样的路径，那么你需要找到文件/这是一个目录并包含该目录中的所有文件。您需要扫描此文件以获取条目'myfilename'，这可能在最坏的情况下要求您遍历整个文件。在平均情况下，将采用O（N / 2），而N显然是10亿（此目录中的总文件数）。
如果你有多个目录...总是在一个目录中说1000个文件，这样你就有3个级别的directorys，你的文件路径现在是/ A / B / myfilename，那么你需要先打开/目录，找到A（需要O（1000/2），打开该文件并再次找到B（O（1000/2））并再次打开该文件以查找myfilename（再次为O（1000/2））。所以添加它们将是3 * O（1000/2）= 1500，比我们之前的O（500.000.000）快很多。
这是始终牢记文件系统的一个非常重要的方面。如果你的目录可能会遇到危险而超出其中存储的10.000个文件，我强烈建议考虑将这些文件排序到子目录的策略。
是否应该更好地使用关系数据库取决于其他问题：您是否需要备份（同时创建）？您是否需要超出简单日记文件系统提供的事务？你需要并发控制吗？你需要搜索你的文件吗？您多久需要访问一次文件？您多久更改一次文件？
有关文件系统的进一步阅读，我推荐Tanenbaum的书籍现代操作系统（第6章“文件系统”），可在线获取：http://lovingod.host.sk/index.html?page=tanenbaum%2FOperating-Systems-Design.html