Ответы пользователя по тегу Проектирование программного обеспечения
  • У кого-нибудь есть опыт подобной архитектуры с Postgres?

    @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(


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


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