Хранение большого количества изображений в единственном каталоге замедляют извлечение изображения?
Я регулярно использую вычисления сложности, в основном потому что я работаю в геопространственном домене с очень большими наборами данных, например, процессах, включающих миллионы и иногда миллиарды декартовых координат. Как только Вы начинаете поражать многомерные проблемы, сложность может быть реальной проблемой, поскольку жадные алгоритмы, которые были бы O (n) в одном размере внезапно, скачкообразно двигаются к O (n^3) в трех измерениях, и не требуется большого количества данных для создания серьезного узкого места. Как я упомянул в подобное сообщение , Вы также видите, что большая нотация O становится громоздкой, когда Вы начинаете иметь дело с группами сложных объектов переменного размера. Порядок сложности может также быть очень информационно-зависим с типичными случаями, работающими намного лучше, чем общие случаи для хорошо разработанного специальный алгоритмы.
также стоит протестировать Ваши алгоритмы при профилировщике, чтобы видеть, является ли то, что Вы разработали, тем, чего Вы достигли. Я нахожу, что большинство узких мест разрешено намного лучше с тонкой настройкой алгоритма, чем улучшенная скорость процессора по всем очевидным причинам.
Для большего количества чтения на общих алгоритмах и их сложностях я нашел работа Sedgewicks и информативный и доступный. Для пространственных алгоритмов O'Rourkes книга по вычислительной геометрии превосходна.
5 ответов
Количество файлов в каталоге не должно вообще влиять на время, необходимое для чтения данных файла, но оно может существенно повлиять на количество времени, необходимое для поиска файла, прежде чем вы сможете начните читать его.
Точные точки останова, в которых возникают основные проблемы, будут варьироваться от типа файловой системы к типу файловой системы, но, в целом, если вы говорите о нескольких сотнях файлов, вам не нужно сильно беспокоиться об этом. Если вы говорите о нескольких тысячах, стоит подумать и, возможно, провести небольшой тест, чтобы увидеть, как ваша файловая система и оборудование справляются с этим. Если вы говорите о десятках тысяч файлов, вам действительно нужно начать разбивать вещи. (У меня когда-то был сервер печати Linux / e2fs, на котором не было CUPS. t удалив свои файлы управления заданиями после того, как он завершил печать и собрал около 100 000 файлов в одном каталоге. Просто получение списка каталогов заняло более получаса, прежде чем он даже начал отображать любые имена файлов.)
Однако разделение их по имени пользователя может быть не лучшим выбором, поскольку у вас, вероятно, будет много пользователей, загружающих очень мало изображения и, возможно, пара, которая загружает сотни или тысячи изображений, потенциально создавая проблемы времени доступа в каталогах хранилища этих пользователей. Более серьезная проблема в этом сценарии заключается в том, что вы, вероятно, в конечном итоге (при условии успешного сайта) будете иметь тысячи или десятки тысяч пользователей, а большое количество подкаталогов так же плохо, как и большое количество файлов, для замедления доступа к вашему data.
Поскольку у вас будет временная метка, я бы, вероятно, поместил их в подкаталоги на основе последних трех цифр отметки времени. Это позволит относительно равномерно распределить файлы по 1000 подкаталогам и сохранить достаточно маленькое количество файлов в каждом каталоге. (Использование первых трех цифр приведет к тому, что один каталог будет заполнен перед переходом к следующему, вместо того, чтобы распределять их равномерно.) Если у вас все еще остается слишком много файлов в каждом подкаталоге (что, вероятно, означает, что вы имеете дело с несколькими миллиона загруженных изображений), вы можете добавить второй уровень для предыдущих трех цифр, так что файл upload-1234567890.jpg окажется в /567/890/upload-1234567890.jpg.
Это позволит относительно равномерно распределить файлы по 1000 подкаталогам и сохранить достаточно маленькое количество файлов в каждом каталоге. (Использование первых трех цифр приведет к тому, что один каталог будет заполнен перед переходом к следующему, вместо того, чтобы распределять их равномерно.) Если у вас все еще остается слишком много файлов в каждом подкаталоге (что, вероятно, означает, что вы имеете дело с несколькими миллиона загруженных изображений), вы можете добавить второй уровень для предыдущих трех цифр, так что файл upload-1234567890.jpg окажется в /567/890/upload-1234567890.jpg. Это позволит относительно равномерно распределить файлы по 1000 подкаталогам и сохранить достаточно маленькое количество файлов в каждом каталоге. (Использование первых трех цифр приведет к тому, что один каталог будет заполнен перед переходом к следующему, вместо того, чтобы распределять их равномерно.) Если у вас по-прежнему слишком много файлов в каждом подкаталоге (что, вероятно, означает, что вы имеете дело с несколькими миллиона загруженных изображений), вы можете добавить второй уровень для предыдущих трех цифр, так что файл upload-1234567890.jpg окажется в /567/890/upload-1234567890.jpg.Ответ на этот вопрос - «может быть». Возможно, с извлечением файла все в порядке, но если вам нужно провести какое-либо обслуживание в папке, это станет огромной головной болью, поскольку процессы пытаются перечислить списки каталогов.
Что могло бы улучшить ситуацию, так это ряд дополнительных каталоги в папке изображений (или два уровня, в зависимости от того, сколько изображений вы хотите сохранить), поэтому у вас есть такая иерархия:
siteroot
-- uploads
---- a
---- b
---- c
:
---- z
... а затем файлы сохраняются на основе их первой буквы (так что все изображения с именами, начинающимися с «а», перейдите в папку «а»). Вы могли бы иметь это как двух- или трехбуквенный суффикс (aa, ab, ac, ad ..., ba, bb, bc ..., zx, zy, zz) и, возможно, иметь иерархию под этим, так что вы разделите файлы в нескольких папках в зависимости от первых четырех символов имени.
Если файлам затем присваивается случайное буквенно-цифровое имя, это обеспечит равномерное распределение файлов по всем папкам (при достаточно большом размере выборки).
Возможно, вы захотите рассмотреть возможность сочетания вашего варианта (1 ) и разделение изображений по иерархии, как я описал выше. Это гарантирует, что, если один пользователь загрузит много файлов, вы будете защищены. Точно так же, если вы просматриваете множество пользовательских каталогов, тот же принцип применяется, чтобы гарантировать, что у вас нет 1 000 000 пользовательских каталогов под одним родителем.
Это гарантирует, что, если один пользователь загрузит много файлов, вы будете защищены. Точно так же, если вы просматриваете множество пользовательских каталогов, тот же принцип применяется, чтобы гарантировать, что у вас нет 1 000 000 пользовательских каталогов под одним родителем. Это гарантирует, что, если один пользователь загрузит много файлов, вы будете защищены. Точно так же, если вы просматриваете множество пользовательских каталогов, тот же принцип применяется, чтобы гарантировать, что у вас нет 1 000 000 пользовательских каталогов под одним родителем.Я думаю, что лучше всего подойдут подкаталоги в каталоге загрузок.
site root
--uploads
----username
------image1.jpg
------image2.jpg
------image3.jpg
----anotheruser
------image1.jpg
------image2.jpg
------image3.jpg
...
В зависимости от операционной системы хоста, слишком много файлов в одном каталоге может вызвать проблемы и проблемы с совместимостью. Кроме того, в зависимости от того, как вы получаете список изображений, это может вызвать проблемы с производительностью.
Кроме того, вариант 2 будет беспорядком. :)
Это зависит от файловой системы. Например, FAT16 имеет тенденцию работать довольно медленно, если в каталоге более 512 файлов. FAT32 и NTFS не имеют одинаковых ограничений, но также работают намного медленнее, если у вас очень большой объем файлов. Даже если вы используете одну из наиболее надежных файловых систем Linux, вы все равно сможете быстрее анализировать каталоги, если они меньше.
Я определенно выбрал бы №2 - разделение изображений на каталоги пользователем.
попробуйте использовать mongodb ... это база данных значения ключа, которая также позволяет хранить двоичные данные. Это очень быстро и эффективно, а также поддерживает сегментирование (размещение данных на нескольких машинах) из коробки
. Вам действительно не нужно, чтобы папки и папки были полны файлов. Управление этими папками занимает вечность, а изменение схемы именования / разделения позже - кошмар. Более того, если у вас заканчивается место на диске, у вас возникает проблема. Также для балансировки нагрузки наличие одного жесткого диска с файлами неэффективно