☰

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

tag-icon • tag-icon performance directory images
Как лучше всего хранить тысячи изображений в структуре папок 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/

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

решение1

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

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

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

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

решение2

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

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

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

решение3

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

Связанный контент