правильно xранить картинки не в базе, а в файловой системе
чем плохо хранить картинки в базе ?
начиная с некоторых объемов - медленно.
начиная с некоторых объемов - медленно.а потом - крайне медленно...
хмм
а это примерно с каких обьёмов ?
быдлопрога предназначена тупо для каталогизирования и систематизирования входящих факсов. штук по 10 в день максимум. Я думаю уж пару лет то не будет медленно ?
ps. Я начинающий велосипедостроитель
а это примерно с каких обьёмов ?
быдлопрога предназначена тупо для каталогизирования и систематизирования входящих факсов. штук по 10 в день максимум. Я думаю уж пару лет то не будет медленно ?
ps. Я начинающий велосипедостроитель
не храни картинки в базене учи плохому
. Про медленно это пиздешь. Рано или поздно файловое хранилище и идентификаторы картинок в базе разойдутся. К тому же, файловая система не предназначена для многопользовательского режима.файловая система не предназначена для многопользовательского режимаа) как это, не предназначена? те же блокировки на уровне файлов.
б) а зачем многопользовательский режим, когда файлы один раз заливаются, после чего только читаются?
в) файловый сервер быстрее сервера БД, т.к. имеет только необходимую функциональность.
в) файловый сервер быстрее сервера БД, т.к. имеет только необходимую функциональность.на очень большом количестве мелких картинок, файловые системы начнут загибаться.
В том-же ютубе, если не ошибаюсь, превьюшки в базе хранятся.
на очень большом количестве мелких картинок, файловые системы начнут загибаться.В том-же ютубе, если не ошибаюсь, превьюшки в базе хранятся.Если верить highscalability, то раньше они использовали для превьюшек ext3, а после покупки гуглом перешли на bigtable
не учи плохому . Про медленно это пиздешь. Рано или поздно файловое хранилище и идентификаторы картинок в базе разойдутся. К тому же, файловая система не предназначена для многопользовательского режима.гыгыгы. глянь на поддерживаемый мной ресурс shop.wildorchid.ru . картинок там до жопы, храню их именно в файловой системе. если бы на серваке - все бы здохло давно. да, глянь на посещаемость. по поводу многопользовательского режима нареканий не было.
а про расходимость идентификаторов - гыгы, главное чтоб руки прямые были
http://shop.wildorchid.ru/catalog/StyleCard.aspx?category=7&...
хочу посмотреть как черные будут выглядеть тыкаю на цвет и нихрена, че за нах?
хочу посмотреть как черные будут выглядеть тыкаю на цвет и нихрена, че за нах?
а про расходимость идентификаторов - гыгы, главное чтоб руки прямые былисделать транзакционную фс и корректно привязать ее к транзакциям в приложении - непростая задача, и сильно выходит за рамки быстрого написания небольшого сайта.
разумеется, если картинки заливаются\меняются\удаляются не часто, сложной обработки картинок не ведется, то можно без особых усилий сделать все без транзакций и не париться.
про ощутимые тормоза бд на большом количестве картинок - пока вы не проведете реальные сравнительные бенчмарки, это бабушка надвое сказала. индекс по ключу картинки и корректная работа с блобом - залог успеха.
хочу посмотреть как черные будут выглядеть тыкаю на цвет и нихрена, че за нах?ето не ко мне, а к фотографам. не все засняли зачем-то...
а потом - крайне медленно...и за счет чего будет крайне медленно?
за счет доп. передачи через shared memory?
гыгыгы. глянь на поддерживаемый мной ресурс shop.wildorchid.ruты показываешь read-only приложение (корзина не в счет упомянутые мной проблемы в read-only режиме естественно не проявляются. В первоначальном посте как раз был код на апдейт.
по поводу многопользовательского режима нареканий не было
поддерживаемый мной ресурс
а про расходимость идентификаторов - гыгы, главное чтоб руки прямые были
часто ситуация обратная — приложение поддерживает не разработчиком
плюс тебе за оба замечания. просто мы нашли такое решение и оно нас не подвело
А какой суммарный размер картинок и пиковая нагрузка (в количестве отдаваемых картинок)?
А картинки кстати маза хранить в мемкешах (ну естественно сдублированием в базе или на диске).
А картинки кстати маза хранить в мемкешах (ну естественно сдублированием в базе или на диске).
тоже поставил плюс , за правильную оценку ситуации
Кстати,
, за правильную оценку ситуацииКстати,
В SQL Server 2008 Microsoft делает ответный ход, объявляя о поддержке типа данных FILESTREAM [15]. В решении Microsoft пользователи получают возможность доступа средствами SQL Server к файлам, хранящимся в файловой системе NTFS (при этом сохраняется ограниченная возможность доступа к тем же файлам на основе интерфейса Win32). Доступ к объектам типа FILESTREAM из SQL Server производится в транзакционном режиме с поддержкой журнализации и восстановления.
http://citforum.ru/database/data_management_overview/2.shtml
как думаешь - зачем они это сделали? 
как думаешь - зачем они это сделали?для хранения больших файлов (например, видео) в базе.
картинки такими большими файлами не являются.
ответь честно - умножение в первом классе учил?
умножение - это второй класс
картинки такими большими файлами не являются.полноцветный, 300dpi, A4 скан в формате BMP - это большой файл?
полноцветный, 300dpi, A4 скан в формате BMP - это большой файл?тут речь скорее про thumbnails, а не про тупо-фотки или сканы.
быдлопрога предназначена тупо для каталогизирования и систематизирования входящих факсов. штук по 10 в день максимум. Я думаю уж пару лет то не будет медленно ?в среднем 50кб/факс, если хранить оригинал (2х цветный TIFF). Вот и считай - 10 факсов в день, 3.5 мб в неделю, 15мб в месяц. это копеечные объемы особенно с учетом того, что факсы как правило очень быстро устаревают или теряют актуальность (например, счета).
а) как это, не предназначена? те же блокировки на уровне файлов.
Только блокировками на запись высокий уровень изоляции транзакций не обеспечить
на очень большом количестве мелких картинок, файловые системы начнут загибаться.Совершенно безосновательное заявление.
в общем-то, когда картинка занимает немногим больше, чем путь к ней, имеет смысл хранить саму картинку, а не путь, по которому потом искать картинку.
Как мне нравятся такие обтекаемые характеристики типа "немногим", "чуть-чуть" и прочее.
Ребята, цифры рулят. 160 байт - это в лучшем случае какая-то иконка в глубинах веб-интерфейса, которую никто в здравом уме хранить в базе не будет по определению.
Нормальные изображения по размеру всегда много длиннее пути, где могла бы лежать эта картинка.
Ребята, цифры рулят. 160 байт - это в лучшем случае какая-то иконка в глубинах веб-интерфейса, которую никто в здравом уме хранить в базе не будет по определению.
Нормальные изображения по размеру всегда много длиннее пути, где могла бы лежать эта картинка.
если у меня 10 серверов, то на каждом картинки должны дублироваться?
(если говорить про шардинг, то он опять же заведомо тормознее,
чем отдача картинок через nginx, который на своем уровне может определить к
какому серверу картинок посылать запрос)
зачем нагружать транзакции в базе, если они по своей сути являются самой тормозной вещью в СУБД.
(если говорить про шардинг, то он опять же заведомо тормознее,
чем отдача картинок через nginx, который на своем уровне может определить к
какому серверу картинок посылать запрос)
зачем нагружать транзакции в базе, если они по своей сути являются самой тормозной вещью в СУБД.
например, flickr, по данным за зиму
470 млн изображений, 5 петабайт дискового пространства (всего, занятое включено)
вопрос в зал:
Как вы думаете, что будет с БД, если в нее это все положить?
особенно обратите внимание на то, что СУБД любят держать свои индексы в оперативной памяти.
470 млн изображений, 5 петабайт дискового пространства (всего, занятое включено)
вопрос в зал:
Как вы думаете, что будет с БД, если в нее это все положить?
особенно обратите внимание на то, что СУБД любят держать свои индексы в оперативной памяти.
http://www.insight-it.ru/net/scalability/arkhitektura-flickr...
> Все, за исключением фотографий, хранится в базе данных
> Все, за исключением фотографий, хранится в базе данных
ну да, я к тому и написал про фликр )
хотя 450 млн записей - не так много и индекс в памяти легко помещается, но все равно остальных проблем не отменяет.
А жж на пехепе был написан.
Из этого следует, что все проекты с большой нагрузкой должны кодиться на пхп?
Из этого следует, что все проекты с большой нагрузкой должны кодиться на пхп?
А жж на пехепе был написанты уверен в этом?
Разумеется. Именно для жж был написан memcached между прочим.
Я, к сожалению, на практике столкнулся с тем, что хранение картинок (почтовых вложений, содержащих как правило картинки) - большой геморой для обслуживания. Не говорю, что это невозможно обслуживать, но процесс существенно более трудоемкий, нежели картинки на fs + метки об этом в БД.
Разумеется. Именно для жж был написан memcached между прочим.жж был написан на перле.
Brad Firzpatrick - создатель Livejournal и один из главных фанатов Perl-а в Google. http://brad.livejournal.com/2388824.html
http://www.usenix.org/events/usenix07/tech/slides/fitzpatric... - слайды про архитектуру LiveJournal.
http://video.google.com/videoplay?docid=-8953828243232338732 - почти те же слайды из уст Брэда Фитцпатрика.
прошу прощения
переформулирую свой исходный пост: все нагруженные приложения надо писать на перле?
переформулирую свой исходный пост: все нагруженные приложения надо писать на перле?
нет, не стоит.
вывод один - стоит думать, прежде чем выдавать категоричные высказывания.
вывод один - стоит думать, прежде чем выдавать категоричные высказывания.
Когда картинка занимает 2 КБ, а путь к ней 0.5 КБ, имо не стоит вытаскивать картинку из БД - получится только лишний доступ к ФС. (не говоря уже о занятии на 25% большего места )
)более того, БД если картинка лежит где надо загрузит её разом с нужными данными, возможно за одну дискововую операцию.
в случае ФС может случится всякая фигня — пути try-кэша неисповедимы =)
в случае ФС может случится всякая фигня — пути try-кэша неисповедимы =)
Твоя картинка в 2Кб будет занимать в ежедневном бекапе БД эти самые 2кб, в то время как в дифференциальном бекапе ФС - ни байта.
плохой аргумент: для БД возможны ровно те же стратегии резервного копирования, что и для ФС, включая дифференциальные и инкрементальные бэкапы.
Уточни, для каких БД возможны диф бекапы? Oracle?
Когда картинка занимает 2 КБ, а путь к ней 0.5 КБ, имо не стоит вытаскивать картинку из БД - получится только лишний доступ к ФС. (не говоря уже о занятии на 25% большего местаА в БД все блобы вплотную упакованы что ли?
ну уж бэкапить файлы журнала транзакций, а при восстановлении "накатывать" их на полный бэкап можно практически везде, и это эквивалентно поддержке инкрементального бэкапа:
- в PostgreSQL (write ahead log или WAL
- в MySQL (Binary Log, MySQL backups
- в Berkeley DB,
- очевидно, это можно делать в Oracle, DB2 и SQL Server
- в PostgreSQL (write ahead log или WAL
- в MySQL (Binary Log, MySQL backups
- в Berkeley DB,
- очевидно, это можно делать в Oracle, DB2 и SQL Server
ну уж бэкапить файлы журнала транзакцийну это жесть, пригодно только если записи почти совсем не меняются
гыгы. бинлоги будешь за месяц накатывать?
ну это жесть, пригодно только если записи почти совсем не меняютсяа какие варианты-то? рано или поздно логи за день будут занимать сильно меньше чем полный бэкап
из моего опыта:
1) нормальный (= опытный и ответственный ) Oracle DBA будет бэкапить:
- и файлы данных (полные, и, если считает возможным, дифференциальные/инкрементальные резервные копии
- и файлы журнала транзакций (archived redo logs)
2) разработчики несколько известных "коробочных" продуктов, использующих встроенную Berkeley DB, инкрементальный бэкап предлагают делать именно как бэкап логов транзакций.
гыгы. бинлоги будешь за месяц накатывать?за неделю - да
а чего ты будешь делать если полный бэкап занимает по времени больше чем допустимое время остановки системы ("daily maintenance window")? а нормальное "окно", достаточное для полного бэкапа, есть только в выходной, скажем?
а какие варианты-то?инкрементальный бекап по образцу того, как это делается для ФС
а чего ты будешь делать если полный бэкап занимает по времени больше чем допустимое время остановки системыа чё, бекап без остановки всякие ораклы не умеют?
>а чего ты будешь делать если полный бэкап занимает по времени больше чем допустимое время остановки системы
ну как бы стандартное решение - поставить репликацию и бэкапить на слейве
ну как бы стандартное решение - поставить репликацию и бэкапить на слейве
а чё, бекап без остановки всякие ораклы не умеют?MySQL я так понял не умеет
а в PostgreSQL, равно как и в Oracle, online-backup состоит из копии файлов данных + копии логов транзакций (после восстановления файлов данных они накатываются, чтобы восстановить consistency)
а в PostgreSQL, равно как и в Oracle, online-backup состоит из копии файлов данных + копии логов транзакцийну не за неделю же логи!
я понимаю, если моментальный снапшот
Я может торможу, но как быть с лагом? Под нагрузкой слейв же будет отставать от мастера, нет? И что мы тогда набекапим?
ну как бы стандартное решение - поставить репликацию и бэкапить на слейвену и чего дешевле:
- место на магнитных лентах под логи,
или же
- отдельный сервер под слейв + дисковое пространство под слейв, равное размеру основной базы?
ответ, как всегда, - "зависит от".
если база - MySQL, лежит на внутренних дисках сервера, а сервер дешевый - наверное держать слейв будет дешевле
если база лежит на внешнем дисковом массиве, и серверы не дешёвые - дешевле бэкапить логи
если машинки одинаковомощные и обе не нагружать чтением, то слейв будет отставать редко, когда например долгая большая трнзакция будет закоммичена.
ну и когда бэкап делать, то слейв тоже будет стоять.
если максимальная задержка не будет более 2 часов (скажем то проблемы не вижу
ну и когда бэкап делать, то слейв тоже будет стоять.
если максимальная задержка не будет более 2 часов (скажем то проблемы не вижу
ну да, я про MySQL :-/
ну не за неделю же логи!логи за время бэкапа, с запасом (т.е. обычно за несколько часов)
в то время как в дифференциальном бекапе ФС - ни байта.как будет обеспечиваться транзакционность backup-а?
остановкой сервера?
MySQL я так понял не умеетНеправильно понял. Если БД на innodb, то блокировка на запись нужна только до момента запуска mysqldump.
А, я перепутал. С бекапом форума нет проблем.
mysqldump просто открывает транзакцию и запускает селекты, как я понимаю, работа не останавливается
А способ со снапшотом тоже хорош по-своему, но нужно копировать все файлы данных, а в случае innodb там много лишнего, ведь место резервируется заранее.
mysqldump просто открывает транзакцию и запускает селекты, как я понимаю, работа не останавливается
А способ со снапшотом тоже хорош по-своему, но нужно копировать все файлы данных, а в случае innodb там много лишнего, ведь место резервируется заранее.
>в случае innodb там много лишнего, ведь место резервируется заранее.
да, в 3 раза по объёму overhead,
а tablespace можно и не резервировать сразу всё
зато быстро!
да, в 3 раза по объёму overhead,
а tablespace можно и не резервировать сразу всё
зато быстро!
> а tablespace можно и не резервировать сразу всё
вакуум всё равно остаётся
вакуум всё равно остаётся
Если БД на innodb, то блокировка на запись нужна только до момента запуска mysqldump.так мы про резервное копирование и восстановление говорим, или про экспорт-импорт?
использовать экспорт-импорт вместо бэкапа-восстановления приемлемо только на небольших базах: импорт базы гигов в 50 из дампа созданного mysqldump будет длиться много часов, а то и суток, или я не прав?
импорт базы гигов в 50 из дампа созданного mysqldump будет длиться много часов, а то и суток, или я не прав?с форматом -T должно быть быстрее, но я не пробовал
а надо иметь две схемы бэкапа: для восстановления удалённых данных и для восстановления полностью базы после аварии (ну тут и слейв спасёт)
Оставить комментарий
Alexander08
мямямя... не храни картинки в базе... мямямя