Как стать автором
Обновить

Комментарии 34

PgQ состоит из частей (как минимум 2-х): 1 — расширение pgq для postgres, 2 — демон pgqd

О, ну, конечно же, это в разы меньше боли, чем установка


RabbitMQ, ActiveMQ, ZeroMQ и тд

// Режим сарказма: выкл

Так установка pgq это ~7 строчек в терминале, а отдельный сервис надо не только поставить, но и обновлять, мониторить, тюнить и тд…

Вы так говорите, будто "демон pgqd" не надо мониторить...


Чем больше "кусочков", тем веселее

pgqd это 1000 строчек кода, вещь очень тонкая, от нее надо только чтобы она была запущена github.com/pgq/pgqd/tree/master/src
Берем Docker и…
… и что? Простите, но я не очень понимаю о чем вы…
Через Docker можно установить что угодно как отдельный сервис, и легко и быстро обновлять, мониторить и т. п. Разницы практически никакой.
Docker, конечно, прекрасный инструмент, но не панацея, не очень понимаю как он решит проблему с мониторингом, поддержкой (если что-то сломалось), необходимостью еще одной библиотеки, с которой надо разбираться, также, я это не упомянул, но pgq можно использовать внутри транзакций и тп…
PgQ по факту ничего в инфраструктуру не привносит (только pgqd, но это ~ ничего), а отдельные сервисы — отдельные сервисы

Ехал докер через докер
Докер докер докер докер

Ну вот да… Жизненная ситуация…
Читаешь значит такой про REST API, а там
получить данные — метод GET
создать — PUT
обновить — POST
удалить — DELETE
и думаешь — избыточно как-то, мне бы хватило только GET и POST, и тут приходит PgQ и говорит: «Не парься, чувак, у нас вобще все через select»
(улыбнуло)
Так вызываются функции в Postgres, рекомендую погуглить, или почитать что-нибудь подобное postgrespro.ru/docs/postgresql/12/xfunc-sql

вы немного не поняли.


вот уже есть какой-то контекст, где уже "всё через select" (активно используется postgres). и потребовалось добавить очереди. именно в этом случае и есть смысл глядеть на реализацию очередей на постгре.


только, честно говоря, по этой статье я так и не понял почему стоит выбрать (или хотя бы серьёзно рассматривать) именно PgQ

только, честно говоря, по этой статье я так и не понял почему стоит выбрать (или хотя бы серьёзно рассматривать) именно PgQ

PgQ идет с Postgres, если вы уже используете Postgres, возможно, вам будет легче начать использовать и PgQ, а не отдельные сервисы (но это только мое мнение).
Также PgQ транзакционен, это большой плюс.

на всякий случай уточню, я имел в виду "PgQ — далеко не единственная реализация очередей на базе postgresql, статья не показывает чем он отличается от прочих"

Тогда зависит от конкретной реализации. Скорее всего производительностью, за счет деления на бачи, например.
почему стоит выбрать (или хотя бы серьёзно рассматривать) именно PgQ

Потому что pgq учитывает как именно работает с данными postgresql. Очень пристально учитывает. И потому не умирает под нагрузкой от любых транзакций длительностью более 15 минут из-за помех работы вакууму — что характерно для самописных очередей (как например вот таких)
Каждый раз когда натыкаюсь на какой нибудь плагин для постгреса, вспоминаю этот комментарий:
Redis и MongoDB не нужны, потому что Постгрес проще, удобнее и быстрее.
Если бы Ruby был написан на хранимках в Постгресе, он работал бы в три раза быстрее и не падал.
Ноду пришлось писать на V8, потому что джаваскриптеры не поняли лицензию Постгреса, а Erlang появился, потому что кто-то просто не умеет пользоваться триггерами и хранимками.
K&R после создания C пришлось писать UNIX, потому что они хотели, конечно, написать Постгрес, но ему было не на чем запускаться.
C++0X появился только для того, чтобы умные люди перестали писать на C и перешли на Постгрес.
Разработка файловых систем нового поколения часто тормозится (особенно ZFS), потому что люди понимают, что с какой стороны не подходи и что не делай, а из-за требований нормальной транзакционности все равно получается Постгрес!
Сам Постгрес написан на хранимках Постгреса, мейкфайл выполнен в виде дампа Постгреса, и собирается Постгрес Постгресом.
Я ни в коем случае не имею в виду, что сторонние сервисы для очередей не нужны, но часто без них будет проще обойтись (на мой взгляд).
В любом случае, после прочтения, выбор брокера очередей все равно остается за вами, например, если вы и ваша команда эксперты в rabbitmq, он вам подходит (по техническим соображениям), и вы умеете его готовить, то скорее всего вам лучше всего подойдет именно он, но если это не так, теперь вы можете посмотреть и в сторону PgQ.

