Посоветуйте мне про архитектуру :-)

А не проще будет через memcached добавить кеширование блобов?

> Картинки планируется хранить в базе данных , а выдавать клиенту по HTTP... .

вот здесь самое тормозное место будет. храни их на файловой системе лучше, в разы быстрее будет работать. и вполне можно будет обойтись без сквида.

>А не проще будет через memcached добавить кеширование блобов?

сам веб-сервер это томкат с апачем... , а потому не хочу их мучать ещо и статикой .

Да и при использовании сквида у меня будет возможность хранить кеш на диске. если вдруг нужно будет :-)

> сам веб-сервер это томкат с апачем...

а, ну в таком случае можно поднять отдельно nginx только на выдачу картинок. дешево и сердито =)

>> Картинки планируется хранить в базе данных , а выдавать клиенту по HTTP... .

>вот здесь самое тормозное место будет. храни их на файловой системе лучше, в разы быстрее будет работать. и вполне можно будет обойтись без сквида.

Зачем от него отказываться ? если с его помощу можно получить и то и другое ?

Когда всё вырастет за размер одного сервера прийдётся мучатся с сетевыми файловыми системами ... , а так просто добавить ещо веб серверов и/или сквидов (их кстати можно в некий кластер закрутить , что бы общий кеш был)

>> сам веб-сервер это томкат с апачем...

>а, ну в таком случае можно поднять отдельно nginx только на выдачу картинок. дешево и сердито =)

Чем он лудше Сквида ?

> Зачем от него отказываться ? если с его помощу можно получить и то и другое ?

меньше общая нагрузка на сервер за счет грамотного планирования архитектуры приложения. отсюда выигрыш в быстродействии. я с e-commerce софтом довольно плотно работаю - там основной затык именно на операциях обращения к базе. отсюда метод оптимизации - вынос из базы всего что только можно.


> их кстати можно в некий кластер закрутить , что бы общий кеш был

здесь уже немного другой подход нужен, а не просто масштабирование. google -> load balancing

> Чем он лудше Сквида ?

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

>> их кстати можно в некий кластер закрутить , что бы общий кеш был

>здесь уже немного другой подход нужен, а не просто масштабирование. google -> load balancing

Это понятное дело :-) Для этого и задывается такая архитектура.

>> Зачем от него отказываться ? если с его помощу можно получить и то и другое ?

>меньше общая нагрузка на сервер за счет грамотного планирования архитектуры приложения. отсюда выигрыш в быстродействии. я с e-commerce софтом довольно плотно работаю - там основной затык именно на операциях обращения к базе. отсюда метод оптимизации - вынос из базы всего что только можно.

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

>> Чем он лудше Сквида ?

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

Сквид имеет похожую архитектуру как и nginx. А какие глюки будут при участии нескольких серверов для раздачи статики nginx ? как их предлагаеш синхронизировать ? (файлы устаревают, добавляются, но не изменяются)

> А какие глюки будут при участии нескольких серверов для раздачи статики nginx ?
> как их предлагаеш синхронизировать ? (файлы устаревают, добавляются, но не изменяются)

это не настолько уж требовательная к ресурсам операция чтобы под это дело несколько серверов мутить я думаю..

>это не настолько уж требовательная к ресурсам операция чтобы под это дело несколько серверов мутить я думаю..

Когда количество картинок перерастёт размер памяти сквида или машины с nginx , то тогда будет важно количество дисков на раздаче статики ...

один не большой файл можно и тем и тем раздавать ... , а когда кешировать в пямяти уже не получается , то думаеш или о количестве дисков или/и о количестве машин . мне кажется что машины дешевле :-)

Хотя может SSD диски будут вскоре дешевле/быстрее ?

скажи, зачем хранить картинки в базе ?

>скажи, зачем хранить картинки в базе ?

Из плюсов:
1. всё хранится в одном месте (не в одной табличке с товарами .... )
2. консистентность с данными , убил товар -> снеслис все картинки.
3. надёжно храняться , как и данные.
4. Удобно до нельзя достучатся до картинки, практически из всего что соеденяется с базой.
5. Удобное управление . Стереть/вставить/проверить на присутствие.


Из минусов:
1. База растёт не по детски (Базы по 100Гиг уже не сказки)
2. Бекап/востанновление дольше (Хотя при работе Стендбая не так страшно)

> 1. всё хранится в одном месте (не в одной табличке с товарами .... )

храни все на каком-нить отдельном сервере в директории скажем /imgs/<id>

> 2. консистентность с данными , убил товар -> снеслис все картинки.

+1 строчка unlink, что бы убить картинку, не вижу смысла в БД

> 3. надёжно храняться , как и данные.

выставь правильно права и преимущества БД исчезнут

> 4. Удобно до нельзя достучатся до картинки, практически из всего что соеденяется с базой.

отдельный сервер тут лучше подходит

> 5. Удобное управление . Стереть/вставить/проверить на присутствие.

ну не знаю, не вижу преимуществ.

ты только увеличишь нагрузку на БД, скорее всего все будет тормозить при дальнейшем развитии.