Comments 26
Если думаете про использование listen/notify — обязательно прочтите это: github.com/postgres/postgres/blob/REL_11_STABLE/src/backend/commands/async.c#L16
И подумайте, подходят ли эти ограничения для вашей задачи.
Ну и это очевидно не будет работать через transaction pool mode pgbouncer'а.
И подумайте, подходят ли эти ограничения для вашей задачи.
Ну и это очевидно не будет работать через transaction pool mode pgbouncer'а.
Если ваши микросервисы уже используют общую базу PostgreSQL
Бегите, глупцы.
А так каждая подписка жрет коннект к postgres, а они там не очень дешевые, разве нет?
NOTIFY канал [, сообщение ]а почему не pg_notify?
А зачем использовать SELECT из функции, который явно больших усилий требует со стороны PG, если можно без этого? Вот изнутри сложного запроса или хранимки звать — так тут просто другого варианта нет.
:) Это одно и то же)))
Просто вызывая pg_notify можно использовать переменные в хранимках и прочие plsql штуки для динамического формирования имён каналов или сообщений, а в NOTIFY — только литералы.
вот мнение почему так делать не стоит dvps.blog/postgresql-missusage
Всегда надо стараться соблюсти баланс — с одной стороны не городить себе же SPoF, с другой — не умножать сущностей без надобности.
Был у нас один кейс, когда отказ от «внешнего» (относительно бизнес-логик) RabbitMQ-кластера в пользу такой «наколеночной» реализации через PG, с которым «все равно уже работали» свел задержки доставки событий практически до нуля — с секунд.
Был у нас один кейс, когда отказ от «внешнего» (относительно бизнес-логик) RabbitMQ-кластера в пользу такой «наколеночной» реализации через PG, с которым «все равно уже работали» свел задержки доставки событий практически до нуля — с секунд.
Спасибо, добавил себе в коллекцию анти-паттернов.
Если ваши микросервисы уже используют общую базу PostgreSQL для хранения данных
выносите, дробите, делите базу на разные…
Вы предлагаете под каждый сервис выделять, в пределе, изолированную реплику базы? То есть если один сервис работает с таблицами [A, B, C, X], а другой с [A, B, C, Y] — все, нельзя жить вместе?
Как бы чуть-чуть слишком затратно.
Как бы чуть-чуть слишком затратно.
да все так: 1 сервис — 1 база, у которой может быть несколько таблиц — но только из одной домменой модели.
Ключевое что доступ к определенной базе, у которой может быть несколько таблиц — только у 1го сервиса
Ничего трудозатратного — если уметь готовить.
Ключевое что доступ к определенной базе, у которой может быть несколько таблиц — только у 1го сервиса
Ничего трудозатратного — если уметь готовить.
А куда делись остальные таблицы, с которыми, сервис работает? Или вы предлагаете все свести к межсервисным взаимодействиям с джойнами в прикладном коде?..
если это сущности этого же сервиса — то конечно несколько таблиц. Но если ему нужна информацию по user'у будь добр сделать запрос в другой сервис — ответственный за это.
Ключевое что доступ к определенной базе, у которой может быть несколько таблиц — только у 1го сервиса
Ключевое что доступ к определенной базе, у которой может быть несколько таблиц — только у 1го сервиса
Как и любое «абсолютное» решение, его производительность сильно проигрывает тому же JOIN с реплицированной с базы мастер-сервиса таблицей.
это выигрывает сейчас, но потом нет.
Если шарится база — прощай независимый деплой, дублирование моделей и т.д. — шанс сломать что то…
Микросервисы — это для горизонтального масштабирования, что будет когда у нас будет 2000+ инстансов? Мы упремся в базу!
Если шарится база — прощай независимый деплой, дублирование моделей и т.д. — шанс сломать что то…
Микросервисы — это для горизонтального масштабирования, что будет когда у нас будет 2000+ инстансов? Мы упремся в базу!
Я не говорю что надо делать разные сервисы для товара в ИМ, для его свойств и фото.
Это все один сервис items — но сервисы orders и basket не должны шарить базу с ним — только межсервисные взаимодействия
Это все один сервис items — но сервисы orders и basket не должны шарить базу с ним — только межсервисные взаимодействия
Такое «не должны» не является абсолютной истиной. Вы просто размениваете иллюзию независимости сервисов на сложность их разработки (custom join) и поддержки.
Разнесли вы items, orders и basket на разные сервисы — а потом приходит менеджмент с необходимостью регулярно делать сводный отчет по товарам, отложенным в корзину, но невыкупленным — и начинаются костыли, потому что нормально работать он не сможет при проблемах на _любом_ из этих сервисов.
То есть на одном конце линейки у нас хардкорный монолит, на другом — «россыпь» сервисов 1-в-1. Любое из этих решений в чем-то плохо, в чем-то хорошо — и надо уметь соблюсти баланс, а не строго следовать какой-то догме.
Разнесли вы items, orders и basket на разные сервисы — а потом приходит менеджмент с необходимостью регулярно делать сводный отчет по товарам, отложенным в корзину, но невыкупленным — и начинаются костыли, потому что нормально работать он не сможет при проблемах на _любом_ из этих сервисов.
То есть на одном конце линейки у нас хардкорный монолит, на другом — «россыпь» сервисов 1-в-1. Любое из этих решений в чем-то плохо, в чем-то хорошо — и надо уметь соблюсти баланс, а не строго следовать какой-то догме.
И я про это — для приложение в 1000 человек в день — микросервисы не нужны, монолита хватит. Но при большой нагрузке не получится горизонтально масштабироваться — а ведь это ключевое зачем используют микросервисы.
Мы делали сервис, где только одного сервиса было поднято 100+ инстансов
Но городить огород: «микросервисы с общими базами» — ответ простой — или монолит или разносить — микросервисы тут не нужны.
Мы делали сервис, где только одного сервиса было поднято 100+ инстансов
Но городить огород: «микросервисы с общими базами» — ответ простой — или монолит или разносить — микросервисы тут не нужны.
Если у вас 1% времени уходит на работу с базой и 99% на прикладной код сервиса, что, кроме идеологических соображений, должно помешать посадить на эту базу 10 инстансов или 10 сервисов?
Я не понимаю что вы хотите доказать)
Рано или поздно мы упремся в базу, вариант один горизонтальное масштабирование.
Только вопрос в том когда упремся:
Скоро? Разносить
Никогда? Тогда вообще забыть о микросервисах
Рано или поздно мы упремся в базу, вариант один горизонтальное масштабирование.
Только вопрос в том когда упремся:
Скоро? Разносить
Никогда? Тогда вообще забыть о микросервисах
«Преждевременная оптимизация — корень всех (или большинства) проблем в программировании.» © Дональд Кнут
Если мы начинаем упираться в базу — ее стоит как-то масштабировать. Если в сервисы — масштабировать их.
Когда это потребуется и как это потребуется. Но подходить аксиоматически «таблицей может пользоваться только один сервис» — плохой подход с точки зрения бизнеса.
Если что, для ноды уже давно есть https://github.com/andywer/pg-listen
Sign up to leave a comment.
PubSub почти бесплатно: особенности NOTIFY в PostgreSQL