Dedykowana a współdzielona baza danych: wydajność i izolacja

Oficjalna dokumentacja firmy Microsoft dotycząca architektury aplikacji SaaS z wieloma dzierżawcami wyróżnia trzy modele dzierżawy, ogólnie zwane Silo (dedykowane zasoby na dzierżawcę), Pula (w pełni współdzielone zasoby) i Bridge (połączenie tych dwóch, niektórzy izolowani najemcy, inni współdzieleni). Te trzy modele dotyczą bezpośrednio Postgres, na poziomie schematu, bazy danych lub całego klastra.

Konkretnie, w przypadku backendu Postgres daje to trzy różne architektury. Schemat współdzielony (pojedyncza baza, kolumna tenant_id, zasady RLS filtrujące wiersze) to najpopularniejszy model puli w przewodnikach z wieloma dzierżawcami: ekonomiczny, ale granica między dwoma klientami staje się wyrażeniem SQL ocenianym tabela po tabeli. Baza na dzierżawcę we współdzielonym klastrze to pośredni model mostu: każdy dzierżawca ma własną bazę Postgres (prawdziwe polecenie CREATE DATABASE), ale kilka baz współistnieje w tym samym klastrze fizycznym, w związku z czym współdzieli procesor, we/wy i połączenia. Klaster w pełni dedykowany dla każdego dzierżawcy to kompletny model silosu: całkowicie izolowane zasoby procesora, pamięci RAM i we/wy, zwykle zarezerwowane dla dzierżawców z dużymi problemami związanymi ze zgodnością lub obciążeniem.

Terminologia silosu / puli / mostu: oficjalna dokumentacja Microsoft, wzorce architektury SaaS z wieloma dzierżawcami (Azure Architecture Center).

Modelu pośredniego, opartego na najemcy we współdzielonym klastrze, często nie ma w przewodnikach, które przedstawiają binarny wybór pomiędzy „jedną bazą dla wszystkich” a „jednym serwerem na klienta”. Jest to jednak ten, którego domyślnie używa Aurabase, co opisano poniżej.

Wybór między tymi trzema modelami pojawia się przy każdej decyzji dotyczącej architektury z wieloma dzierżawcami, nie tylko w przypadku dostawcy BaaS: zespół, który buduje własny backend SaaS na zarządzanym Postgresie (RDS, Cloud SQL lub instancja hostowana samodzielnie) dokonuje dokładnie tego samego arbitrażu, z tymi samymi mechanizmami rywalizacji, gdy kilku klientów jest umieszczonych w tej samej instancji fizycznej.

noisy neighbor (hałaśliwy sąsiad) to dzierżawca, który zużywa nieproporcjonalną część współdzielonych zasobów infrastruktury, ze szkodą dla innych dzierżawców na tym samym serwerze. Termin pochodzi z chmury publicznej, ale odnosi się bezpośrednio do współdzielonego klastra Postgres: jedna baza danych może obniżyć wydajność innych, nie dotykając w ogóle ich danych.

W produkcji najczęściej pojawia się sześć mechanizmów:

• Rywalizacja o procesor: drogie zapytanie (łączenie bez indeksu, sortowanie masowe) zużywa cykle procesora, które jądro współdzieli pomiędzy wszystkimi aktywnymi bazami danych w klastrze.
• Rywalizacja IOPS: kopia zapasowa, VACUUM FULL lub masowy import obciążają przepustowość dysku klastra, spowalniając odczyt i zapis w innych bazach danych.
• Wyczerpanie połączeń: max_connections ogranicza liczbę aktywnych połączeń na poziomie całego klastra, a nie na bazę. Baza, która otwiera się zbyt mocno, zmniejsza margines innych.
• Konflikt dotyczący automatycznej próżni: automatyczna próżnia działa z ograniczoną liczbą pracowników na klaster; baza danych o dużej szybkości zapisu może opóźnić czyszczenie tabel innej bazy danych.
• Eksmisja pamięci podręcznej: shared_buffers to pojedyncza pamięć dla całego klastra; baza danych z dużym zestawem roboczym może wykluczyć strony z pamięci podręcznej mniejszej sąsiedniej bazy danych.
• Wspólne okna konserwacji: kopia zapasowa, przełączanie awaryjne repliki lub większa aktualizacja dotyczą całego klastra, a nie poszczególnych baz.

