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

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

В базе данных я укажу на URL-адрес изображения, но здесь проблема: я знаю, что нецелесообразно, чтобы все они сидели в одном каталоге на сервере, так как это замедляло бы доступ к обходу, как бы вы их сохранили? Какое-то дерево, основанное на имени jpeg/png?

Какие правила для разделения изображений вы бы мне рекомендовали?

(Он будет сфокусирован на использовании в cheapo dot coms, поэтому невозможно управлять сервером)

Ответ 1

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

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

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

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

Ответ 2

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

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

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

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

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

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

Ответ 3

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

12345 % 100 = 45
12345 % 1000 = 345

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

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

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

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

Ответ 4

Я знаю, что нецелесообразно, чтобы все они сидели в том же каталоге на сервере, что и медленный доступ к обходу.

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

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

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

Ответ 5

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

Ответ 6

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

Ответ 7

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

Пример

2009
-01
- 01
- 02
- 03
- 31

таким образом вы получите не более 3 папок в глубину.

Ответ 8

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

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

Ответ 9

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

Ответ 10

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

Ответ 11

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

Ответ 12

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