Pull to refresh
8
0

Пользователь

Очереди сообщений в PostgreSQL с использованием PgQ

1. хотел поинтересоваться есть примеры когда нужно использовать данное решение?

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

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

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

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

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

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

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

Очереди сообщений в PostgreSQL с использованием PgQ

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

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

Очереди сообщений в PostgreSQL с использованием PgQ

Да, PgQ был разработан в skype, только сейчас актуальная версия — 3, а этот доклад относится ко 2, но основные концепты не поменялись, поэтому подобные вещи полезно читать (на мой взгляд), несмотря на то что местами они могли устареть.

Очереди сообщений в PostgreSQL с использованием PgQ

Плох тем, что большой latency, поэтому и не годится в сценариях, где месседжи приходят достаточно редко, но требуют моментальной обработки.

Не очень понимаю, что за сценарий такой, и не уверен, что для этого вообще стоит использовать очереди.
(Также вам никто не запрещает использовать PgQ (для гарантий обработки) + LISTEN/NOTIFY (для отсутствия latency))

А на коленках через полинг я очереди могу сделать и через обычную таблицу — для этого не нужен PgQ.

Почему не надо использовать самописные очереди — отдельная тема, описанная много где, например тут.

Поэтому прежде чем заявлять, что Postgresql умеет очереди, нужно позаботиться о клиентских интерфейсах и имплементировать стандартные протоколы типа AMQP, MQTT, STOMP, JMS, etc

С обычными задачами (отправка уведомлений, ресайз картинок и тп (задачи, для которых latency ~секунда норма)) прекрасно справляется select + полинг.

Очереди сообщений в PostgreSQL с использованием PgQ

Тогда зависит от конкретной реализации. Скорее всего производительностью, за счет деления на бачи, например.

Очереди сообщений в PostgreSQL с использованием PgQ

Есть какие-нибудь тесты, показывающие, чем PgQ лучше/хуже, чем тот же RabbitMQ?

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

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

Очереди сообщений в PostgreSQL с использованием PgQ

(если я правильно понял ваш вопрос)

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

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

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

Зависит от http запроса, если вы хотите выполнить его асинхронно, то да, для этого PgQ подойдет.

Очереди сообщений в PostgreSQL с использованием PgQ

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

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

Очереди сообщений в PostgreSQL с использованием PgQ

LISTEN/NOTIFY о PubSub, а PgQ об очередях.
А чем плох полинг? Eго просто реализовать — простой for, он никак не влияет на производительность. Если next_batch вернул null спите несколько секунд (размер тика в pgqd), если не null, то обрабатываете и сразу берете следующий.

Очереди сообщений в PostgreSQL с использованием PgQ

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

Очереди сообщений в PostgreSQL с использованием PgQ

Ну вот да… Жизненная ситуация…

Очереди сообщений в PostgreSQL с использованием PgQ

(улыбнуло)
Так вызываются функции в Postgres, рекомендую погуглить, или почитать что-нибудь подобное postgrespro.ru/docs/postgresql/12/xfunc-sql

Очереди сообщений в PostgreSQL с использованием PgQ

Docker, конечно, прекрасный инструмент, но не панацея, не очень понимаю как он решит проблему с мониторингом, поддержкой (если что-то сломалось), необходимостью еще одной библиотеки, с которой надо разбираться, также, я это не упомянул, но pgq можно использовать внутри транзакций и тп…
PgQ по факту ничего в инфраструктуру не привносит (только pgqd, но это ~ ничего), а отдельные сервисы — отдельные сервисы

Очереди сообщений в PostgreSQL с использованием PgQ

… и что? Простите, но я не очень понимаю о чем вы…

Очереди сообщений в PostgreSQL с использованием PgQ

pgqd это 1000 строчек кода, вещь очень тонкая, от нее надо только чтобы она была запущена github.com/pgq/pgqd/tree/master/src

Очереди сообщений в PostgreSQL с использованием PgQ

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

Тайная жизнь Linux сервера или веерная брутфорс атака на подсистему SSH

А почему бы не запретить доступ по поролям, и не использовать ключи?

Information

Rating
Does not participate
Registered
Activity