Выделенная и общая база данных: производительность и изоляция

В официальной документации Microsoft по архитектуре мультитенантных приложений SaaS различаются три модели аренды, обычно называемые «бункером» (выделенные ресурсы для каждого клиента), «пулом» (полностью общие ресурсы) и «мостом» (смесь двух моделей: некоторые изолированные арендаторы, другие общие). Эти три модели применимы непосредственно к Postgres на уровне схемы, базы данных или всего кластера.

Конкретно, для серверной части Postgres это дает три различные архитектуры. Общая схема (одна база, столбец tenant_id, политики RLS, фильтрующие строки) — это наиболее распространенная модель пула в многопользовательских руководствах: экономичная, но граница между двумя клиентами становится выражением SQL, вычисляемым таблица за таблицей. База на одного тенанта в общем кластере — это промежуточная модель моста: каждый тенант имеет свою собственную базу Postgres (настоящая команда CREATE DATABASE), но несколько баз сосуществуют в одном физическом кластере, поэтому совместно используют ЦП, операции ввода-вывода и соединения. Кластер , полностью выделенный для каждого клиента, представляет собой полную модель изолированного хранилища: полностью изолированные ресурсы ЦП, ОЗУ и ввода-вывода, обычно зарезервированные для клиентов с высокими требованиями к соблюдению требований или проблемами с нагрузкой.

Терминология Silo/Pool/Bridge: официальная документация Microsoft, шаблоны мультитенантной архитектуры SaaS (Azure Architecture Center).

Промежуточная модель, основанная на одном клиенте в общем кластере, часто отсутствует в руководствах, которые представляют выбор как бинарный между «одной базой для всех» и «одним сервером на каждого клиента». Однако именно его Aurabase использует по умолчанию, как описано ниже.

Выбор между этими тремя моделями возникает при каждом решении по мультитенантной архитектуре, а не только при выборе поставщика BaaS: команда, которая создает свой собственный бэкэнд SaaS на управляемом Postgres (RDS, Cloud SQL или самостоятельный экземпляр), проводит точно такой же арбитраж, используя одни и те же механизмы конкуренции, когда несколько клиентов размещаются на одном физическом экземпляре.

noisy neighbor (шумный сосед) — это арендатор, который потребляет непропорционально большую долю общих ресурсов инфраструктуры в ущерб другим арендаторам на том же сервере. Этот термин пришел из публичного облака, но применим непосредственно к общему кластеру Postgres: одна база данных может снижать производительность других, даже не затрагивая их данные.

В производстве чаще всего встречаются шесть механизмов:

• Конфликт ЦП: дорогостоящий запрос (объединение без индекса, массовая сортировка) потребляет циклы ЦП, которые ядро ​​распределяет между всеми активными базами данных в кластере.
• Конфликт IOPS: резервное копирование, VACUUM FULL или массовый импорт перегружают пропускную способность диска кластера, замедляя операции чтения и записи в другие базы данных.
• Исчерпание соединений: max_connections ограничивает количество активных соединений на уровне всего кластера, а не на базе. База, которая открывается слишком сильно, снижает маржу других.
• Конфликт при автоочистке: автоочистка выполняется с ограниченным количеством рабочих процессов на кластер; база данных с высокой скоростью записи может задержать очистку таблиц другой базы данных.
• Вытеснение кэша: shared_buffers — это единая память для всего кластера; база данных с большим рабочим набором может вытеснить кэшированные страницы соседней базы данных меньшего размера.
• Общие окна обслуживания: резервное копирование, отработка отказа реплики или крупное обновление применяются ко всему кластеру, а не отдельно для каждой базы.

Структурная схема, а не результат измерений: сравнительных показателей производительности для этих двух топологий на сегодняшний день не опубликовано.

Бюджет соединения часто является наиболее заметным признаком в производстве, даже до задержки. Это подробная тема нашего руководства по настройке max_connections и нашего сравнения PgBouncer, Supavisor и PgCat.

Создатель пула режима транзакций (PgBouncer, Supavisor, PgCat) снижает нагрузку на соединения, но не устраняет конфликты ЦП или операций ввода-вывода в секунду: он повторно использует существующие подключения к серверу, не добавляет в кластер дополнительные ядра ЦП или пропускную способность диска. В нашей статье о режиме пула транзакций подробно описано, что на самом деле меняет этот режим, а что нет.

Безопасность на уровне строк решает другую проблему: она не позволяет запросу читать или изменять строки другого арендатора на логическом уровне. Он не резервирует ни цикл процессора, ни слот подключения, ни пропускную способность диска для конкретного арендатора.

Два арендатора могут иметь совершенно надежную политику RLS и одновременно ухудшать работу друг друга: шумный сосед — это проблема физических ресурсов, а не прав доступа. Смешение этих двух факторов приводит к ложному ощущению эксплуатационной безопасности после установки АРБ.

