У кого-нибудь есть опыт подобной архитектуры с Postgres?

Речь идет о специфической CRM-системе, которая должна функционировать в качестве SaaS, но с возможностью "горячего" перемещения инстанса на сервер клиента.

Я предполагаю, что для каждого клиента должна создаваться отдельная база данных в кластере Постгреса.

Есть сведения, что один кластер может держать 10 тыс БД. Это число может быть увеличено за счет плоского масштабирования (увеличения числа серверов).

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

С точки зрения разработки все новые БД будут создаваться из шаблона (шаблон будет содержать 20-25 таблиц и больше двух сотен процедур). Понятно, что при внесении изменений в структуру данных или бизнес-логику нужно будет обновлять все базы данных, что как минимум потребует хорошего покрытия тестами (да, часть таблиц с редко изменяемыми справочниками вроде списка городов можно сделать внешними).

Это выглядит решаемым, но как будут обстоять дела с конкурентным доступом к разным БД на одном сервере? С какими еще проблемами придется столкнуться при администрировании? То есть насколько вообще жизнеспособна такая архитектура по сравнению с традиционной, когда данные разных аккаунтов хранятся в секционируемых таблицах и разделяются по ключу?
  • Вопрос задан
  • 182 просмотра
Решения вопроса 1
@Xtensive
Есть сведения, что один кластер может держать 10 тыс БД.


На ext4 лимит 60к субдиректорий. Теоретический максимум для ПГ - 4 миллиарда баз в одном кластере
https://www.postgresql.org/docs/current/limits.html
Вопрос переносится в плоскость трудности обслуживания и развёртывания дополнительных ресурсов. Управлением опять же такой "махиной".

Это выглядит решаемым, но как будут обстоять дела с конкурентным доступом к разным БД на одном сервере?

Дела с конкурентным доступом будут посредственны. Постгрес на каждое клиентское соединение будет плодить один серверный процесс. Потребуется очень детальное конфигурирование сервера СУБД по памяти чтобы work_mem и прочие не преводили к OOM падению всего кластера.

Приблизительно: сервер 56 тредов, 512ГБ памяти может выдержать около 2-4 тысячи клиентов со смешанной OLTP нагрузкой, на одной БД. И тут на само деле не сильно принципиально одна или несколько БД, поскольку всё упирается в диски/хранилище и доступную пропускную способность.

Количество соединений можно +/- решить пулером соединений (PgBouncer, Odyssey или другие)

С какими еще проблемами придется столкнуться при администрировании?

  • Бэкапы. Всегда. Особенно инкрементальные.
  • Количество пользователей, и прав к ним.
  • Количество сервисных процессов ПГ
  • Настройка всего этого дела и переконфигурирование по необходимости
  • Апгрейд и патчинг самого ПГ (пока нет и не предвидется подъёма версии СУБД на работающем кластере)
  • Первая же ошибка записи WAL или скрытый коррапт данных убьёт весь кластер 8(


То есть насколько вообще жизнеспособна такая архитектура по сравнению с традиционной, когда данные разных аккаунтов хранятся в секционируемых таблицах и разделяются по ключу?


Возможно стоит комбинировать подход - несколько серверов СУБД, несколько БД для групп клиентов, группы и клиенты разбиты по схемам данных внутри одного экземпляра БД.
Как минимум обслуживание отдельных кластеров не вызовет даунтайм для всех клиентов.
А наиболее активные клиенты и с большей нагрузкой/потребностями могут быть перенесены в отдельный кластер с репликациями и горячим/тёплым резервированием.
Ответ написан
Пригласить эксперта
Ответы на вопрос 1
ky0
@ky0
Миллиардер, филантроп, патологический лгун
для каждого клиента должна создаваться отдельная база данных в кластере Постгреса

Копирование отдельных таблиц или баз данных (говоря о планируемом вами "горячем переезде") возможна только при логической репликации. Мне это видится излишним усложнением по сравнению с вариантом "каждому клиенту свою СУБД + стандартная потоковая репликация в случае необходимости", при котором нет огромных кластеров, отказ которых повлияет на существенное число клиентов.
Ответ написан
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Войти через центр авторизации
Похожие вопросы