Пардон, а как сие чудо использовать клиенту? Например как устроить листенер месседжей через стандартный jdbc, чтобы он не делал тупой полинг? Да и зачем так усложнять, если уже есть LISTEN/NOTIFY?

LISTEN/NOTIFY о PubSub, а PgQ об очередях.
А чем плох полинг? 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 + полинг.
1) ИМХО специализированный инструмент будет работать на порядок лучше, чем универсальный. Есть какие-нибудь тесты, показывающие, чем PgQ лучше/хуже, чем тот же RabbitMQ?
2) Навешивая на PostgreSQL кучу всяких свистелок, вы превращаете его в одну большую точку отказа.
Есть какие-нибудь тесты, показывающие, чем PgQ лучше/хуже, чем тот же RabbitMQ?

Вы имеете в виду производительность? Это отдельная тема, в статье я ее почти не затрагивал, в основном я говорил об удобстве.
Навешивая на PostgreSQL кучу всяких свистелок, вы превращаете его в одну большую точку отказа.

Если вы используете Postgres, и вам нужна отказоустойчивость, то скорее всего вы о ней уже позаботились (patroni и тп), но да в каком-то смысле вы правы.
А что если мне нужно делать http запрос в сторонний сервис? Мне придеться переодически слать запросы на получение бачей?
(если я правильно понял ваш вопрос)

Мне придется периодически слать запросы на получение бачей?

Я обычно в своем языке программирования один раз пишу абстракцию очереди и вызываю ее методы Put, Subscribe, Unsubscribe… там где нужна очередь, при этом реализую получение бачей (и другое взаимодействие с PgQ) только один раз в ней.

А что если мне нужно делать http запрос в сторонний сервис?

Зависит от http запроса, если вы хотите выполнить его асинхронно, то да, для этого PgQ подойдет.
Да, PgQ был разработан в skype, только сейчас актуальная версия — 3, а этот доклад относится ко 2, но основные концепты не поменялись, поэтому подобные вещи полезно читать (на мой взгляд), несмотря на то что местами они могли устареть.
Понял. Спасибо за статью (и информацию).
Насколько я понимаю, pgq — это инструмент позволяющий перенести часть логики работы с очередями в базу данных. Но ведь, большинство маломальски средних проектов наоборот, стремятся вынести всю логику на уровне кода в пользу базы данных. Возможно, конечно, у меня просто небыло задач, где бы пригодился pgq.
В любом случае спасибо за ваш труд, было познавательно почитать.
Но ведь, большинство маломальски средних проектов наоборот, стремятся вынести всю логику на уровне кода в пользу базы данных.

Обычно речь о бизнес-логике, тут ситуация другая. Очередь это тип базы данных, вы же используете БД, а не храните данные в собственном формате в файлах или вообще напрямую на блочном устройстве.
В данном случае PgQ легко (по крайней мере я пишу на golang) оборачивается в абстракцию на уровне вашего приложения и легко подменяется другими реализациями в случае необходимости, а поверх этого уже реализуется ваша бизнес-логика.
1. хотел поинтересоваться есть примеры когда нужно использовать данное решение?
2. как данное решение можно масштабировать?
3. есть возможность подписаться и не писать свой скедулер а просто получить сообщение которое пришло?
4. какая конфигурация пула бд должно быть скажем на 1к
1. хотел поинтересоваться есть примеры когда нужно использовать данное решение?

Вообще они есть в различных докладах на эту тему, но, если кратко, то тогда же, когда вы используете очереди (т.к. это и есть очередь), например в этой статье есть раздел Использование очереди сообщений, пункты которого относятся к +- любой очереди.

2. как данное решение можно масштабировать?

Вместе с Postgres, но у PgQ такая производительность, что проблем не должно быть (рекомендую вам самим это проверить).

3. есть возможность подписаться и не писать свой скедулер а просто получить сообщение которое пришло?

А что вы называете скедулером? Получение бачей — это простой цикл for + if + sleep, работающий в отдельном потоке.

4. какая конфигурация пула бд должно быть скажем на 1к

Не очень понимаю что вы имеете в виду под пулом бд и , но если я правильно понял, то PgQ спокойно обрабатывает тысячи запросов в секунду на t3.nano + 20 gb gp2 ebs, не верьте мне, проверьте сами.
Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.