是否有人有我可以使用的方法/公式等 - 希望基于当前和预计的文件数量 - 来预测分割的“正确”长度和嵌套文件夹的数量？
请注意，虽然类似，但并不完全相同在文件系统中存储一百万张图像。我正在寻找一种方法来帮助使所概述的理论更加通用。
假设
- 我有“一些”初始文件数量。这个数字是任意的，但很大。比如说 500k 到 10m+。
- 我已经考虑过支持此类努力所必需的底层物理硬件磁盘 IO 要求。
换一种方式
随着时间的推移，这家商店会发展壮大。我希望在当前性能和需求增长之间取得最佳平衡。假设我将存储量增加一倍或三倍。我需要能够同时满足当前需求和预计的未来增长。我需要提前规划，同时又不能牺牲太多当前性能。
我想到的是
我已经在考虑使用每隔几个字符进行一次哈希拆分，将内容拆分到多个目录中，并使树保持均匀，这与上述问题的评论中概述的非常相似。它还可以避免重复文件，这在一段时间内至关重要。
我确信初始文件夹结构会根据我所概述的内容以及初始规模而有所不同。据我所知，这里没有一个万能的解决方案。通过实验解决问题会耗费大量时间。
答案1
几年前我开始编写一个类似于 ceph 的存储系统。后来我发现 ceph 和它的一些功能更好，所以我放弃了开发。
在开发过程中我问过和你类似的问题，但是是关于 SA 我做了大量的计算来处理大量小文件，发现通过 uuid 命名文件（假设它们可以是任何内容）并将其分成 3 级深度足以满足我的需求。
从记忆中，我使用前 3 个字母构成顶层，然后使用接下来的 3 个字母构成第 2 级，然后使用整个 uuid 作为文件名。
我的计算基于我想要的文件数量、每个驱动器存储的数据量以及文件系统类型的限制。
对于 UUID，如果使用十六进制版本，您将获得 AZ、az、0-9，因此 26+26+9 或 61。对于 3 级深度，即 61*61*61 = 226,981。我认为 226k 个目录组合就足够了。对于 XFS，这没问题。但对于 NTFS，我不确定。所以你最好找出真正的限制是什么。仅通过打开资源管理器列出那么多目录可能会导致你的服务器有点卡顿。所以你可能想要想出一个在顶层没有那么多文件夹的方案。也许使用一个字母并深入 4 级或类似的东西。
答案2
您没有提供要使用的 Windows 版本。我真的建议使用 2012 R2 来获取 NTFS 的所有新功能，例如热修复。
你的 3 个噩梦将是：
- 碎片化
- 完成 所需的时间
chkdsk。其时间取决于文件数量，而不是大小。 - 备份时间
如果你至少在用 Windows 2012，那么你应该看看 ReFS。这个新文件系统有你想要的东西： http://msdn.microsoft.com/en-us/library/windows/desktop/hh848060(v=vs.85).aspx
您可能遇到的 ReFS 问题：管理安全和备份软件。
如果您坚持使用 NTFS，我会将数据拆分到多个 NTFS 驱动器上（使用挂载点），然后使用 DFS 访问它们（从而将一个根文件夹链接到不同的驱动器，然后链接到不同的服务器进行传播）。
您应该寻找一款碎片整理软件，例如 o&o，它比 Windows 碎片整理软件功能强大得多。从一开始就启动碎片整理，并尽可能频繁地启动。
您将需要足够的 RAM 来缓存文件（如果偶尔访问多次）。