Форум PHP

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

И недавно с одним человеком подняли вопрос ресурсоемкости того и другого варианта. Воспользовавшись Апачевской утилитой "ab" этот чел сообщил, что вроде как вариант с централизованным хранением данных в мускуле зажирает ресурсов в 3 РАЗА БОЛЬШЕ.

Т.е. скажем берем код вида

<img src="images/<?=$row['id']?>.jpg"> <!-- где $row['id'] - результат фетча из базы -->

и сравниваем его с кодом

<img src="view.php?id=15"> <!-- где view.php просто залазит в базу и выдает на поток текст двоичного файла из BLOB-поля. -->

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

Прошу знающих людей помочь мне разобраться в этом вопросе. Подход хранения в BLOB'ах мне лично очень близок, но если мой оппонент в этом споре прав, то мне придется вернуться к плугу... (((

Первый вариант - запрос обыкновенного статического документа, на это требуется минимум процессорного времени и оперативной памяти, во втором уже требуется соединение с СУБД, запрос этой картинки, вывод. Причём, содержимое документа всё сразу забивается в оперативную память, а не по кусочкам.

Так что первый вариант предпочтительней.

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

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

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

Щас попытаюсь объяснить, к чему я это..

Вариант №1:

1) клиент получает DOM-структуру документа и анализирует ссылку 2) по ссылке он подает запрос к файлу-фотке на сервере 3) апаче прочитывает его содержимое (в оп. память) и посылает клиенту

я правильно процесс описал? если верно, то содержимое двоичного файла так или иначе оказывается в RAM сервера.

Теперь Вариант №2:

1) клиент получает DOM-структуру документа и анализирует ссылку 2) по ссылке он подает запрос к скрипту-просмотрщику на сервере 3) тот открывает соединение с БД или использует уже открытое (кстати, не соображу возможен ли вариант с pconnect'ом) 4) скрипт достает текст фотки из базы и записывает его в RAM 5) апаче посылает его клиенту.

Если я все верно описал, то кроме ресурсозатрат на обращение к БД больше различий в потреблении оп. памяти быть не должно.... А если в чем-то скривил душой, то сильно не бейте =)

> HTTP разве сервер не прочитывает сперва текст этого двоичного файла в поток, а значит и в RAM

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

Грубо говоря, Вы видите разницу между

<?php $fh = fopen('big_file.txt', 'r'); while( ( $b = fread($fh, 4098) ) !== false ) # Считывание 4 Kb текста {     echo $b; # Отправка } fclose($fh); ?>

и

<?php $buffer = file_get_contents('big_file.txt'); # Запихивание всего содержимого в RAM echo $buffer; ?>

? Можно считать, что буферизация вывода отключена.

Да, вполне наглядно....
Тогда вопрос, быть может возможно реализовать искусственную имитацию буферизации при считывании данных из LONGBLOB? Или на уровне мускула никак невозможно вмешаться в процесс, пока он заполняет переменную/массив данными?

П.С.: хочу еще вот что спросить: может ли как-то измениться ситуация, учитывая что на уровне РНР будет применяться GDlib? Дело в том что я пишу универсальный класс по закачке-считыванию изображений для CMS-ки. На клиентскую часть например к списку новостей будет прилагаться список соответствующих тамбнейлов. В прошлой версии своей CMS-ки я использовал просто 2 варианта файлов, т.е. через админку закачиваем здоровую картинку, скрипт ее ресайзит и создает уменьшенную копию, помещая соответственно ту и другую картинки в каталоги /thumbs/ и /photos/. Сейчас я хочу избавиться от этого геммороя, поместив оригинал картинки в BLOB, а на выходе - на лету через GD преобразовывать ее в тамбик нужных размеров, заданных в методе класса. В обслуживании такой метод будет более эргономичным. И вот тут внимание вопрос: скажется ли использование GD преобразований на том, используем мы файловую систему или базу данных? Или же оба процесса просто напросто удлинятся на величину GD-преобразований?
(пардон за такие адские умоизречения =)

>закачиваем здоровую картинку, скрипт ее ресайзит и создает уменьшенную копию, помещая соответственно ту и другую картинки в каталоги /thumbs/ и /photos/. Сейчас я хочу избавиться от этого геммороя

Я бы назвал это не геммороем, а необходимой оптимизацией. Ресайзинг "здоровой катринки" "на лету" будет отнимать немало CPU и ОЗУ. Особенно, если пользователь просматривает что то вроде галлереи с уменьшенными копиями, браузер закидает сервер тормозящими запросами. Если онлайн-пользователей будет много, тормоза будут заметны + потенциально это может стать лазейкой для атаки DoS.

Да.. это последняя капля ))) оставляю идею с BLOB-ами, отрываю буквально-таки от сердца )))
Тогда если не сложно, подскажите такую вещь: можно ли с помощью .хтаксесса искусственно изменить права на каталоги для закачиваемых файлов? Скажем в корне сайта есть каталог /img/, внутри него еще 2 - /thumbs/ и /photos/. Для верной работы нужно влезть на ФТП и всем им присвоить соотв. права на доступ, чтобы скрипт в админке потом смог поместить туда изображения. А если структура разветвится и например уйдет вглубь, то это превратится в настоящее наказание. Можно ли поместить в /img/ файл .htaccess с указанием прав доступа а-ля chmod для всех дочерних директорий, или же апаче тут вообще никак не сможет посодействовать?