Schemat strukturalny, a nie wynik pomiaru: dotychczas nie opublikowano żadnych porównawczych danych dotyczących wydajności dla tych dwóch topologii.

Budżet połączeń jest często najbardziej widocznym objawem w środowisku produkcyjnym, nawet przed opóźnieniami. Jest to szczegółowy temat naszego przewodnika dostrajania max_connections i naszego porównania PgBouncer, Supavisor i PgCat.

Pula w trybie transakcyjnym (PgBouncer, Supavisor, PgCat) łagodzi wyczerpanie połączeń, ale nie usuwa rywalizacji o procesor lub IOPS: ponownie wykorzystuje istniejące połączenia z serwerem, nie dodaje dodatkowych rdzeni procesora ani przepustowości dysku do klastra. Nasz artykuł na temat trybu łączenia transakcji szczegółowo opisuje, co ten tryb faktycznie zmienia, a czego nie zmienia.

Zabezpieczenia na poziomie wiersza rozwiązują inny problem: zapobiegają czytaniu lub modyfikowaniu przez zapytanie wierszy innego dzierżawcy na poziomie logicznym. Nie rezerwuje żadnego cyklu procesora, żadnego gniazda połączeniowego ani przepustowości dysku dla konkretnego dzierżawcy.

Dwóch najemców może mieć doskonale szczelne zasady RLS i jednocześnie degradować się nawzajem: hałaśliwy sąsiad to problem zasobów fizycznych, a nie praw dostępu. Mylenie tych dwóch kwestii prowadzi do fałszywego poczucia bezpieczeństwa operacyjnego po uruchomieniu EPIRB.

Kod dostawcy usług (aura-provisioner) dokumentuje dokładnie dwie możliwe architektury aktywnego projektu Postgres na podstawie konsolidacji udostępniania, którą kod określa jako Zadanie 12: FullyDedicated i SharedClusterDedicated. Starsze modele oparte na schemacie zostały usunięte ze ścieżki udostępniania.

Poziom enterprise wyzwala FullyDedicated: cały klaster CNPG zarezerwowany dla tego pojedynczego projektu. Wszystkie pozostałe poziomy (bezpłatny, profesjonalny, zespołowy) prowadzą do SharedClusterDedicated: pełnoprawnej bazy danych Postgres project_<uuid> w klastrze CNPG organizacji projektowej. Dlatego nie jest to schemat współdzielony: nawet w przypadku planu standardowego Twoja baza danych jest kompletną bazą danych Postgres, a nie jedną linią między innymi we wspólnej tabeli. Udostępniany jest klaster (procesor, pamięć RAM, dysk, połączenia), a nie sama baza.

Klaster CNPG organizacji jest tworzony podczas udostępniania pierwszego projektu Postgres i nigdy nie obsługuje projektu z innej organizacji, a wybór projektu jest zablokowany na poziomie kodu (org_cluster.rs, blokada doradcza Postgres według organizacji podczas tworzenia). Jedynym możliwym hałaśliwym sąsiadem na współdzielonym lądowaniu Aurabase jest zatem kolejny projekt Twojej własnej organizacji, a nie klienta strony trzeciej.

/// Nominalna pojemność (liczba baz projektowych) klastra organizacyjnego.
/// Próg obserwowalności: powyżej tego skieruj organizację w stronę Fully Dedicated.
/// Sterowanie poprzez FLEET_CLUSTER_CAPACITY (domyślnie 1000, ograniczone [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)
}

Specyfikacje architektury klastra zarządzanego przez Aurabase PostgreSQL.

