Вчера мне наш сис. админ дал задание сделать фотоальбом. Вроде, не сложно, но...
Условие: Все фотографии должны храниться в мускуле, а точнее, их бинарный код.
Такое желание он подпрег 2 факторами:
Полная Версия: Хранение бинарных файлов в БД
| Цитата |
| Все толковые программисты хранят бинарные файлы в БД |
| Цитата |
| Я сомневаюсь, что ты способен реализовать подобное |
Ладно, 2 пункт то я могу оспорить, но насчет 1, я в недоумении. Действительно ли все толковые программисты хранят все бинарные файлы в БД, или он параноик, что не хочет просто мне открыть каталог на запись?
Я желаю услышать ответы конечно всех, но, конечно-же, мнение экспертов по этому поводу я хочу услышать больше и подробней. Спасибо заранее
Спустя 6 минут, 22 секунды (11.03.2011 - 09:03) Семён написал(а):
Он имхо даун очевидно и безусловно и как сисадмин нуль, если не может оценить преимущества того или иного способа решения задачи
А так-то можно действительно хранить файлы и в базе в поле производного типа от BLOB.
---
Для чего можно применять:
1) если MSSQL и документы вроде exel,word то база по-умолчанию будет строить по ним фул-индекс, и соответственно можно быстро осуществлять поиск по ним.
2) если Oracle база, то работа будет быстрее чем с обычной ФС.
А так-то можно действительно хранить файлы и в базе в поле производного типа от BLOB.
---
Для чего можно применять:
1) если MSSQL и документы вроде exel,word то база по-умолчанию будет строить по ним фул-индекс, и соответственно можно быстро осуществлять поиск по ним.
2) если Oracle база, то работа будет быстрее чем с обычной ФС.
Спустя 1 минута, 39 секунд (11.03.2011 - 09:04) alex12060 написал(а):
Не, как сис админ он хороший, толковый, правда, странный)
Окей, одно мнение есть)
Окей, одно мнение есть)
Спустя 31 минута, 2 секунды (11.03.2011 - 09:35) linker написал(а):
В топку его с таким предложением. Не хранят файлы в MySQL.
Спустя 19 минут, 25 секунд (11.03.2011 - 09:55) twin написал(а):
Про MySQL вообще то не упоминалось. Хотя сути это не меняет. Лично я не могу придумать ни одного более-менее выдерживающего критики оправдания такому заявлению. Народам - мир, ацедефилам - ацедефильное молоко, файлам - файловая система.
Спустя 18 минут, 21 секунда (11.03.2011 - 10:13) linker написал(а):
twin
| Цитата |
| Условие: Все фотографии должны храниться в мускуле |
Спустя 10 минут, 21 секунда (11.03.2011 - 10:24) twin написал(а):
Упс...
Спустя 45 минут, 20 секунд (11.03.2011 - 11:09) Zerstoren написал(а):
Ептб(куча-мата)
Алекс, я могу вам помочь. У меня есть примеры
(нуна поискать в одном сайте методику этого бреда)
Но я сам долго матов нагонял на прогера этого издевательства.
Сайт плужил страшно, в конце его забанил хостер и сказал - свободен.
Давайте в приват, скину вам примеры.
Алекс, я могу вам помочь. У меня есть примеры
(нуна поискать в одном сайте методику этого бреда)
Но я сам долго матов нагонял на прогера этого издевательства.
Сайт плужил страшно, в конце его забанил хостер и сказал - свободен.
Давайте в приват, скину вам примеры.
Спустя 51 минута, 4 секунды (11.03.2011 - 12:00) vagrand написал(а):
Спустя 3 часа, 40 минут, 44 секунды (11.03.2011 - 15:41) Trianon написал(а):
Это вопрос ответственности за надежность обслуживания и устойчивость к отказам.
Если сисадмину удобнее (репликация, снятие дампов и их резервное копирование) обеспечивать надежность и отказоустойчивость данных в БД (а не в каталогах ФС) он выберет именно такой путь.
Если удобнее (RAID, резервное копирование разделов ФС) обеспечивать надежность и отказоустойчивость данных, хранимых в файлах - выберет другой.
Первичное храниение изображений в БД само по себе еще не означает, что каждый запрос на доступ к картинкам будет удовлетворять именно сервер БД.
php-сторона может обеспечить кеширование данных из БД в каталог с последующим прямым статическим доступом http-сервера.
С другой стороны, хранение в БД дает общие преимущества СУБД (возможность поддержки версий картинок, протоколирование изменений и проч.)
Так что лепить ярлык на сисадмина при минимуме входных данных я бы не стал.
Если сисадмину удобнее (репликация, снятие дампов и их резервное копирование) обеспечивать надежность и отказоустойчивость данных в БД (а не в каталогах ФС) он выберет именно такой путь.
Если удобнее (RAID, резервное копирование разделов ФС) обеспечивать надежность и отказоустойчивость данных, хранимых в файлах - выберет другой.
Первичное храниение изображений в БД само по себе еще не означает, что каждый запрос на доступ к картинкам будет удовлетворять именно сервер БД.
php-сторона может обеспечить кеширование данных из БД в каталог с последующим прямым статическим доступом http-сервера.
С другой стороны, хранение в БД дает общие преимущества СУБД (возможность поддержки версий картинок, протоколирование изменений и проч.)
Так что лепить ярлык на сисадмина при минимуме входных данных я бы не стал.
Спустя 1 час, 4 минуты, 28 секунд (11.03.2011 - 16:45) vagrand написал(а):
Trianon
| Цитата |
| Если сисадмину удобнее (репликация, снятие дампов и их резервное копирование) обеспечивать надежность и отказоустойчивость данных в БД (а не в каталогах ФС) он выберет именно такой путь. Если удобнее (RAID, резервное копирование разделов ФС) обеспечивать надежность и отказоустойчивость данных, хранимых в файлах - выберет другой. |
Сайт должен работать как можно быстрее и как можно меньше нагружать сервак, а не так что бы админу было удобнее делать резервное копирование.
| Цитата |
| Первичное храниение изображений в БД само по себе еще не означает, что каждый запрос на доступ к картинкам будет удовлетворять именно сервер БД. php-сторона может обеспечить кеширование данных из БД в каталог с последующим прямым статическим доступом http-сервера. |
А если отдавать файлы с ФС то можно вообще php и apache не привлекать, а отдавать их шустрым ngix.
| Цитата |
| С другой стороны, хранение в БД дает общие преимущества СУБД (возможность поддержки версий картинок, протоколирование изменений и проч.) |
А что мешает реализовать все это храня в БД только путь к картинке и номер ее версии?
Спустя 21 минута, 59 секунд (11.03.2011 - 17:07) Trianon написал(а):
| Цитата (vagrand) |
| Сайт должен работать как можно быстрее и как можно меньше нагружать сервак, а не так что бы админу было удобнее делать резервное копирование. |
Вы очень зря пропустили первую фразу.
Еще раз. Это вопрос ответственности конкретного лица.
Именно ему (а не мне или Вам) виднее, как и кому должен работать сайт, а как не должен. Кроме того, я вижу явное передергивание в словах " что бы админу было удобнее делать резервное копирование ...".
Он (человек, отвечающий за функционирование) как нибудь сам решит, что ему должно быть удобнее в первую очередь, а что во вторую.
| Цитата (vagrand) | ||
А если отдавать файлы с ФС то можно вообще php и apache не привлекать, а отдавать их шустрым ngix. |
Если nginx в случае отсутствия файла сможет отправить запрос далее апачу с php - почему бы и нет?
| Цитата (vagrand) |
| А что мешает реализовать все это храня в БД только путь к картинке и номер ее версии? |
У каждой схемы есть свои достоинства, свои недостатки.
Недостатки, присущие такой схеме, не то что бы мешают, но заставляют задуматься о целесообразности выбора.
Более сложная поддержка консистентности файлового набора состоянию таблиц БД.
Очевидная необходимость периодической чистки "потерявшихся картинок" и т.п.
UPD. Попробу подытожить.
Я вовсе не утверждаю, что хранение картинок в виде BLOB - единственно правиильная методика.
Я лишь говорю, что внешние условия (равно как и проектная задумка) могут быть такими, когда такой вариант окажется вполне оправданным.
Могут и не быть.
Но при минимуме известной информации кричать "да он даун", "фтопку его" я бы не стал.
Еще раз. Я - не стал бы. При всем уважении к альтернативным точкам зрения.
Спустя 51 минута, 59 секунд (11.03.2011 - 17:59) vagrand написал(а):
| Цитата |
| Я лишь говорю, что внешние условия (равно как и проектная задумка) могут быть такими, когда такой вариант окажется вполне оправданным. |
Можете привести хотя бы один конкретный пример в котором хранение файлов можно реализовать только через БД?
Спустя 45 минут, 40 секунд (11.03.2011 - 18:45) Trianon написал(а):
Зачем?
Я где-то говорил, что что-то следует делать "только через"?
Я где-то говорил, что что-то следует делать "только через"?
Спустя 47 минут, 41 секунда (11.03.2011 - 19:32) alex12060 написал(а):
Не, тут намного все прозаичней)
Он просто параноик, и, просто хочет из меня смять что-то непонятное.
Он очень высокомерен, и верит, что любой сайт можно взломать через что угодно, и, если открыть запись на каталог группе www-data, то запорится весь сайт.
Скажу сразу, веб частью заведую я, и я даже не представляю как с блобами делать дампы оО
Он просто параноик, и, просто хочет из меня смять что-то непонятное.
Он очень высокомерен, и верит, что любой сайт можно взломать через что угодно, и, если открыть запись на каталог группе www-data, то запорится весь сайт.
Скажу сразу, веб частью заведую я, и я даже не представляю как с блобами делать дампы оО
Спустя 2 часа, 24 минуты, 18 секунд (11.03.2011 - 21:57) Trianon написал(а):
Стоило бы отделить мухи от котлет.
Тонкости ваших взаимоотношений, психологической совместимости, а также особенности харакрера Вашего коллеги можно (другое дело, нужно ли) пообсуждать отдельно от технических приемов.
Поскольку работа с BLOB-объектами в MySQL практически не отличается от корректной работы со строками, никакие ужасные конфу Вам для освоения учить не придется.
Можно ни разу не применять навык, но владеть им, и быть уверенным, что если припрет вдруг, то проблем не возникнет - более чем выгодно.
В конце концов, Вы могли бы написать оба варианта, сравнить их как по ресурсозатратам, так и по удобству администрежа, и найти аргументы для подкрепления собственной позиции.
Да, насчет дампов.
Они, вообще-то не отличаются, кроме как по объему.
Ну то есть можно у того же phpMyAdmin попросить сформировать не простой дамп, а с hex-записью BLOB и TEXT-полей. Но, как правило, это перестраховка, и обычный дамп вполне себе кошерен в плане переноса BLOB
Тонкости ваших взаимоотношений, психологической совместимости, а также особенности харакрера Вашего коллеги можно (другое дело, нужно ли) пообсуждать отдельно от технических приемов.
Поскольку работа с BLOB-объектами в MySQL практически не отличается от корректной работы со строками, никакие ужасные конфу Вам для освоения учить не придется.
Можно ни разу не применять навык, но владеть им, и быть уверенным, что если припрет вдруг, то проблем не возникнет - более чем выгодно.
В конце концов, Вы могли бы написать оба варианта, сравнить их как по ресурсозатратам, так и по удобству администрежа, и найти аргументы для подкрепления собственной позиции.
Да, насчет дампов.
Они, вообще-то не отличаются, кроме как по объему.
Ну то есть можно у того же phpMyAdmin попросить сформировать не простой дамп, а с hex-записью BLOB и TEXT-полей. Но, как правило, это перестраховка, и обычный дамп вполне себе кошерен в плане переноса BLOB
Спустя 1 день, 14 часов, 31 минута, 40 секунд (13.03.2011 - 12:28) alex12060 написал(а):
Окей, так и сделаю)
Спустя 21 час, 35 минут, 14 секунд (14.03.2011 - 10:04) linker написал(а):
Я вижу тема продолжается.
1. Самая важная задача - это работа сайта, его быстрая работа и никакой админ тут не вправе решать что и как. Его дело - администрирование, его проблема - бэкапы. Админ обязан подстраиваться под сайт, а не сайт под админа в ущерб производительности.
2. Есть задача - сайт. Есть его основная характеристика - производительность. И админ и разработчик обязаны подстроиться под этот критерий при проектировании.
3. Да кэш - это хорошо, но слишком много операций для получения конкретной иллюстрации. Как минимум проверка кэша и будет хорошо, если кэш не пустой.
4. Размер информации в базе в конце концов будет равен размеру кэша картинок. Т.е. имея в наличии терабайт реальных картинок, мы будем иметь 2 терабайта гумна.
5. Размер базы в MySQL и время доступа к данным имеет приделы.
Отсюда делаем вывод, что никакие удобства админа не стоят того, чтобы прогибаться под него и хранить картинки в базе.
1. Самая важная задача - это работа сайта, его быстрая работа и никакой админ тут не вправе решать что и как. Его дело - администрирование, его проблема - бэкапы. Админ обязан подстраиваться под сайт, а не сайт под админа в ущерб производительности.
2. Есть задача - сайт. Есть его основная характеристика - производительность. И админ и разработчик обязаны подстроиться под этот критерий при проектировании.
3. Да кэш - это хорошо, но слишком много операций для получения конкретной иллюстрации. Как минимум проверка кэша и будет хорошо, если кэш не пустой.
4. Размер информации в базе в конце концов будет равен размеру кэша картинок. Т.е. имея в наличии терабайт реальных картинок, мы будем иметь 2 терабайта гумна.
5. Размер базы в MySQL и время доступа к данным имеет приделы.
Отсюда делаем вывод, что никакие удобства админа не стоят того, чтобы прогибаться под него и хранить картинки в базе.
Спустя 4 часа, 10 минут, 37 секунд (14.03.2011 - 14:14) Trianon написал(а):
twin
а кто такой ацедефил?
linker,
В Вашем резюме из пяти пунктов, все пять имеют спорные моменты.
Я приведу только два.
(2) Мы не знаем ни распределения ролей в рассматриваемой истории, ни объемов ресурсов, которыми располагает владелец, ни кто отвечает за их использование.
Что этот конкретный Админ поменяет свою точку зрения, лишь ознакомившись с подобным мнением, мне представляется довольно сомнительным.
А что он поменяет разработчика (уж коль скоро в его компетенции давать ему задания, см. 1 пост) буде тот ему свою точку зрения навязывать - вполне возможным.
(4) Вовсе необязательно доводить ситуацию до такого.
Скорее всего, распределение вероятности доступа к картинкам далеко от равномерного. Как обычно, что-то запрашивается чаще, что-то реже.
Вполне можно построить такую схему вытеснения кеша, при которой гумна будет куда меньше терабайта (кстати, Вы зря написали двойку - если считать контент ценным в принципе)
Еще один довод привел Семён. Правда, как я теперь понимаю, не для этого случая.
И таки повторю еще раз. Я ничего не имею, как против хранения картинок в файлах, так и против того, что в большинстве случаев это естественный и оптимальный путь
а кто такой ацедефил?
linker,
В Вашем резюме из пяти пунктов, все пять имеют спорные моменты.
Я приведу только два.
(2) Мы не знаем ни распределения ролей в рассматриваемой истории, ни объемов ресурсов, которыми располагает владелец, ни кто отвечает за их использование.
Что этот конкретный Админ поменяет свою точку зрения, лишь ознакомившись с подобным мнением, мне представляется довольно сомнительным.
А что он поменяет разработчика (уж коль скоро в его компетенции давать ему задания, см. 1 пост) буде тот ему свою точку зрения навязывать - вполне возможным.
(4) Вовсе необязательно доводить ситуацию до такого.
Скорее всего, распределение вероятности доступа к картинкам далеко от равномерного. Как обычно, что-то запрашивается чаще, что-то реже.
Вполне можно построить такую схему вытеснения кеша, при которой гумна будет куда меньше терабайта (кстати, Вы зря написали двойку - если считать контент ценным в принципе)
Еще один довод привел Семён. Правда, как я теперь понимаю, не для этого случая.
И таки повторю еще раз. Я ничего не имею, как против хранения картинок в файлах, так и против того, что в большинстве случаев это естественный и оптимальный путь
Спустя 3 минуты, 32 секунды (14.03.2011 - 14:18) vagrand написал(а):
linker
Все это перечислялось ТС-у, но люди так устроены что пока сами шишек не набьют, то ничему не научатся.
Все это перечислялось ТС-у, но люди так устроены что пока сами шишек не набьют, то ничему не научатся.
Спустя 11 минут, 59 секунд (14.03.2011 - 14:30) Trianon написал(а):
процесс набивания шишек, между прочим, один из непременных атрибутов как профессионального, так и личностного роста.
На чужих ошибках умеют учиться только гении, коих немного.
На чужих ошибках умеют учиться только гении, коих немного.
Спустя 15 минут, 52 секунды (14.03.2011 - 14:46) linker написал(а):
В случае MySQL - это 99% оптимальный и естественный путь. Вообще сомнительна ситуация, когда админ лезет в дела программера, а уж тем более может давать ему задания, а также распоряжаться его выходным пособием.
Спустя 59 минут, 31 секунда (14.03.2011 - 15:45) twin написал(а):
Trianon
| Цитата |
| а кто такой ацедефил? |
Понятия не имею
Как то давно в КВН прозвучало.А по теме, оно конечно, случаи бывают разными. Наверняка бывает и такое, что ценность админа превышает все остальное вместе взятое.
Но приоритеты должны быть по меньшей мере обоснованы. Тот аргумент, который был приведен топикстартеру
| Цитата |
| Все толковые программисты хранят бинарные файлы в БД |
не выдерживает никакой критики. Собственно и все остальное как то в моем разумении не совсем вяжется с рациональным использованием ресурсов. Как технических, так и человеческих. Кладбище, как говорится, забито незаменимыми людьми.
Спустя 9 минут, 1 секунда (14.03.2011 - 15:54) Trianon написал(а):
| Цитата (twin) |
| Тот аргумент, который был приведен топикстартеру "Все толковые программисты ..." не выдерживает никакой критики. |
С этим нельзя не согласиться.
Собственно, настораживает уже само обобщение.
Спустя 17 часов, 49 минут, 3 секунды (15.03.2011 - 09:43) linker написал(а):
Видимо я не толковый программист 
Здесь расположена полная версия этой страницы.