在 Windows 文件夹结构中存储数千张图像的最佳方法是什么？

Question

我们在这样的 Windows 文件夹结构中拥有数十万张 jpg 图像，但很难以快速的方式与它们交互和使用它们（列出需要时间，复制需要时间等）。这是结构：

images/
  1/
    10001/
      10001-a.jpg
      10001-b.jpg
      ...
      10001-j.jpg (10 images in each XXXXX folder)
    10002/
    10003/
    ...
    19999/
  2/
    20001/
    20002/
    20003/
    ...
    29999/
  3/
  4/
  5/
  6/
  7/
  8/
  9/

现在，浏览这些图像有点慢，因为有 appr。每个 X 文件夹中有 10 000 个文件夹并列出这些文件夹需要时间。

有没有更好的方法来组织具有较少子文件夹/项目的图像？把结构改成这样会有什么影响吗？

images/
  1/
    0/
      0/
        0/
          0/
          1/
          2/
          3/
          4/
          5/
          6/
          7/
          8/
          9/
          10000/ (image folder, same as path)
            10000-a.jpg
            10000-b.jpg
            ...
            10000-j.jpg (10 images in each image folder)
        1/
        2/
        3/
        4/
        5/
        6/
        7/
        8/
        9/
      1/
      2/
      3/
      4/
      5/
      6/
      7/
      8/
      9/
    1/
    2/
    3/
    4/
    5/
    6/
    7/
    8/
    9/
  2/
  3/
  4/
  5/
  6/
  7/
  8/
  9/

因此，定位图像 48617-c.jpg 将等于路径 4/8/6/1/7/48617/48617-c.jpg。

使用完整路径号为 48617 的单独文件夹的原因是为了简化完整的 10 个图像批次的复制（通过复制整个文件夹）。

现在...没有一个文件夹的直接子文件夹超过 11 个，但会有很多额外的个位数文件夹用于分隔。此设置是否会加快浏览和交互，让多个用户添加/复制/删除/等图像？

Answer 1

当涉及到包含大量文件的文件夹布局时，Windows 有点特殊。尤其是图像，因为 Windows 资源管理器对它们很特别。这就是说，有一些指导线遵循以让事情变得太失控了：

• 如果您出于任何原因打算从 Windows 资源管理器浏览目录结构，请将其保持在一个目录（文件和子目录）中的 10,000 个条目以下。
• 如果您将仅通过 cli 实用程序或代码与其交互，则 10K 限制要灵活得多。
• 不要创建太多的子目录，您创建的每个目录都是副本在复制时必须进行的另一个离散操作。
  • 如果每个文件创建 N 个目录，则该文件创建的文件系统对象的数量将是 1+N，这会线性扩展您的复制时间。
  • 一个简短的指数树（即三层目录，每层有 256 个子目录）可以在达到 10K/每个目录限制之前惊人地扩展。
• 如果您使用代码访问它，请直接打开而不是在打开之前解析目录列表。在许多情况下，失败的 fopen() 后跟目录扫描比后跟有保证的 fopen() 的目录扫描快。

注意事项：

• 文件计数是不可变的，但目录计数取决于您。这两个计数的总和会影响复制操作的速度。
• 如果可能，请尽量不要使用 Windows 资源管理器进行浏览，除非您必须这样做。它不能很好地处理大目录，而且您无能为力。