Ten próg 1000 baz na klaster nie jest sztywnym limitem: jest to punkt odniesienia obserwowalności, który wyzwala zalecenie migracji do FullyDedicated, a nie automatycznego bloku. Nie wpływa to już na decyzje o rozmieszczeniu, teraz na organizację można utworzyć tylko jeden klaster.

Każdy klaster, dedykowany lub flotowy, udostępnia CNPG Pooler (PgBouncer), który pochłania część obciążenia aktywnych połączeń, w obu topologiach. Poniżej szczegółowo opisano, co faktycznie zmienia ten Pooler w związku z rywalizacją o zasoby.

Rozmiar procesora/RAM we współdzielonym klastrze również nie jest jednolity pomiędzy organizacjami: wywodzi się z poziomu organizacji za pośrednictwem dedykowanej funkcji (FleetSizing::from_org_plan, zweryfikowanej w org_cluster.rs), a nie z jednego rozmiaru stosowanego na wszystkich poziomach. Organizacja na poziomie zespołu nie określa wielkości swojego klastra w taki sam sposób, jak organizacja na poziomie swobodnym.

Te dwie architektury działają na PostgreSQL 16, a nie na wersji 17, zweryfikowanej w pliku Dockerfile obrazu CNPG używanego w produkcji. Ten wybór wersji ma swoje własne implikacje związane z dostrojeniem, szczegółowo opisane w naszym porównaniu Postgres 16 vs 17 vs 18.

W przypadku projektów objętych umownym zobowiązaniem dotyczącym udokumentowanej izolacji fizycznej, nasze strony dotyczące zgodności DPA i szczegółowo opisują każdy poziom.

Wadą modelu „base-by-tenant” podkreślaną przez kilka narzędzi do zarządzania migracją schematów, takich jak Bytebase, jest raczej charakter operacyjny niż techniczny: każda migracja musi zostać zastosowana i zweryfikowana na każdej bazie, jedna po drugiej, nawet jeśli współistnieją w tym samym klastrze. W pełni dedykowany klaster nie eliminuje tego kosztu, wręcz go dodaje: jedna migracja na klaster w celu niezależnego monitorowania, a nie tylko jedna.

Zasoby specjalizujące się w architekturze oprogramowania z wieloma dzierżawcami, takie jak CodeOpinion, regularnie przedstawiają to pośrednie podejście (w przeliczeniu na dzierżawcę współdzielonej infrastruktury) jako rozsądny kompromis między współdzielonym schematem a w pełni dedykowanym klastrem, a nie binarny wybór między dwiema skrajnościami.

Przejście z wersji współdzielonej na dedykowaną nie wymaga przepisywania schematu ani zmiany silników: w obu przypadkach jest to Postgres z tym samym łańcuchem pg_dump / pg_restore, jak opisano w naszym przewodniku migracji Supabase do Aurabase. Zmiana poziomu pozostaje operacją przełączania, a nie przepisywaniem aplikacji.

Baza dedykowana i baza współdzielona nie kolidują z bezpieczeństwem danych: oba modele mogą poprawnie odizolować jednego najemcę od drugiego na poziomie logicznym. Przeciwstawiają się sobie pod względem zasobów fizycznych (procesor, IOPS, połączenia, pamięć podręczna, okna konserwacyjne). To właśnie ten plan definiuje hałaśliwego sąsiada, a nie źle napisaną politykę RLS.

Model Aurabase, zweryfikowany w kodzie dostawcy, domyślnie zachowuje kompromis pośredni: dedykowaną bazę danych Postgres na projekt, we współdzielonym klastrze, ale ściśle zarezerwowaną dla jednej organizacji, z w pełni dedykowanym klastrem zarezerwowanym dla poziomu biznesowego. Właściwy wybór zależy od Twoich rzeczywistych ograniczeń, a nie od odruchu, w którym dedykowana zawsze byłaby najlepszą opcją.