我pipe理一个包含一个文件存储的应用程序，在这个文件存储中，所有文件的文件名都等于他们的md5总和。 所有文件都存储在一个目录中。 目前有成千上万，但很快它们应该是服务器上的数百万个文件。 当前服务器在ext4文件系统上运行Ubuntu 11.10。
有人告诉我，把许多文件放在一个目录中是不明智的，因为这会大大增加查找时间和可靠性（他有一个单个目录可能指向的最大文件的故事，导致一个大的链接列表）。 相反，他build议创build子目录，例如文件名的子string。 但是，这会使我的应用程序中的一些事情变得更加繁琐。
这仍然是真的，或者现代文件系统（如ext4）有更有效的方法来处理这个问题，自然而然地扩展吗？ 维基百科有一些关于文件系统的细节，但是它并没有真正说明每个目录的最大文件或查询时间。
ext3及以后的文件系统支持散列B树目录索引。 只要你做的唯一操作是按名称添加，删除和访问，就可以很好地扩展。 但是，我仍然build议打破目录。 否则，你会为工具（ updatedb ， ls ， du等等）创build一个危险的诱杀陷阱，这个工具对目录中有太多条目的目录会执行其他操作。
问题的核心是挖掘你想要的一个文件的目录inode。 有些文件系统比其他文件系统做得更好。 一些规模接近数十亿，但如果你只有… 20K文件得到这些文件显着更快。 另外，大文件计数会给某些工具带来问题，因此可能会使备份/还原变得更加困难。
碰巧遇到了我们自己开发中完全相同的问题（文件名为md5sum，缩放比例）。 我向我们的开发者推荐的是将string切成小块。 他们四人一组，但是在当时我们所在的文件系统上，即使从性能的angular度来看，很多人也会遇到问题，所以他们最终以前三名的三分之一分组，terminal目录中的文件名。
4组： 4976/d70b/180c/6142/c617/d0c8/9d0b/bd2b.txt
3组： 497/6d7/0b1/80c/614/2c6/17d0c89d0bbd2b.txt
这样做的好处是可以保持较小的目录大小，而且由于MD5sum非常随意，它将创build平衡的目录树。 最后一个目录不太可能只有几个文件。 并不难于工作到我们的代码。 我们与数百万个文件项目合作，所以扩展对我们来说非常重要。
现代文件系统处理非常大的目录，甚至数百万个文件。 但传统工具不。 例如，用“ls”列出这样一个大的目录将花费相当长的时间，因为它通常会读取整个目录并对其进行sorting（尽pipe可以使用ls -f来避免sorting）。 直到全部被读取，它才开始显示文件。 在某些情况下，分割名称会有所帮助，但是不会（例如，rsync复制仍然需要收集整个名称树）。
我可以build议使用SQL数据库吗？ 这可能会将您认为的应用软件的弱点转化为实力。