Каков наилучший способ хранить тысячи изображений в структуре папок Windows?

У нас есть сотни тысяч изображений jpg в структуре папок Windows, подобных этой, но с ними очень сложно взаимодействовать и работать с ними быстро (перечисление занимает много времени, копирование требует времени и т. Д.). Вот структура:

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/

Теперь просмотр этих изображений немного медленный, потому что есть ок. 10 000 папок в каждой папке X и перечисление тех просто занимает время.

Есть ли лучший способ организовать изображения с меньшим количеством подпапок / элементов? Повлияет ли изменение структуры на это?

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 непосредственных подпапок, но будет много дополнительных однозначных папок для разделения. Ускорит ли эта настройка просмотр и взаимодействие, когда несколько пользователей будут добавлять / копировать / удалять / и т. Д.?

Источник

3 ответа

Windows немного особенная, когда дело доходит до макета папок с каджиллионами файлов. Особенно изображения, так как Windows Explorer относится к ним особенным. Тем не менее, есть несколько руководящих принципов, чтобы следовать, чтобы вещи не выходили из-под контроля:

  • Если по какой-либо причине вы намерены просмотреть структуру каталогов в проводнике Windows, храните в каталоге не более 10000 записей (файлы и подкаталоги).
  • Если вы будете взаимодействовать с ним исключительно из клиентских утилит или кода, ограничение в 10 КБ будет гораздо более гибким.
  • Не создавайте слишком много подкаталогов, каждый создаваемый вами каталог - это еще одна отдельная операция, которую копия должна выполнять при копировании.
    • Если каждый файл создает N каталогов, число объектов файловой системы, созданных этим файлом, будет 1+N, что линейно масштабирует время копирования.
    • Короткое экспоненциальное дерево (т. Е. Три уровня каталогов, каждый с 256 подкаталогами) может удивительно масштабироваться до того, как вы достигнете предела 10K/per-directory.
  • Если вы обращаетесь к нему с помощью кода, перейдите к прямому открытию вместо анализа списков каталогов перед открытием. Сбой fopen(), за которым следует сканирование каталогов, выполняется быстрее, чем dir-сканирование, за которым следует во многих случаях гарантированный fopen().

Предостережения:

  • Количество файлов является неизменным, но количество каталогов зависит от вас. Сумма этих двух показателей влияет на скорость выполнения операций копирования.
  • Постарайтесь, если это вообще возможно, не просматривать Windows Explorer, если это не нужно. Он плохо справляется с большими каталогами, и вы ничего не можете с этим поделать.
Источник

В моем ответе много полезной информации о математике. Как влияет сложность каталогов на i-узлы?

При этом различные файловые системы обрабатывают большое количество файлов в каталогах различными способами. Некоторые в порядке с 10000 записей, другие с пряжкой. Как быстро придуманное практическое правило, 1000 - это, вероятно, хороший целевой предел, если у вас есть контроль дизайна. Записи в каталоге обычно хранятся в виде некоего списка, и приложение для чтения должно сортировать их порядок. Например, ls в мире Unix считывает вещи в память из каталога и затем распечатывает их в алфавитном порядке.

Взгляните на математику из другого вопроса. Также обратите внимание на то, что sysadmin1338 говорит о том, что Explorer ведет себя по-другому. Проводник создаст миниатюры всего, что он распознает как изображение, а затем прочитает миниатюры, чтобы отобразить их. Это много дискового ввода-вывода, чтобы посмотреть каталог, полный файлов.

Источник

В зависимости от того, есть ли у вас ресурсы для разработки такой системы, это звучит как хороший кандидат для базы данных SQL Server, использующей хранилище файлов FILESTREAM. Таким образом, вы оставляете организацию каталогов на SQL Server, и все, о чем вам нужно беспокоиться, это как вы сами управляете данными. Возможно, вы могли бы использовать SQL Express, поскольку данные FILESTREAM не учитываются при расчете размера базы данных.

Источник
Другие вопросы по тегам