Мэкс: IBM-овский Lotus Domino. Правда там объем индексов может существенно превышать объем самой базы, по которой производится поиск. Да и индексы на таких объемах не быстро перестраиваются.
wolf: Кого предупредить? Не забывайте, что оптимизаторы остаются для Яндекса (равно как и для любого другого поисковика) людьми, паразитирующими на его выдаче и зачастую засоряющими индекс и создающими постоянные проблемы для разработчиков алгоритма. Какой бы респектабельный вид они не имели и какие бы дорогие костюмы не напялили. Много чести будет.
Ну точно также можно сказать, что всякие бифидобактерии, живущие в человеке, на нем паразитируют. Однако без них, человек скопытится от первой же заразы, если не раньше, от несварения. Так что это не паразитизм, а симбиоз.
Оптимизаторы, как полезные бактерии, помогают ПС переваривать разные сайты и помогают в защите их от вредных бактарий;)
Зингельшухер: Их много да в количественном исчислении, но в процентном соотношении мусора намного больше по этому найти среди этой кучи дерьма конфетку очень сложно...
Это во всем так.
Но есть критерии которые позволяют выловить хорошие библиотеки;-)
dkameleon: Ну что же, пойдём дальше. Перечислите пожалуйста каталоги товаров / интернет-магазины, построенные по кластерной архитектуре с хранением картинок в базе.
А вы мне покажите интернет магазин с посещаемостью больше 30ки в сутки.
Ugnich Anton: Обычно в очень крупных задачах для раздачи статики (картинок) используются отдельные выделенные сервера. Синхронизироваться они замечательно могут и без СУБД.
Согласен, что используются отдельные image сервера. Однако в случае хранения в базе задаче тривиально расширяется с одного сервера без выделенного сервера картинок, на кластерную архитектуру с выделенными серверами картинок.
Как Вы будете расширять в случае хранения в папке я не представляю. Точнее предполагаю что для распределенного хранилища картинок Вам придется реализовать собственное подмножество БД.
ЗЫ. Вот и я удивляюсь человеческой упертости: объясните мне какие недостатки в хранении картинке в базе (при наличии кэша),помимо увеличения размера самой базы, что может привести к удорожанию хостинга, но не выделенного сервака.
Суть системы в том что она создается именно как правильная, которая не нарушает лицензии Я, и созданна для людей.
И в чем же предназначение для людей? И если она для людей зачем тиц и пр в интерфейсе?
IBM-овский Lotus Domino. Правда там объем индексов может существенно превышать объем самой базы, по которой производится поиск. Да и индексы на таких объемах не быстро перестраиваются.
Тогда уж озвучьте цену на домино ;-)
Кого предупредить? Не забывайте, что оптимизаторы остаются для Яндекса (равно как и для любого другого поисковика) людьми, паразитирующими на его выдаче и зачастую засоряющими индекс и создающими постоянные проблемы для разработчиков алгоритма. Какой бы респектабельный вид они не имели и какие бы дорогие костюмы не напялили. Много чести будет.
Ну точно также можно сказать, что всякие бифидобактерии, живущие в человеке, на нем паразитируют. Однако без них, человек скопытится от первой же заразы, если не раньше, от несварения. Так что это не паразитизм, а симбиоз.
Оптимизаторы, как полезные бактерии, помогают ПС переваривать разные сайты и помогают в защите их от вредных бактарий;)
Их много да в количественном исчислении, но в процентном соотношении мусора намного больше по этому найти среди этой кучи дерьма конфетку очень сложно...
Это во всем так.
Но есть критерии которые позволяют выловить хорошие библиотеки;-)
это из области вредных советов (там столько ужаса что хорошие вещи там хоть и есть но их трудно найти)
Странно, например в жабе, очень много хороших проектов выросло из sourceforge
dkameleon, а если народ яндекс маркет делает?:-))
Ну что же, пойдём дальше. Перечислите пожалуйста каталоги товаров / интернет-магазины, построенные по кластерной архитектуре с хранением картинок в базе.
А вы мне покажите интернет магазин с посещаемостью больше 30ки в сутки.
Обычно в очень крупных задачах для раздачи статики (картинок) используются отдельные выделенные сервера. Синхронизироваться они замечательно могут и без СУБД.
Согласен, что используются отдельные image сервера. Однако в случае хранения в базе задаче тривиально расширяется с одного сервера без выделенного сервера картинок, на кластерную архитектуру с выделенными серверами картинок.
Как Вы будете расширять в случае хранения в папке я не представляю. Точнее предполагаю что для распределенного хранилища картинок Вам придется реализовать собственное подмножество БД.
ЗЫ. Вот и я удивляюсь человеческой упертости: объясните мне какие недостатки в хранении картинке в базе (при наличии кэша),помимо увеличения размера самой базы, что может привести к удорожанию хостинга, но не выделенного сервака.
ЗЫЫ. Преимущества мне очевидны.
Мишган,
ПРочтите вопрос ТС. Как думаете, речь о кластере идёт? ;)
Так в том то и дело, что при хранении в базе не нужно будет ничего переделывать когда понадобица кластер. А вот в случае папки нас ждет беда....
Ни одного аргумента в пользу хранения в БД так и не увидел
Кто не захотел - тот не увидел.
Сторонники хранения в папке ответьте на вопрос: будет ли ваша система работать в кластере (например два вебсервера и сервер бд)
А ничего, что база таких размеров будет в памяти висеть?
Только в папке.
А с чего бы она будет в памяти сидеть? да и в какой памяти?:-))
ЗЫ. Объясните мне как при хранении в папке (одной?) контролировать целостность данных? Как делать репликацию картинок в кластере?
ЗЫЫ. Могу еще проблем найти. А вот проблем с хранением в базе и кэшированием не вижу.