Полагаю, зависит от того, как вы определяете «серьезные недостатки». Всегда есть компромиссы, и задача разработчика / системного архитектора состоит в том, чтобы сбалансировать эти компромиссы. Если вы действительно хотите наивысшего уровня эффективности, почему вы пишете свой сайт на PHP? Используйте сборку, это более эффективно.

учший метод, который я когда-либо придумал, и я хотел бы знать, есть ли еще лучший метод (я уверен, что есть!) Для хранения и извлечения миллионов пользовательских изображений:

Чтобы уменьшить размеры каталогов и избежать дополнительных вызовов к БД, я использую вложенные каталоги, которые рассчитываются на основе уникального идентификатора пользователя следующим образом:

$firstDir = './images';
$secondDir = floor($userID / 100000);
$thirdDir = floor(substr($id, -5, 5) / 100);
$fourthDir = $userID;
$imgLocation = "$firstDir/$secondDir/$thirdDir/$fourthDir/1.jpg";

ID пользователя ($userID) в диапазоне от 1 до миллионов.

Так что, если у меня есть идентификатор пользователя7654321Например, первая фотография этого пользователя будет сохранена в:

./images/76/543/7654321/1.jpg

Для идентификатора пользователя654321:

./images/6/543/654321/1.jpg

Для идентификатора пользователя54321 это было бы:

./images/0/543/54321/1.jpg

Для идентификатора пользователя4321 это было бы:

./images/0/43/4321/1.jpg

Для идентификатора пользователя321 это было бы:

./images/0/3/321/1.jpg

Для идентификатора пользователя21 это было бы:

./images/0/0/21/1.jpg

Для идентификатора пользователя1 это было бы:

./images/0/0/1/1.jpg

Это гарантирует, что с 100 000 000 пользователей у меня никогда не будет каталога с более чем 1000 подкаталогами, так что, похоже, все будет чисто и эффективно.

Я сравнил этот метод с использованием следующего метода «хэширования», который использует самый быстрый метод хэширования, доступный в PHP (crc32). Этот метод «хеширования» вычисляет Второй каталог как первые 3 символа в хэше идентификатора пользователя и Третий каталог как следующие 3 символа для распределения файлов случайным образом, но равномерно, следующим образом:

$hash = crc32($userID);
$firstDir = './images';
$secondDir = substr($hash,0,3);
$thirdDir = substr($hash,3,3);
$fourthDir = $userID;
$imgLocation = "$firstDir/$secondDir/$thirdDir/$fourthDir/1.jpg";

Однако этот метод «хэширования» медленнее, чем метод, описанный выше, поэтому он бесполезен.

Затем я пошел еще дальше и нашел еще более быстрый метод вычисления третьего каталога в моем исходном примере (floor(substr($userID, -5, 5) / 100);) следующее:

$thirdDir = floor(substr($userID, -5, 3));

Теперь это меняет то, как / где хранятся первые 10000 идентификаторов пользователей, в результате чего некоторые третьи каталоги имеют либо 1 пользовательский подкаталог, либо 111 вместо 100, но преимущество в том, что он быстрее, поскольку нам не нужно делить на 100, так что я думаю, что в конечном итоге это того стоит.

После того, как структура каталогов определена, я планирую сохранить фактические отдельные изображения: например, если пользователь загружает 2-е изображение, оно будет находиться в том же каталоге, что и первое изображение, но будет иметь имя2.jpg, Картинка по умолчанию для пользователя всегда будет1.jpgтак что, если они решат сделать свою вторую фотографию по умолчанию,2.jpg будет переименован в1.jpg а также1.jpg будет переименован2.jpg.

И последнее, но не менее важное: если бы мне нужно было хранить несколько размеров одного и того же изображения, я бы сохранил их следующим образом для идентификатора пользователя 1 (например):

1024px:

./images/0/0/1/1024/1.jpg
./images/0/0/1/1024/2.jpg

640px:

./images/0/0/1/640/1.jpg
./images/0/0/1/640/2.jpg

Вот и все.

Итак, есть ли недостатки этого метода? Если да, не могли бы вы указать на них?

Есть ли лучший метод? Если да, не могли бы вы описать это?

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

Спасибо!

Ответы на вопрос(1)

Ваш ответ на вопрос