PHP-имя strpos имя файла или запрос MySQL

Question

Я храню некоторые файлы высокого разрешения на обслуживании (100K + если это имеет значение), и я организую их в разных галереях. Когда кто-то получает доступ к галерее, я показываю только миниатюры и низкую версию изображений, которые в некоторых случаях обозначаются водяным знаком, а в другом случае - нет. Теперь из-за того, что я говорю о огромном количестве фотографий, версия с низким разрешением, отображаемая на странице галереи, удаляется с сервера через X дней. Если кто-то действительно имеет доступ к галерее, а версия lowres этого файла не существует на сервере, она генерируется «на лету», однако, когда я создаю lowres, мне может понадобиться сделать это с водяным знаком или нет.

В настоящее время сценарий, который отображает изображения не делает любой SQL называть все это основано на файловой системе (если файл существует, и т.д.) и решение водяного знака изображения или не основано на:

if (strpos($file_name,"FREE")===false){ //add watermark }else{ //just resize} 

Моя логика говорит, что это более результативно, чем выполнение SQL-запроса с именем файла или файлом и проверка того, должен ли он быть не водяным знаком. Однако я нахожу это немного неудобством, чтобы иметь имена файлов, содержащие слово FREE.

Какая разница в производительности, которую я могу ожидать, если я использую SQL-запрос вместо strpos?

EDIT/UPDATE

Резюмируя итоги ответы и комментарии:

• Система разрабатывается, чтобы работать в течение нескольких лет, со всеми галереями, которые добавляют более чтобы быть еще доступным. Это означает, что требования к хранению просто ОГРОМНЫ, а изображение с высоким разрешением для старых альбомов будет перемещено за пределы места на медленном и дешевом выделенном хранилище, поэтому предложение сохранить дополнительные накладные расходы со всех миниатюр - это серьезный вариант. В прошлом году мне нужно было хранить более 3 ТБ изображений (это только высочайший размер).

• Я нахожусь на Lighttpd, и я намерен использовать rewrite-if-not-file, чтобы получить наилучшую производительность для существующих эскизов.

• Я знаю о штрафе за запись ввода-вывода, и я намерен сохранить его до минимума, написание только при необходимости, предпочтительно чтение. Однако комментарий от @ N.B. действительно заставил меня задуматься о сохранении изображений lowres на SSD, поэтому даже когда мне нужно создавать и записывать их на диск, производительность намного выше, чем у обычного жесткого диска.

• Будет действительно сложно сделать какой-либо тест (@Steve E.) Я отстаю от графика, и система должна выйти вживую к концу этого месяца. (Сегодня я получил бомбу, что они затягивают штепсель старой системы). Да, гибкость - главная причина, по которой я соблазн пойти с SQL, но я ожидаю, что база данных SQL будет значительно расти, помимо информации о файле, есть масса другой информации, которую мне нужно также хранить, пометки, покупки , загрузки и т. д., поэтому я также пытаюсь убедиться, что я не слишком сильно надаю на SQL, когда я действительно могу использовать некоторые из них с хорошей структурой и доступом к файловой системе.

Answer 1

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

В хорошо сконфигурированной системе переменные, которые требуются часто, будут находиться в кеше ОЗУ, а не на диске. Это касается кэширования файловой системы, а также индексов кэширования MySQL. Влияние кеширования и других механизмов может дать результаты, отличающиеся от ожидаемых.

Во многих сценариях любое решение будет работать и быть адекватным, поскольку время, затраченное на любой запрос, должно быть минимальным в хорошо спроектированной системе, а дополнительная производительность одного подхода может не стоить того неудобства, которое вы обнаружите при использовании «БЕСПЛАТНО», в имени файла. Было бы не слишком сложно разбираться в обоих методах и измерять производительность.

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

Если производительность действительно является существенной проблемой, обратитесь к веб-серверу, чтобы проверить файл на диске (или в кеше как memcache) и вернуть его, если он существует, прежде чем передать запрос на PHP вообще. Оба Nginx и Apache могут это сделать, это общий подход ускорения для сайтов с высоким трафиком.

Answer 2

Вы уже сделали трудную часть. SQL-запрос в вашем случае только замедлит вас ...

вот как вы делаете это

user--->php-->filesystem-->php--->user 

если MySQL приходит в это, как она идет

user--->php--->mysql--->filesystem--->mysql-->php--->user 

так что вы уже спасти себя некоторое время, пока не используете MySQL ...

Answer 3

Если кто-то действительно имеет доступ к галерее, а версия нижнего уровня файла не существует на сервере, она генерируется на лету

Если версии с высоким разрешением не хранятся в базе данных, а в качестве файлов сервера, это означает, что миниатюры с низким разрешением занимают очень мало места пропорционально высоким изображениям с высоким разрешением. Например, допустим, что изображения с низким разрешением составляют 10% от размера высоких значений. Сохранение всех изображений с низким разрешением, доступных на вашем сервере, добавляет 10% к вашим потребностям в хранении, и если у вас нет 10% запасной емкости, вам необходимо пойти за покупками для большего объема хранения, а не пытаться использовать методы обхода.

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