чуть больше среднего) использовать один общий инстанс(кластер) PG, но с отдельной БД для каждого сервиса? Какие от этого могут быть плюсы и минусы?
Взаимное влияние. Проблемы с производительностью одной бд могут аффектить всех. А так была бы норм идея, т.к. обслуживать одну систему всегда проще, чем сто.
Это нормально абсолютно. Если перформанса не хватит, то вынесите в отдельный инстанс
Херновая идея, грабли, об которые я сломал лоб несколько лет назад. Дважды - второй раз это было несколько постмастеров в одной ос. Лучше отдельные системы, хотя бы виртуалки/вдски с независимыми ядрами и памятью. А админится весь зоопарк вполне нормально скриптами.
У нас сейчас так и мы выросли из этого горшочка. Проблема №1 - когда один сервис обрастает траффиком, он начинает пожирать больше connection pools в pgbouncer, соответственно больше active connections в PG, а один инстанс ограничен в max active connections по кол-ву RAM (как например в GCP), проблема №2 - вертикальное масштабирование инстанса кладёт все базы, если используете pgbouncer, то можно поставить на паузу, но в зависимости от траффика, может накопиться очень много запросов. Проблема №3 - апгрейд одной базы допустим с PG 9 на PG 12 может иметь несовместимости и тогда придётся писать миграции на все базы одним махом, а не мигрировать по одной. Мы рассматриваем вариант Patroni+Spilo от Zalando, но есть проблемы с их postgres-operator, он выкатывает всего один connection pooler и мы пока не понимаем как разделять read/write стримы (как коннектиться к мастеру или слейву) через этот пулер.
Обсуждают сегодня