Назад | Перейти на главную страницу

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

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

Если вы по какой-либо причине намереваетесь просматривать структуру каталогов в проводнике Windows, не превышайте 10 000 записей в каталоге (файлы и подкаталоги).
Если вы будете взаимодействовать с ним исключительно из утилит cli или кода, ограничение в 10 КБ будет гораздо более гибким.
Не создавайте СЛИШКОМ много подкаталогов, каждый создаваемый каталог - это еще одна отдельная операция, которую копия должна выполнять при копировании.
- Если каждый файл создает N каталогов, количество объекты файловой системы созданный этим файлом будет 1 + N, что линейно масштабирует время копирования.
- Короткое экспоненциальное дерево (то есть три уровня каталогов, каждый с 256 подкаталогами) может удивительно масштабироваться задолго до того, как вы столкнетесь с ограничением в 10 КБ на каталог.
Если вы обращаетесь к нему с помощью кода, используйте прямое открытие вместо анализа списков каталогов перед открытием. Неудачная попытка fopen () с последующим сканированием каталога во многих случаях выполняется быстрее, чем сканирование каталога с последующим гарантированным fopen ().

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

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

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

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

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

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