我注意到一些应用程序或数据库使用a存储文件/ blob集合的情况必须确定路径和文件名。我相信预期的结果是路径永远不会太深，或者文件夹太满 - 文件夹中的文件（或文件夹）太多而导致访问速度变慢。
编辑：示例通常是数字图书馆或存储库，虽然我能想到的最简单的例子（可以在大约30秒内安装）是Zotero document/citation database.
为什么这样？
编辑：感谢Mat的答案 - 这种使用哈希创建文件路径的技术是否具有名称？它是模式吗？我想阅读更多内容，但未能在ACM Digital Library 中找到任何内容答案 0 :(得分：5)
当你只打算使用“=”运算符进行搜索时，哈希的优势在于可以更快地查看。
如果你打算使用像“＆lt;”这样的东西或“＆gt;”除了“=”之外的其他任何东西，你都会想要使用B：树，因为它可以进行那种搜索。
如果你有数十万个文件要存储在一个文件系统中并且你把它们全部放在一个目录中，那么你将会到达目录inode增长如此之大以至于需要几分钟才能添加/删除来自该目录的文件，您甚至可能会到达inode不适合内存的位置，并且您将无法添加/删除甚至触摸该目录。
你可以放心，对于散列方法foo，foo（“something”）将总是返回相同的东西，比如说“grbezi”。现在，您使用该哈希的一部分来存储文件，例如，在gr / be / something中。下次需要该文件时，您只需计算哈希值即可直接使用。此外，您可以获得这样的事实：使用良好的散列函数，散列空间中散列的散列非常好，并且对于大量文件，它们将均匀地分布在层次结构中，从而分割负载。
答案 1 :(得分：2)
我认为我们需要仔细看看你想要做什么。通常，散列和B树抽象地提供两种常见操作：“插入项”和“搜索项”。只要哈希函数表现良好，哈希就会在 O（1）时间内执行它们asymptotically（尽管在大多数情况下，针对特定工作负载的表现非常糟糕的哈希可以是与 O（n）一样糟糕。）相比之下，AB树需要 O（log n）时间进行插入和搜索。所以如果这些是您执行的唯一操作，则哈希表是更快的选择（如果您必须自己编写，则比实现B树要简单得多。）
当你想要添加操作时，踢球者会进来。如果你想做任何需要排序的事情（也就是说，按键顺序读取元素），你必须做其他事情，最简单的方法是复制和排序密钥，然后使用该临时表访问密钥。问题在于排序的时间复杂度是 O（n log n），所以如果你必须这样做，哈希表不再具有性能优势。
答案 2 :(得分：0)
哈希检查比遍历B树更快。因此，如果进行频繁的存在检查，则此方法可能很有用。除此之外，我并不真正理解这种情况，因为哈希表不会保留排序或层次结构。因此，如果需要单独遍历目录，则在其中存储目录结构似乎不可行。
答案 3 :(得分：0)
哈希还给出了路径名的唯一性。名字冲突很少。
答案 4 :(得分：0)
特别是Zotero实际上使用八个字符的字母数字唯一ID;它们不是与底层文件相关的任何哈希，它们实际上对应于Zotero数据库中的附件密钥（也用于使用Zotero API访问文件及其元数据）。密钥在本地Zotero实例中保证唯一（对于具有2821109907457项目的库），它与库密钥连接，以便在更大的Zotero世界中为附件创建全局唯一密钥。密钥在文件系统中大部分用于解决名称冲突和特殊字符。
我的理解是，您在库和存储库世界中看到的许多UUID在证明方面是相似的 - 它们比自动增量数字ID更容易发生碰撞，使许多事情变得更简单，但它们不是，与在git中用作提交标识符的正确SHA1哈希相反，必然是哈希。