Re: [pgsql-ru-general] Re: [pgsql-ru-general] философия: хранение картинок

В рассылке по Перлу, а может и тут что-то такое было года 2 назад. Даже на хайлоад поехало. Смысл сего был в том, что есть плагин к nginx'у, который позволяет через него в Pg ходить напрямую, если ссылку правильную дать. Там даже хранимки вроде-бы можно было вызывать таким способом... Вот вам и то, что вы хотите без строчки кода... ну в 1м приближении.

Понедельник, 16 марта 2015, 16:26 +03:00 от Миша Тюрин <tmihail(at)bk(dot)ru>:
>
>привет. pgq. простой консумер. а из конечного обработчика потом и веб можно подопнуть.
>
>http://pyvideo.org/speaker/489/magnus-hagander
>http://www.hagander.net/talks/cache_invalidation_2014.pdf
>
>можно на pgq обрабатывать (можно много очередей сделать и между ними делить -- это хорошо согласованно, но менее масштабируется), а можно
>pgq как транспорт использовать и в очередь обработки перекладывать, например в redis/rabbit.
>
>как -то так:
>
>1 пост картинки уходит
>2 синхронно приходит айдишка и уже маленькая фоточка готова (привьюшка синхронно жмется)
>3 пользователь сабмитит что всё ОК
>
>// не забываем, что может пригодится   http://wiki.nginx.org/HttpUploadModule  чтобы лишний раз не гонять внутри дц картинки.
>
>на шаге 2 (в той же транзакции) при покладке в базу еще и событие на допережатия в pgq кидаем.
>если всё норм, то к шагу 3 уже всё будет готово!
>
>а если юзер потом всё отменил (после привьюшек) и до 3 не дошел, то на шаге 2 (в той же транзакции) надо еще трекать выданные айди и через "час" проверять, есть ли в итоговый таблице ссылки на эти картинки -- если нет -- можно физически удалять файлы
>
>
>-- Миша
>
>Пятница, 13 марта 2015, 6:28 +03:00 от "Dmitry E. Oboukhov" <unera(at)debian(dot)org>:
>>Раз уж тут пошло обсуждение "что правильно а что нет"
>>
>>задам такой вопрос:
>>
>>есть веб-проект, где пользователи загружают некоторые картинки себе в
>>профиль.
>>набор картинок условно говоря у всех пользователей одинаков.
>>
>>нужно реализовать хранилище вида
>>
>>- кладем картинку
>>- какой-то рабочий у хранилища создает для картинки preview, icon,
>>fulllsize изображения
>>- после этого процесс покладки картинки считаем завершенным
>>
>>далее внешние запросы будут обращаться к картинкам строго по их ID.
>>
>>какой дорогой пошли сперва:
>>
>>Pg и три (или одна со столбиками) таблички icon, preview, full.
>>
>>вебсервер который по ID делает запрос в одну из табличек за телом
>>картинки.
>>
>>уперлись в то что вебсервер надо писать в асинхронном стиле (что не
>>проблема), причем ему нужна асинхронная работа с БД, что уже является
>>проблемой (асинхронность полностью не поддерживается драйверами и
>>Pg: то есть нельзя заслать множество запросов в Pg в асинхронном стиле
>>и ждать ответы на них, чтобы порядок был неважен итп)
>>
>>а если сервер в синхронном стиле написан, то нагрузка его прибивает
>>очень здорово (повторюсь: выборка изображений строго по ID его
>>задача).
>>
>>в итоге от Pg мы отказались, а стали хранить изображения в файликах на
>>диске.
>>Тут сильно страдает консистентность, но в угоду стоимости разработки
>>на это пошли.
>>
>>вопрос: а как правильно организовать хранение картинок, чтобы
>>
>>1. дешево разрабатывать и использовать
>>2. получить плюшки от индексов (например с помощью Pg можно отвечать
>>на вопросы "дай картинки похожие на эту")
>>
>>--
>>
>>. ''`. Dmitry E. Oboukhov
>>: :’ : email: unera(at)debian(dot)org jabber: //UNera(at)uvw(dot)ru
>>`. `~’ GPGKey: 1024D / F8E26537 2006-11-21
>>  `- 1B23 D4F8 8EC0 D902 0555 E438 AB8C 00CF F8E2 6537
>
>
>