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

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

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

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

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

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

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

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

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

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

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

Пример

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

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

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

12345 % 100 = 45
12345 % 1000 = 345

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

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

Или что-то типа того.

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

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

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

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

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

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

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

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

При сохранении файлов, связанных с идентификаторами 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;
}

I know is impractical to have all of them sitting at the same directory in the server as it would slow access to a crawl.

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

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

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

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

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