Код поставщика (aura-provisioner) документирует ровно две возможные архитектуры для активного проекта Postgres из консолидации обеспечения, которую код называет задачей 12: FullyDedicated и SharedClusterDedicated. Устаревшие модели с детализацией схемы были удалены из пути подготовки.

Уровень enterprise запускает FullyDedicated: целый кластер CNPG, зарезервированный для этого отдельного проекта. Все остальные уровни (бесплатный, профессиональный, командный) направляются к SharedClusterDedicated: полноценной базе данных Postgres project_<uuid> в кластере CNPG проектной организации. Следовательно, это не общая схема: даже в стандартном плане ваша база данных представляет собой полную базу данных Postgres, а не одну строку среди других в общей таблице. Совместно используется кластер (ЦП, ОЗУ, диск, соединения), а не сама база.

Кластер CNPG организации создается при подготовке ее первого проекта Postgres и никогда не содержит проектов из другой организации. Выбор конструкции блокируется на уровне кода (org_cluster.rs, рекомендательная блокировка Postgres организацией при создании). Таким образом, единственным возможным шумным соседом на общей площадке Aurabase является еще один проект вашей собственной организации, а не стороннего клиента.

/// Номинальная мощность (количество проектных баз) организационного кластера.
/// Порог наблюдаемости: помимо этого направьте организацию в сторону FullyDedicated.
/// Управляется через FLEET_CLUSTER_CAPACITY (по умолчанию 1000, ограничено [1, 1_000_000]).
pub fn fleet_cluster_capacity() -> i32 {
    std::env::var("FLEET_CLUSTER_CAPACITY")
        .ok()
        .and_then(|v| v.parse::<i32>().ok())
        .filter(|n| (1..=1_000_000).contains(n))
        .unwrap_or(1000)
}

Спецификации архитектуры кластера PostgreSQL под управлением Aurabase.

Этот порог в 1000 баз на кластер не является жестким пределом: это тест наблюдаемости, который вызывает рекомендацию перейти на FullyDedicated, а не автоматическую блокировку. Он больше не влияет на принятие решений о размещении, теперь для каждой организации возможен только один кластер.

Каждый кластер, выделенный или групповой, предоставляет CNPG Pooler (PgBouncer), который поглощает часть нагрузки на активные соединения в обеих топологиях. Что на самом деле меняет этот пулер для борьбы за ресурсы, подробно описано ниже.

Размер ЦП/ОЗУ общего кластера также неодинаков в разных организациях: он определяется уровнем организации с помощью специальной функции (FleetSizing::from_org_plan, проверено в org_cluster.rs), а не единого размера, применяемого ко всем уровням. Организация на уровне команды не определяет размер своего кластера так же, как организация на свободном уровне.

Эти две архитектуры работают на PostgreSQL 16, а не на версии 17, что проверено в Dockerfile образа CNPG, используемого в рабочей среде. Этот выбор версии имеет свои собственные последствия настройки, подробно описанные в нашем сравнении Postgres 16, 17 и 18.

Для проектов, в которых предусмотрены договорные обязательства по документированной физической изоляции, на страницах DPA и подробно описано, что охватывает каждый уровень.

Недостаток модели «база-за-тенантом», подчеркнутый несколькими инструментами управления миграцией схем, такими как Bytebase, скорее операционный, чем технический: каждую миграцию необходимо применять и проверять на каждой базе, одну за другой, даже если они сосуществуют в одном кластере. Полностью выделенный кластер не устраняет эти затраты, а даже добавляет их: одна миграция на кластер для независимого мониторинга, а не только одна.

Ресурсы, специализирующиеся на мультитенантной архитектуре программного обеспечения, такие как CodeOpinion, регулярно представляют этот промежуточный подход (на основе каждого арендатора в общей инфраструктуре) как разумный компромисс между общей схемой и полностью выделенным кластером, а не бинарный выбор между двумя крайностями.

Переход от общего к выделенному не требует переписывания схемы или смены движков: в обоих случаях это Postgres с той же цепочкой pg_dump/pg_restore, что описана в нашем руководстве по миграции Supabase на Aurabase. Изменение уровня остается операцией переключения, а не перезаписью приложения.

Выделенная база и общая база не конфликтуют по безопасности данных: обе модели могут корректно изолировать одного арендатора от другого на логическом уровне. Они противостоят друг другу по физическим ресурсам (ЦП, IOPS, соединения, кэш, окна обслуживания). Именно этот план определяет шумного соседа, а не плохо написанную политику RLS.

Модель Aurabase, проверенная в коде поставщика, по умолчанию сохраняет промежуточный компромисс: выделенная база данных Postgres для каждого проекта в общем кластере, но строго зарезервированная для одной организации, с полностью выделенным кластером, зарезервированным для бизнес-уровня. Правильный выбор зависит от ваших реальных ограничений, а не от рефлекса, где преданность делу всегда будет лучшим вариантом.