Хранение большого количества изображений

У нас была похожая проблема в прошлом. И нашел хорошее решение:

• Дайте каждому изображению уникальный путеводитель.
• Создайте запись в базе данных для каждого изображения, содержащую имя, расположение, guid и возможное расположение вспомогательных изображений (эскизы, уменьшенный размер и т. Д.).
• Используйте первые (один или два) символа руководства для определения папки верхнего уровня.
• Если в папках слишком много файлов, разделите их снова. Обновите ссылки, и вы готовы к работе.
• Если количество файлов и доступов слишком велико, вы можете распределить папки по разным файловым серверам.

Мы убедились, что с помощью направляющих можно получить более или менее равномерное разделение. И это сработало как шарм.

Ссылки, которые могут помочь сгенерировать уникальный идентификатор:

• http://en.wikipedia.org/wiki/Universally_Unique_Identifier
• http://en.wikipedia.org/wiki/Sha1

Несколько лет назад я работал над системой электронного управления документами, и мы сделали в значительной степени то, что предлагали Gamecat и wic.

То есть назначьте каждому изображению уникальный идентификатор и используйте его для получения относительного пути к файлу изображения. Мы использовали MOD, аналогичный тому, что предлагал wic, но мы разрешили 1024 папки / файла на каждом уровне, с 3 уровнями, поэтому мы могли поддерживать файлы размером 1 ГБ.

Однако мы удалили расширение из файлов. Записи БД содержали MIME-тип, поэтому расширение не требовалось.

Я бы не рекомендовал хранить в записи БД полный URL, только ID изображения. Если вы сохраняете URL-адрес, вы не можете переместить или реструктурировать свое хранилище без преобразования вашей БД. Относительный URL-адрес был бы приемлемым, поскольку таким образом вы можете по крайней мере перемещать репозиторий изображений, но вы получите больше гибкости, если просто сохраните идентификатор и получите URL-адрес.

Кроме того, я бы не рекомендовал разрешать прямые ссылки на ваши файлы изображений из Интернета. Вместо этого предоставьте URL-адрес серверной программы (например, сервлета Java) с идентификатором изображения, указанным в URL-запросе (http://url.com/GetImage?imageID=1234).

Сервлет может использовать этот идентификатор для поиска записи БД, определения типа MIME, определения фактического местоположения, проверки ограничений безопасности, ведения журнала и т. Д.

Обычно я просто использую числовой идентификатор базы данных (auto_increment), а затем использую оператор модуля (%), чтобы выяснить, куда поместить файл. Просто и масштабируемо. Например, путь к изображению с идентификатором 12345 можно создать так:

12345 % 100 = 45
12345 % 1000 = 345

Заканчивается через:

/home/joe/images/345/45/12345.png

Или что-то вроде того.

Если вы используете Linux, ext3 и файловую систему, вы должны знать, что есть ограничения на количество каталогов и файлов, которые вы можете иметь в каталоге. Ограничение составляет 32000 каталогов, поэтому вы всегда должны стремиться к тому, чтобы количество каталогов оставалось низким.

Я знаю, что нецелесообразно размещать все они в одном каталоге на сервере, поскольку это замедлит доступ к сканированию.

Это предположение.

Я разработал системы, в которых миллионы файлов хранились в одном каталоге, и это прекрасно работало. Это также самая простая в программировании система. Большинство файловых систем сервера поддерживают это без проблем (хотя вам нужно будет проверить, какую из них вы используете).

http://www.databasesandlife.com/flat-directories/

При сохранении файлов, связанных с идентификаторами auto_increment, я использую что-то вроде следующего, которое создает три уровня каталогов, каждый из которых состоит из 1000 каталогов и 100 файлов в каждом каталоге третьего уровня. Это поддерживает ~ 100 миллиардов файлов.

если $ id = 99532455444, то следующие возвращают / 995/324/554/44

function getFileDirectory($id) {
    $level1 = ($id / 100000000) % 100000000;
    $level2 = (($id - $level1 * 100000000) / 100000) % 100000;
    $level3 = (($id - ($level1 * 100000000) - ($level2 * 100000)) / 100) % 1000;
    $file   = $id - (($level1 * 100000000) + ($level2 * 100000) + ($level3 * 100));

    return '/' . sprintf("%03d", $level1)
         . '/' . sprintf("%03d", $level2)
         . '/' . sprintf("%03d", $level3)
         . '/' . $file;
}

Посмотрите на файловую систему XFS. Он поддерживает неограниченное количество файлов, и Linux поддерживает это. http://oss.sgi.com/projects/xfs/papers/xfs_usenix/index.html

Вы можете иметь столбец DateTime в таблице, а затем хранить их в папках, названных по месяцам, годам или даже месяцам, дням и годам изображений, которые были добавлены в таблицу.

Пример

1. 2009
2. -01
3. --01
4. --02
5. --03
6. --31

таким образом у вас останется не более трех папок.

В настоящее время я столкнулся с этой проблемой, и то, что написал Исаак, заинтересовало меня этой идеей. Моя функция немного отличается.

function _getFilePath($id) {
    $id = sprintf("%06d", $id);
    $level = array();
    for($lvl = 3; $lvl >= 1; $lvl--)
        $level[$lvl] = substr($id, (($lvl*2)-2), 2);
    return implode('/', array_reverse($level)).'.jpg';
}

Мои изображения исчисляются тысячами, поэтому у меня есть только этот предел до 999999, и поэтому он разделится на 99/99 / 99.jpg или 43524 на 04/35 / 24.jpg

Используйте иерархию файловой системы. Идентифицируйте свои изображения, используя что-то вроде 001/002/003 / 004.jpg, было бы очень полезно. Однако разделение - это совсем другая история. Может быть случайным, на основе содержимого, на основе даты создания и т. Д. На самом деле зависит от вашего приложения.

Вы можете проверить стратегию, используемую Apple iPod для хранения мультимедийного контента. Есть папки на одном уровне глубины и файлы с заголовками одинаковой ширины. Я считаю, что ребята из Apple потратили много времени на тестирование своего решения, поэтому оно может принести вам мгновенную пользу.

Если изображения, которые вы обрабатываете, являются цифровыми фотографиями, вы можете использовать данные EXIF ​​для их сортировки, например, по дате съемки.

Вы можете хранить изображения в базе данных как большие двоичные объекты (varbinary для mssql ). Таким образом, вам не нужно беспокоиться о хранилище или структуре каталогов. Единственным недостатком является то, что вы не можете легко просматривать файлы, но в любом случае это будет сложно в сбалансированном дереве каталогов.