Обсуждение: Re: [pgsql-ru-general] философия: хранение картинок
привет. 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@debian.org>:
задам такой вопрос:
есть веб-проект, где пользователи загружают некоторые картинки себе в
профиль.
набор картинок условно говоря у всех пользователей одинаков.
нужно реализовать хранилище вида
- кладем картинку
- какой-то рабочий у хранилища создает для картинки preview, icon,
fulllsize изображения
- после этого процесс покладки картинки считаем завершенным
далее внешние запросы будут обращаться к картинкам строго по их ID.
какой дорогой пошли сперва:
Pg и три (или одна со столбиками) таблички icon, preview, full.
вебсервер который по ID делает запрос в одну из табличек за телом
картинки.
уперлись в то что вебсервер надо писать в асинхронном стиле (что не
проблема), причем ему нужна асинхронная работа с БД, что уже является
проблемой (асинхронность полностью не поддерживается драйверами и
Pg: то есть нельзя заслать множество запросов в Pg в асинхронном стиле
и ждать ответы на них, чтобы порядок был неважен итп)
а если сервер в синхронном стиле написан, то нагрузка его прибивает
очень здорово (повторюсь: выборка изображений строго по ID его
задача).
в итоге от Pg мы отказались, а стали хранить изображения в файликах на
диске.
Тут сильно страдает консистентность, но в угоду стоимости разработки
на это пошли.
вопрос: а как правильно организовать хранение картинок, чтобы
1. дешево разрабатывать и использовать
2. получить плюшки от индексов (например с помощью Pg можно отвечать
на вопросы "дай картинки похожие на эту")
--
. ''`. Dmitry E. Oboukhov
: :’ : email: unera@debian.org jabber://UNera@uvw.ru
`. `~’ GPGKey: 1024D / F8E26537 2006-11-21
`- 1B23 D4F8 8EC0 D902 0555 E438 AB8C 00CF F8E2 6537
Re: [pgsql-ru-general] Re: [pgsql-ru-general] философия: хранение картинок
Понедельник, 16 марта 2015, 16:26 +03:00 от Миша Тюрин <tmihail@bk.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@debian.org>:
Раз уж тут пошло обсуждение "что правильно а что нет"
задам такой вопрос:
есть веб-проект, где пользователи загружают некоторые картинки себе в
профиль.
набор картинок условно говоря у всех пользователей одинаков.
нужно реализовать хранилище вида
- кладем картинку
- какой-то рабочий у хранилища создает для картинки preview, icon,
fulllsize изображения
- после этого процесс покладки картинки считаем завершенным
далее внешние запросы будут обращаться к картинкам строго по их ID.
какой дорогой пошли сперва:
Pg и три (или одна со столбиками) таблички icon, preview, full.
вебсервер который по ID делает запрос в одну из табличек за телом
картинки.
уперлись в то что вебсервер надо писать в асинхронном стиле (что не
проблема), причем ему нужна асинхронная работа с БД, что уже является
проблемой (асинхронность полностью не поддерживается драйверами и
Pg: то есть нельзя заслать множество запросов в Pg в асинхронном стиле
и ждать ответы на них, чтобы порядок был неважен итп)
а если сервер в синхронном стиле написан, то нагрузка его прибивает
очень здорово (повторюсь: выборка изображений строго по ID его
задача).
в итоге от Pg мы отказались, а стали хранить изображения в файликах на
диске.
Тут сильно страдает консистентность, но в угоду стоимости разработки
на это пошли.
вопрос: а как правильно организовать хранение картинок, чтобы
1. дешево разрабатывать и использовать
2. получить плюшки от индексов (например с помощью Pg можно отвечать
на вопросы "дай картинки похожие на эту")
--
. ''`. Dmitry E. Oboukhov
: :’ : email: unera@debian.org jabber://UNera@uvw.ru
`. `~’ GPGKey: 1024D / F8E26537 2006-11-21
`- 1B23 D4F8 8EC0 D902 0555 E438 AB8C 00CF F8E2 6537
> привет. pgq. простой консумер. а из конечного обработчика потом и веб можно > подопнуть. да мы немного на других очередях примерно так первичную обработку и сделали. вопрос основной был как дальше раздавать эти картинки асинхронного коннектора (полностью асинхронного) к Pg нет и соответственно когда зайдет 30 пользователей - пойдет 30 запросов по ID и соответственно все начинает тупить и плавать ибо передача данных от Pg занимает коннектор целиком. -- . ''`. Dmitry E. Oboukhov : :’ : email: unera@debian.org jabber://UNera@uvw.ru `. `~’ GPGKey: 1024D / F8E26537 2006-11-21 `- 1B23 D4F8 8EC0 D902 0555 E438 AB8C 00CF F8E2 6537
Вложения
Re[2]: [pgsql-ru-general] Re: [pgsql-ru-general] философия: хранение картинок
Ну и еще можно похимичить с асинком через dblink самого на себя... Это как-раз и будет то, что вы хотите (1 коннект, 10 запросов, как только готов первый - канал занят его передачей, потом второй и т.д.), но это такие костыли...
Понедельник, 16 марта 2015, 19:12 +03:00 от "Dmitry E. Oboukhov" <unera@debian.org>:
> привет. pgq. простой консумер. а из конечного обработчика потом и веб можно
> подопнуть.
да мы немного на других очередях примерно так первичную обработку и
сделали.
вопрос основной был как дальше раздавать эти картинки
асинхронного коннектора (полностью асинхронного) к Pg нет и
соответственно когда зайдет 30 пользователей - пойдет 30 запросов по
ID
и соответственно все начинает тупить и плавать ибо передача данных от
Pg занимает коннектор целиком.
--
. ''`. Dmitry E. Oboukhov
: :’ : email: unera@debian.org jabber://UNera@uvw.ru
`. `~’ GPGKey: 1024D / F8E26537 2006-11-21
`- 1B23 D4F8 8EC0 D902 0555 E438 AB8C 00CF F8E2 6537
вопрос основной был как дальше раздавать эти картинки
асинхронного коннектора (полностью асинхронного) к Pg нет и
соответственно когда зайдет 30 пользователей - пойдет 30 запросов по
ID
и соответственно все начинает тупить и плавать ибо передача данных от
Pg занимает коннектор целиком.
pgbouncer
transaction pooling
у нас в авито на одной из машин 7KTPS на 600%cpu
но сами файлы то nginx раздает, из базы тока айдишки, которые суть имя файла
-- миша
Re: [pgsql-ru-general] Re[2]: [pgsql-ru-general] Re: [pgsql-ru-general] философия: хранение картинок
вопрос основной был как дальше раздавать эти картинки
асинхронного коннектора (полностью асинхронного) к Pg нет и
соответственно когда зайдет 30 пользователей - пойдет 30 запросов по
ID
и соответственно все начинает тупить и плавать ибо передача данных от
Pg занимает коннектор целиком.
pgbouncer
transaction pooling
Не используем. Единственные "привелегии" -- pgbouncer на некоторых машинах с la небольшим (cpu-bound) -- renice -20
понедельник, 16 марта 2015г., 21:28 +03:00 от Dmitry Igrishin <dmitigr@gmail.com>:
16 марта 2015 г., 20:05 пользователь Миша Тюрин < tmihail@bk.ru > написал:
>>вопрос основной был как дальше раздавать эти картинки
>>
>>асинхронного коннектора (полностью асинхронного) к Pg нет и
>>соответственно когда зайдет 30 пользователей - пойдет 30 запросов по
>>ID
>>и соответственно все начинает тупить и плавать ибо передача данных от
>>Pg занимает коннектор целиком.
>pgbouncer
>transaction pooling
Оффтопик, но интереса ради. Используете ли вы систему привилегий ролей Postgres?
--
// Dmitry.