有没有人有一个方法/公式等，我可以使用 – 希望基于当前和预计数量的文件 – 投影拆分的“正确的”长度和嵌套文件夹的数量？
请注意，虽然相似，但与在文件系统中存储一百万张图像不太一样。 我正在寻找一种方法来帮助使理论更加通用。
假设
换一种方式
随着时间的推移，这家店将会增长。 我希望在当前的performance上达到最佳平衡，并且随着我的需求的增加。 说我把存储空间增加了一倍或三倍。 我需要能够解决当前的需求和未来的增长。 我需要提前计划，而不是牺牲太多目前的performance。
我想到了什么
我已经在考虑对每个如此多的字符使用散列分割来将事物分割到多个目录中，并保持树木的均匀性，这与上面问题中的注释中所述的非常相似。 它也避免了重复的文件，随着时间的推移这将是至关重要的。
我确定最初的文件夹结构将根据我所概述的内容以及最初的比例而不同。 据我所知，这里没有一个适合所有的解决scheme。 通过实验工作来完成这项工作是非常麻烦的。
几年前我开始写一个类似于ceph的存储系统。 然后我发现了ceph，他们的工作做得更好，所以我抛弃了我的发展。
在开发过程中，我向你们提出了一个类似的问题，但在SA上，我在处理大量小文件方面做了大量计算，发现通过uuid命名文件（假设它们可以是任何东西）并将其分成三级，足够我的需要。
从内存中，我用前3个字母组成顶层，接下来3个组成2层，然后使用整个uuid作为文件名。
我的计算是基于我想要的文件数量和每个驱动器存储的数据量以及文件系统types的限制。
对于UUID，如果使用hex版本，则可以得到AZ，az，0-9，例如26 + 26 + 9或61.对于3个深度即61 * 61 * 61 = 226,981。 我想226k目录组合是充足的。 对于XFS，这很好。 但是对于NTFS我不确定。 所以你最好找出真正的限制是什么。 只是通过打开资源pipe理器列出许多目录可能会导致您的服务器有所磨损。 所以你可能想要一个没有顶级文件夹的scheme。 也许使用一个单一的字母，并深入到4个层次或什么东西。
您不提供您将使用的Windows版本。 我真的推荐使用2012 R2从NTFS获取所有新function，如热修复。
你的3个噩梦将是：
chkdsk 。 它的时间是基于文件的数量，而不是大小。 如果你至less在Windows 2012上，你应该看看ReFS。 这个新的文件系统有你想要的： http : //msdn.microsoft.com/en-us/library/windows/desktop/hh848060(v=vs.85).aspx
ReFS问题你可能有：pipe理安全和备份软件。
如果你坚持使用NTFS，我将在大量NTFS驱动器（使用安装点）上分割数据，并使用DFS访问它们（以便将一个根文件夹链接到另一个驱动器，然后再传输到另一个服务器） 。
你应该寻找一个磁盘碎片整理软件，比如o＆o，远远超过windows。 从开始就开始碎片整理，并尽可能经常。
你将需要大量的RAM来caching文件（如果不止一次访问）。