Comments 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, но это ~ ничего), а отдельные сервисы — отдельные сервисы
PgQ по факту ничего в инфраструктуру не привносит (только pgqd, но это ~ ничего), а отдельные сервисы — отдельные сервисы
Читаешь значит такой про REST API, а там
получить данные — метод GET
создать — PUT
обновить — POST
удалить — DELETE
и думаешь — избыточно как-то, мне бы хватило только GET и POST, и тут приходит PgQ и говорит: «Не парься, чувак, у нас вобще все через select»
получить данные — метод GET
создать — PUT
обновить — POST
удалить — DELETE
и думаешь — избыточно как-то, мне бы хватило только GET и POST, и тут приходит PgQ и говорит: «Не парься, чувак, у нас вобще все через select»
(улыбнуло)
Так вызываются функции в Postgres, рекомендую погуглить, или почитать что-нибудь подобное postgrespro.ru/docs/postgresql/12/xfunc-sql
Так вызываются функции в Postgres, рекомендую погуглить, или почитать что-нибудь подобное postgrespro.ru/docs/postgresql/12/xfunc-sql
вы немного не поняли.
вот уже есть какой-то контекст, где уже "всё через select" (активно используется postgres). и потребовалось добавить очереди. именно в этом случае и есть смысл глядеть на реализацию очередей на постгре.
только, честно говоря, по этой статье я так и не понял почему стоит выбрать (или хотя бы серьёзно рассматривать) именно PgQ
только, честно говоря, по этой статье я так и не понял почему стоит выбрать (или хотя бы серьёзно рассматривать) именно PgQ
PgQ идет с Postgres, если вы уже используете Postgres, возможно, вам будет легче начать использовать и PgQ, а не отдельные сервисы (но это только мое мнение).
Также PgQ транзакционен, это большой плюс.
почему стоит выбрать (или хотя бы серьёзно рассматривать) именно PgQ
Потому что pgq учитывает как именно работает с данными postgresql. Очень пристально учитывает. И потому не умирает под нагрузкой от любых транзакций длительностью более 15 минут из-за помех работы вакууму — что характерно для самописных очередей (как например вот таких)
UFO just landed and posted this here
Я ни в коем случае не имею в виду, что сторонние сервисы для очередей не нужны, но часто без них будет проще обойтись (на мой взгляд).
В любом случае, после прочтения, выбор брокера очередей все равно остается за вами, например, если вы и ваша команда эксперты в rabbitmq, он вам подходит (по техническим соображениям), и вы умеете его готовить, то скорее всего вам лучше всего подойдет именно он, но если это не так, теперь вы можете посмотреть и в сторону PgQ.
В любом случае, после прочтения, выбор брокера очередей все равно остается за вами, например, если вы и ваша команда эксперты в rabbitmq, он вам подходит (по техническим соображениям), и вы умеете его готовить, то скорее всего вам лучше всего подойдет именно он, но если это не так, теперь вы можете посмотреть и в сторону PgQ.
Пардон, а как сие чудо использовать клиенту? Например как устроить листенер месседжей через стандартный jdbc, чтобы он не делал тупой полинг? Да и зачем так усложнять, если уже есть LISTEN/NOTIFY?
LISTEN/NOTIFY о PubSub, а PgQ об очередях.
А чем плох полинг? Eго просто реализовать — простой for, он никак не влияет на производительность. Если next_batch вернул null спите несколько секунд (размер тика в pgqd), если не null, то обрабатываете и сразу берете следующий.
А чем плох полинг? 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 кучу всяких свистелок, вы превращаете его в одну большую точку отказа.
2) Навешивая на PostgreSQL кучу всяких свистелок, вы превращаете его в одну большую точку отказа.
Есть какие-нибудь тесты, показывающие, чем PgQ лучше/хуже, чем тот же RabbitMQ?
Вы имеете в виду производительность? Это отдельная тема, в статье я ее почти не затрагивал, в основном я говорил об удобстве.
Навешивая на PostgreSQL кучу всяких свистелок, вы превращаете его в одну большую точку отказа.
Если вы используете Postgres, и вам нужна отказоустойчивость, то скорее всего вы о ней уже позаботились (patroni и тп), но да в каком-то смысле вы правы.
А что если мне нужно делать http запрос в сторонний сервис? Мне придеться переодически слать запросы на получение бачей?
(если я правильно понял ваш вопрос)
Я обычно в своем языке программирования один раз пишу абстракцию очереди и вызываю ее методы Put, Subscribe, Unsubscribe… там где нужна очередь, при этом реализую получение бачей (и другое взаимодействие с PgQ) только один раз в ней.
Зависит от http запроса, если вы хотите выполнить его асинхронно, то да, для этого PgQ подойдет.
Мне придется периодически слать запросы на получение бачей?
Я обычно в своем языке программирования один раз пишу абстракцию очереди и вызываю ее методы Put, Subscribe, Unsubscribe… там где нужна очередь, при этом реализую получение бачей (и другое взаимодействие с PgQ) только один раз в ней.
А что если мне нужно делать http запрос в сторонний сервис?
Зависит от http запроса, если вы хотите выполнить его асинхронно, то да, для этого PgQ подойдет.
А это тоже самое (вроде как от разработчиков skype) или что-то другое?
www.pgcon.org/2008/schedule/attachments/55_pgq.pdf
www.pgcon.org/2008/schedule/attachments/55_pgq.pdf
Насколько я понимаю, pgq — это инструмент позволяющий перенести часть логики работы с очередями в базу данных. Но ведь, большинство маломальски средних проектов наоборот, стремятся вынести всю логику на уровне кода в пользу базы данных. Возможно, конечно, у меня просто небыло задач, где бы пригодился pgq.
В любом случае спасибо за ваш труд, было познавательно почитать.
В любом случае спасибо за ваш труд, было познавательно почитать.
Но ведь, большинство маломальски средних проектов наоборот, стремятся вынести всю логику на уровне кода в пользу базы данных.
Обычно речь о бизнес-логике, тут ситуация другая. Очередь это тип базы данных, вы же используете БД, а не храните данные в собственном формате в файлах или вообще напрямую на блочном устройстве.
В данном случае PgQ легко (по крайней мере я пишу на golang) оборачивается в абстракцию на уровне вашего приложения и легко подменяется другими реализациями в случае необходимости, а поверх этого уже реализуется ваша бизнес-логика.
1. хотел поинтересоваться есть примеры когда нужно использовать данное решение?
2. как данное решение можно масштабировать?
3. есть возможность подписаться и не писать свой скедулер а просто получить сообщение которое пришло?
4. какая конфигурация пула бд должно быть скажем на 1к
2. как данное решение можно масштабировать?
3. есть возможность подписаться и не писать свой скедулер а просто получить сообщение которое пришло?
4. какая конфигурация пула бд должно быть скажем на 1к
1. хотел поинтересоваться есть примеры когда нужно использовать данное решение?
Вообще они есть в различных докладах на эту тему, но, если кратко, то тогда же, когда вы используете очереди (т.к. это и есть очередь), например в этой статье есть раздел Использование очереди сообщений, пункты которого относятся к +- любой очереди.
2. как данное решение можно масштабировать?
Вместе с Postgres, но у PgQ такая производительность, что проблем не должно быть (рекомендую вам самим это проверить).
3. есть возможность подписаться и не писать свой скедулер а просто получить сообщение которое пришло?
А что вы называете скедулером? Получение бачей — это простой цикл for + if + sleep, работающий в отдельном потоке.
4. какая конфигурация пула бд должно быть скажем на 1к
Не очень понимаю что вы имеете в виду под пулом бд и 1к, но если я правильно понял, то PgQ спокойно обрабатывает тысячи запросов в секунду на t3.nano + 20 gb gp2 ebs, не верьте мне, проверьте сами.
Sign up to leave a comment.
Очереди сообщений в PostgreSQL с использованием PgQ