• Очереди сообщений в PostgreSQL с использованием PgQ
    0
    1. хотел поинтересоваться есть примеры когда нужно использовать данное решение?

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

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

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

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

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

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

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

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

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

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

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

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

    С обычными задачами (отправка уведомлений, ресайз картинок и тп (задачи, для которых latency ~секунда норма)) прекрасно справляется select + полинг.
  • Очереди сообщений в PostgreSQL с использованием PgQ
    0
    Тогда зависит от конкретной реализации. Скорее всего производительностью, за счет деления на бачи, например.
  • Очереди сообщений в PostgreSQL с использованием PgQ
    0
    Есть какие-нибудь тесты, показывающие, чем PgQ лучше/хуже, чем тот же RabbitMQ?

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

    Если вы используете Postgres, и вам нужна отказоустойчивость, то скорее всего вы о ней уже позаботились (patroni и тп), но да в каком-то смысле вы правы.
  • Очереди сообщений в PostgreSQL с использованием PgQ
    0
    (если я правильно понял ваш вопрос)

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

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

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

    Зависит от http запроса, если вы хотите выполнить его асинхронно, то да, для этого PgQ подойдет.
  • Очереди сообщений в PostgreSQL с использованием PgQ
    0
    только, честно говоря, по этой статье я так и не понял почему стоит выбрать (или хотя бы серьёзно рассматривать) именно PgQ

    PgQ идет с Postgres, если вы уже используете Postgres, возможно, вам будет легче начать использовать и PgQ, а не отдельные сервисы (но это только мое мнение).
    Также PgQ транзакционен, это большой плюс.
  • Очереди сообщений в PostgreSQL с использованием PgQ
    0
    LISTEN/NOTIFY о PubSub, а PgQ об очередях.
    А чем плох полинг? Eго просто реализовать — простой for, он никак не влияет на производительность. Если next_batch вернул null спите несколько секунд (размер тика в pgqd), если не null, то обрабатываете и сразу берете следующий.
  • Очереди сообщений в PostgreSQL с использованием PgQ
    0
    Я ни в коем случае не имею в виду, что сторонние сервисы для очередей не нужны, но часто без них будет проще обойтись (на мой взгляд).
    В любом случае, после прочтения, выбор брокера очередей все равно остается за вами, например, если вы и ваша команда эксперты в rabbitmq, он вам подходит (по техническим соображениям), и вы умеете его готовить, то скорее всего вам лучше всего подойдет именно он, но если это не так, теперь вы можете посмотреть и в сторону PgQ.
  • Очереди сообщений в PostgreSQL с использованием PgQ
    0
    Ну вот да… Жизненная ситуация…
  • Очереди сообщений в PostgreSQL с использованием PgQ
    +1
    (улыбнуло)
    Так вызываются функции в Postgres, рекомендую погуглить, или почитать что-нибудь подобное postgrespro.ru/docs/postgresql/12/xfunc-sql
  • Очереди сообщений в PostgreSQL с использованием PgQ
    0
    Docker, конечно, прекрасный инструмент, но не панацея, не очень понимаю как он решит проблему с мониторингом, поддержкой (если что-то сломалось), необходимостью еще одной библиотеки, с которой надо разбираться, также, я это не упомянул, но pgq можно использовать внутри транзакций и тп…
    PgQ по факту ничего в инфраструктуру не привносит (только pgqd, но это ~ ничего), а отдельные сервисы — отдельные сервисы
  • Очереди сообщений в PostgreSQL с использованием PgQ
    0
    … и что? Простите, но я не очень понимаю о чем вы…
  • Очереди сообщений в PostgreSQL с использованием PgQ
    –4
    pgqd это 1000 строчек кода, вещь очень тонкая, от нее надо только чтобы она была запущена github.com/pgq/pgqd/tree/master/src
  • Очереди сообщений в PostgreSQL с использованием PgQ
    0
    Так установка pgq это ~7 строчек в терминале, а отдельный сервис надо не только поставить, но и обновлять, мониторить, тюнить и тд…
  • Тайная жизнь Linux сервера или веерная брутфорс атака на подсистему SSH
    +5
    А почему бы не запретить доступ по поролям, и не использовать ключи?