Текушая ситуация: Имеется 40+ информационных систем, со своими базами данных postgres. Большая

часть (30) развернута посредством трех докеров: nginx, app and db.
Но есть и такие (10), которые работают на хосте (виртуальной машине).
Конфигурации виртуалок раличные, мониторим вручную поддерживая утилизацию по cpu и ram на уровне <70%.
Сейчас системы разрознены, работают каждая сама по себе, интеграции практически нет.
Идем в сторону сервис-ориентированной архитекуры.

Железо получаем от провайдера и имеем ограничения на виртуалки (на странность ограничений просьба не обращать внимания): max cpu = 54, max ram = 64Gb
Оптимизацию запросов делаем постоянно, для упрощения задачи будем считать, что все запросы максимально оптимизированы.

Задумываеся на общей архитектурой построения с точки зрения баз данных. Предполагаем, что имеется как минимум два пути:
1. Оставить как сейчас - каждый сервис со своей базой данных.
2. Смотреть на базу данных как на сервис - выделить энное количество серверов на общую базу данных, разделять доступы на уровне схем.


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


Во втором варианте - есть мнение, что одна большая база данных, расположенная на мощных серверах - лучше, потому что один админ следит кластером, может как-то оптимизировать ее, "раскидав" по дискам, например.
Но экспертизы не достаточно, нет понимания, как это все делать и самое главное:

Вопрос 1 - лучше ли одна база данных, чем множество (совокупный размер на данный момент - 16ТБ, потенциальный рост - до 2ПБ?)?
Вопрос 2 - имеет ли значение указанные выше ограничения на виртуалку по cpu/ram?

Холивары на тему - это уже не микро-сервис можно не заводить :-)

Это по-моему не имеет ничего общего с первоначально заданным вопросом.

Да я написал, что неправильно был поставлен вопрос.

Оставить разрозненные, разумеется. Масштабирование СУБД вверх -- это боль, тлен, бабло и IBM. Если у вас исторически сложылось такое замечательное шардирование по сервисам -- то его и оставляйте. Единое управление только введите -- там, деплой виртуалки с базой одной кнопкой, выгрузка из бэкапа другой, одна группа админов на все базы, списки репликацыи в цэнтральном репозитории, вот это всё. Общие данные можно сваливать в какие

Централизация БД плоха тем, что одно приложение скорее всего сможет положить вам весь инстанс БД и, как следствие, все остальные приложения лягут. Децентрализация - ну вы тут всё сами правильно написали. Для чего может понадобиться 56 ЦПУ на одном хосте - я, честно сказать, затрудняюсь представить. А вот куда можно девать 64 Гб RAM и даже больше - легко 😊

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

предпочитаем работать так: - избегаем LVM/ceph/docker (и прочая виртуализация), т.к. это лишняя административная прослойка, ни к чему - лучше иметь хороший выделенный сервер под N баз, чем N серверов под каждую базу — сильно проще админить - в сумме, N баз на одном сервере потребуют меньше ресурсов, чем на N серверах - если какая-то база сильно отрывается по нагрузке и сервер перестаёт тянуть — отселяем на отдельное железо (как правило, к такому моменту можно позволить) - RO нагрузку стараемся максимально отселять на реплики, которые есть всегда - стараемся по максимуму использовать pgbouncer: меньше сессий к базе, возможность поставить на паузу для работ на базе или же перенаправить трафик на другой сервер

а в чем LVM виноват если не секрет? :) Управлять чисто блочными устройствами менее практично и удобно же, особенно отталкиваясь от позиции ниже по удобству администрирования :)

тут 2 варианта работы: - сервер настраивают инженеры компании по своим внутренним практикам и предоставляют нам для настройки базы, тут работаем с тем, что есть. как правило, это in premise железо - сервер дают нам. в таком случае просто выделяем все диски под базу без всяких LVM, если места не хватит, то скорее всего надо будет ехать на другой сервер. как правило, это что-то вроде EC2 (и аналогов) на NVMe дисках против LVM-а ничего не имею, но в наших реалиях он не нужен.

Ок, понял, я просто думал есть что-то в LVM сверх ужасающее о чем я не знал))