Comments 35
PgQ состоит из частей (как минимум 2-х): 1 — расширение pgq для postgres, 2 — демон pgqd
О, ну, конечно же, это в разы меньше боли, чем установка
RabbitMQ, ActiveMQ, ZeroMQ и тд
// Режим сарказма: выкл
Вы так говорите, будто "демон pgqd" не надо мониторить...
Чем больше "кусочков", тем веселее
PgQ по факту ничего в инфраструктуру не привносит (только pgqd, но это ~ ничего), а отдельные сервисы — отдельные сервисы
Так вызываются функции в Postgres, рекомендую погуглить, или почитать что-нибудь подобное postgrespro.ru/docs/postgresql/12/xfunc-sql
вы немного не поняли.
вот уже есть какой-то контекст, где уже "всё через select" (активно используется postgres). и потребовалось добавить очереди. именно в этом случае и есть смысл глядеть на реализацию очередей на постгре.
только, честно говоря, по этой статье я так и не понял почему стоит выбрать (или хотя бы серьёзно рассматривать) именно PgQ
только, честно говоря, по этой статье я так и не понял почему стоит выбрать (или хотя бы серьёзно рассматривать) именно PgQ
PgQ идет с Postgres, если вы уже используете Postgres, возможно, вам будет легче начать использовать и PgQ, а не отдельные сервисы (но это только мое мнение).
Также PgQ транзакционен, это большой плюс.
почему стоит выбрать (или хотя бы серьёзно рассматривать) именно PgQ
Потому что pgq учитывает как именно работает с данными postgresql. Очень пристально учитывает. И потому не умирает под нагрузкой от любых транзакций длительностью более 15 минут из-за помех работы вакууму — что характерно для самописных очередей (как например вот таких)
В любом случае, после прочтения, выбор брокера очередей все равно остается за вами, например, если вы и ваша команда эксперты в rabbitmq, он вам подходит (по техническим соображениям), и вы умеете его готовить, то скорее всего вам лучше всего подойдет именно он, но если это не так, теперь вы можете посмотреть и в сторону PgQ.
Пардон, а как сие чудо использовать клиенту? Например как устроить листенер месседжей через стандартный jdbc, чтобы он не делал тупой полинг? Да и зачем так усложнять, если уже есть LISTEN/NOTIFY?
А чем плох полинг? Eго просто реализовать — простой for, он никак не влияет на производительность. Если next_batch вернул null спите несколько секунд (размер тика в pgqd), если не null, то обрабатываете и сразу берете следующий.
Плох тем, что большой latency, поэтому и не годится в сценариях, где месседжи приходят достаточно редко, но требуют моментальной обработки. Впринципе LISTEN/NOTIFY как раз мог бы использоваться для нотификации, что в такую-то очередь пришло сообщение и надо его прочитать. Но проблема в том, что стандартный PG jdbc не умеет нотификации (только через тот же поллинг).
Поэтому прежде чем заявлять, что Postgresql умеет очереди, нужно позаботиться о клиентских интерфейсах и имплементировать стандартные протоколы типа AMQP, MQTT, STOMP, JMS, etc (например в Oracle идет поддержка JMS из коробки). А на коленках через полинг я очереди могу сделать и через обычную таблицу — для этого не нужен PgQ.
Плох тем, что большой latency, поэтому и не годится в сценариях, где месседжи приходят достаточно редко, но требуют моментальной обработки.
Не очень понимаю, что за сценарий такой, и не уверен, что для этого вообще стоит использовать очереди.
(Также вам никто не запрещает использовать PgQ (для гарантий обработки) + LISTEN/NOTIFY (для отсутствия latency))
А на коленках через полинг я очереди могу сделать и через обычную таблицу — для этого не нужен PgQ.
Почему не надо использовать самописные очереди — отдельная тема, описанная много где, например тут.
Поэтому прежде чем заявлять, что Postgresql умеет очереди, нужно позаботиться о клиентских интерфейсах и имплементировать стандартные протоколы типа AMQP, MQTT, STOMP, JMS, etc
С обычными задачами (отправка уведомлений, ресайз картинок и тп (задачи, для которых latency ~секунда норма)) прекрасно справляется select + полинг.
Почему не надо использовать самописные очереди — отдельная тема, описанная много где, например тут.
Из аргументов против использования самописной очереди нашел только то, что она забьется и будет медленно работать. Решается добавлением джобы, которая смотрит на статусы задач и либо удаляет их (переносит в другую таблицу / базу / S3), либо переносит в 'ready' и уменьшает retry_count (в зависимости от бизнес-логики).
2) Навешивая на PostgreSQL кучу всяких свистелок, вы превращаете его в одну большую точку отказа.
Есть какие-нибудь тесты, показывающие, чем PgQ лучше/хуже, чем тот же RabbitMQ?
Вы имеете в виду производительность? Это отдельная тема, в статье я ее почти не затрагивал, в основном я говорил об удобстве.
Навешивая на PostgreSQL кучу всяких свистелок, вы превращаете его в одну большую точку отказа.
Если вы используете Postgres, и вам нужна отказоустойчивость, то скорее всего вы о ней уже позаботились (patroni и тп), но да в каком-то смысле вы правы.
Мне придется периодически слать запросы на получение бачей?
Я обычно в своем языке программирования один раз пишу абстракцию очереди и вызываю ее методы Put, Subscribe, Unsubscribe… там где нужна очередь, при этом реализую получение бачей (и другое взаимодействие с PgQ) только один раз в ней.
А что если мне нужно делать http запрос в сторонний сервис?
Зависит от http запроса, если вы хотите выполнить его асинхронно, то да, для этого PgQ подойдет.
www.pgcon.org/2008/schedule/attachments/55_pgq.pdf
В любом случае спасибо за ваш труд, было познавательно почитать.
Но ведь, большинство маломальски средних проектов наоборот, стремятся вынести всю логику на уровне кода в пользу базы данных.
Обычно речь о бизнес-логике, тут ситуация другая. Очередь это тип базы данных, вы же используете БД, а не храните данные в собственном формате в файлах или вообще напрямую на блочном устройстве.
В данном случае PgQ легко (по крайней мере я пишу на golang) оборачивается в абстракцию на уровне вашего приложения и легко подменяется другими реализациями в случае необходимости, а поверх этого уже реализуется ваша бизнес-логика.
2. как данное решение можно масштабировать?
3. есть возможность подписаться и не писать свой скедулер а просто получить сообщение которое пришло?
4. какая конфигурация пула бд должно быть скажем на 1к
1. хотел поинтересоваться есть примеры когда нужно использовать данное решение?
Вообще они есть в различных докладах на эту тему, но, если кратко, то тогда же, когда вы используете очереди (т.к. это и есть очередь), например в этой статье есть раздел Использование очереди сообщений, пункты которого относятся к +- любой очереди.
2. как данное решение можно масштабировать?
Вместе с Postgres, но у PgQ такая производительность, что проблем не должно быть (рекомендую вам самим это проверить).
3. есть возможность подписаться и не писать свой скедулер а просто получить сообщение которое пришло?
А что вы называете скедулером? Получение бачей — это простой цикл for + if + sleep, работающий в отдельном потоке.
4. какая конфигурация пула бд должно быть скажем на 1к
Не очень понимаю что вы имеете в виду под пулом бд и 1к, но если я правильно понял, то PgQ спокойно обрабатывает тысячи запросов в секунду на t3.nano + 20 gb gp2 ebs, не верьте мне, проверьте сами.
Очереди сообщений в PostgreSQL с использованием PgQ