Özel ve paylaşılan veritabanı: performans ve izolasyon

Microsoft'un çok kiracılı SaaS uygulamalarının mimarisine ilişkin resmi belgeleri, genellikle Silo (kiracı başına ayrılmış kaynaklar), Havuz (tamamen paylaşılan kaynaklar) ve Köprü (ikisinin bir karışımı, bazıları yalıtılmış kiracılar, diğerleri paylaşılan) olarak adlandırılan üç kiracılık modelini birbirinden ayırır. Bu üç model şema, veritabanı veya tüm küme düzeyinde doğrudan Postgres'e uygulanır.

Somut olarak, Postgres arka ucu için bu üç farklı mimari sağlar. The shared schema (a single base, a tenant_idcolumn, RLS policies which filter the rows) is the most common Pool model in multi-tenant guides: economical, but the border between two clients becomes an SQL expression evaluated table by table. The base per tenant on a shared cluster is an intermediate Bridge model: each tenant has its own Postgres base (a real CREATE DATABASEcommand), but several bases coexist on the same physical cluster, therefore sharing CPU, IO and connections. The cluster fully dedicated per tenant is the complete Silo model: completely isolated CPU, RAM and IO resources, generally reserved for tenants with high compliance or load issues.

Silo/Havuz/Köprü terminolojisi: resmi Microsoft belgeleri, çok kiracılı SaaS mimari modelleri (Azure Mimarlık Merkezi).

Paylaşılan bir kümede kiracı başına temel alınan ara model, "herkes için tek bir taban" ile "istemci başına bir sunucu" arasındaki seçimi ikili olarak sunan kılavuzlarda genellikle yoktur. Ancak bu, aşağıda ayrıntıları verilen Aurabase'in varsayılan olarak kullandığı yöntemdir.

Bu üç model arasındaki seçim, yalnızca bir BaaS sağlayıcısıyla değil, her çok kiracılı mimari kararında ortaya çıkar: yönetilen Postgres (RDS, Cloud SQL veya kendi kendine barındırılan bir örnek) üzerinde kendi SaaS arka ucunu oluşturan bir ekip, birkaç istemci aynı fiziksel örneğe yerleştirildiğinde aynı çekişme mekanizmalarının devreye girmesiyle tam olarak aynı tahkimi gerçekleştirir.

noisy neighbor (gürültülü komşu), aynı sunucudaki diğer kiracıların zararına olacak şekilde bir altyapının paylaşılan kaynaklarının orantısız bir kısmını tüketen bir kiracıdır. Terim genel buluttan gelir ancak doğrudan paylaşılan bir Postgres kümesi için geçerlidir: bir veritabanı, diğerlerinin performansını, onların verilerine hiç dokunmadan düşürebilir.

Üretimde en sık altı mekanizma ortaya çıkar:

• CPU çekişmesi: pahalı bir sorgu (indeks olmadan birleştirme, büyük sıralama), çekirdeğin kümedeki tüm etkin veritabanları arasında paylaştığı CPU döngülerini tüketir.
• IOPS çekişmesi: bir yedekleme, bir VACUUM FULL veya büyük miktarda içe aktarma, kümenin disk verimini doyurur, diğer veritabanlarına okuma ve yazma işlemlerini yavaşlatır.
• Bağlantı tükenmesi: max_connections taban başına değil, tüm küme düzeyindeki etkin bağlantı sayısını sınırlar. Çok fazla açılan bir taban başkalarının marjını azaltır.
• Autovacuum çekişmesi: autovacuum küme başına sınırlı sayıda çalışanla çalışır; Yazma hızı yüksek bir veritabanı, başka bir veritabanının tablolarının temizlenmesini geciktirebilir.
• Önbellek tahliyesi: shared_buffers tüm küme için tek bir bellektir; Büyük bir çalışma kümesine sahip bir veritabanı, daha küçük bir komşu veritabanının önbelleğe alınmış sayfalarını çıkarabilir.
• Paylaşılan bakım pencereleri: yedekleme, replika yük devretme veya büyük yükseltme, taban bazında değil, kümenin tamamı için geçerlidir.

Yapısal diyagram, ölçüm sonucu değil: bu iki topoloji için bugüne kadar yayınlanmış karşılaştırmalı performans rakamı yoktur.

Bağlantı bütçesi, gecikmeden önce bile genellikle üretimdeki en görünür belirtidir. Bu, max_connections ayarlama rehberimizin ve karşılaştırmamızın PgBouncer, Supavisor ve PgCatayrıntılı konusudur.

A transaction mode pooler (PgBouncer, Supavisor, PgCat) mitigates connection exhaustion, but does not remove CPU or IOPS contention: it reuses existing server connections, it does not add additional CPU cores or disk throughput to the cluster. Our article on transaction pooling mode details what this mode actually changes, and what it doesn't change.

Satır Düzeyinde Güvenlik farklı bir sorunu çözer: bir sorgunun başka bir kiracının satırlarını mantıksal düzeyde okumasını veya değiştirmesini engeller. Belirli bir kiracı için CPU döngüsü, bağlantı yuvası veya disk verimi ayırmaz.

İki kiracı mükemmel bir şekilde su geçirmez RLS politikalarına sahip olabilir ve aynı zamanda birbirlerini olumsuz etkileyebilir: Gürültülü komşu, erişim haklarıyla ilgili değil, fiziksel kaynaklarla ilgili bir sorundur. Bu ikisini karıştırmak, EPIRB devreye girdiğinde yanlış bir operasyonel güvenlik algısına yol açar.

Hazırlayıcı kodu (aura-provisioner), etkin bir Postgres projesi için, kodun Görev 12 olarak adlandırdığı bir sağlama birleştirmesinden tam olarak iki olası mimariyi belgelemektedir: FullyDedicated ve SharedClusterDedicated. Eski şema taneli modeller sağlama yolundan kaldırıldı.

enterprise düzeyi FullyDedicatedtetikler: bu tek proje için ayrılmış CNPG kümesinin tamamı. Diğer tüm düzeyler (ücretsiz, profesyonel, ekip) SharedClusterDedicated'ye yönlendirilir: proje organizasyonunun CNPG kümesinde tam teşekküllü bir Postgres project_<uuid> veritabanı. Bu nedenle paylaşılan bir şema değildir: standart bir planda bile veritabanınız ortak bir tablodaki diğer satırlar arasında değil, tam bir Postgres veritabanıdır. Paylaşılan, tabanın kendisi değil, kümedir (CPU, RAM, disk, bağlantılar).

Bir kuruluşun CNPG kümesi, ilk Postgres projesi sağlandığında ve hiçbir zaman başka bir kuruluştan gelen bir projeyi barındırmadığında oluşturulur; bu, kod düzeyinde kilitlenen bir tasarım seçeneğidir (org_cluster.rs, oluşturma sırasında kuruluşa göre Postgres öneri kilidi). Bu nedenle, paylaşılan Aurabase iskelesindeki olası tek gürültücü komşu, asla üçüncü taraf bir müşterinin değil, kendi kuruluşunuzun başka bir projesidir.

/// Organizasyonel bir kümenin nominal kapasitesi (proje tabanı sayısı).
/// Gözlemlenebilirlik eşiği: bunun ötesinde kuruluşu FullyDedicated'e yönlendirin.
/// FLEET_CLUSTER_CAPACITY aracılığıyla kontrol edilebilir (varsayılan 1000, sınırlı [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)
}

Aurabase tarafından yönetilen PostgreSQL küme mimarisi özellikleri.

Küme başına 1000 bazdan oluşan bu eşik, kesin bir sınır değildir: otomatik bir blok değil, FullyDedicated'ye geçiş önerisini tetikleyen bir gözlemlenebilirlik kriteridir. Artık herhangi bir yerleştirme kararına yön vermiyor; artık kuruluş başına yalnızca bir küme mümkün.

Her küme, ister özel ister filo, her iki topolojide de aktif bağlantılar üzerindeki baskının bir kısmını emen bir CNPG Havuzlayıcıyı (PgBouncer) açığa çıkarır. Bu havuzlayıcının kaynak çekişmesi için gerçekte neyi değiştirdiği aşağıda ayrıntılı olarak açıklanmıştır.

Paylaşılan bir kümenin CPU/RAM boyutu da kuruluşlar arasında tek tip değildir: tüm düzeylere uygulanan tek bir boyuttan değil, özel bir işlev (FleetSizing::from_org_plan, org_cluster.rsile doğrulanmıştır) aracılığıyla kuruluş düzeyinden türetilir. Ekip düzeyindeki bir kuruluş, kümesini serbest düzeydeki bir kuruluşla aynı şekilde boyutlandırmaz.

Bu iki mimari, üretimde kullanılan CNPG görüntüsünün Docker dosyasında doğrulanan sürüm 17 değil, PostgreSQL 16 üzerinde çalışır. Bu sürüm seçiminin, Postgres 16 vs 17 vs 18 karşılaştırmamızdaayrıntılı olarak açıklanan kendi ayarlama sonuçları vardır.

Belgelenmiş fiziksel izolasyona ilişkin sözleşme yükümlülüğüne tabi projeler için, DPA ve uyumluluk sayfalarımız her bir düzeyin neleri kapsadığını ayrıntılı olarak gösterir.

The downside of the base-by-tenant model, highlighted by several schema migration management tools like Bytebase, is operational rather than technical: each migration must be applied and verified on each base, one by one, even when they coexist on the same cluster. A fully dedicated cluster does not eliminate this cost, it even adds it: one migration per cluster to monitor independently, rather than just one.

CodeOpinion gibi çok kiracılı yazılım mimarisinde uzmanlaşmış kaynaklar, düzenli olarak bu ara yaklaşımı (paylaşılan altyapı üzerinde kiracı bazında), iki uç arasındaki ikili bir seçim yerine, paylaşılan şema ile tamamen tahsis edilmiş küme arasında makul bir uzlaşma olarak sunar.

Going from shared to dedicated does not require rewriting a schema or changing engines: in both cases, it is Postgres, with the same pg_dump / pg_restore chain as that described in our Supabase to Aurabase migration guide. Seviyeyi değiştirmek, uygulamanın yeniden yazılması değil, bir geçiş işlemi olarak kalır.

Özel taban ve paylaşılan taban, veri güvenliği açısından çakışmaz: her iki model de bir kiracıyı diğerinden mantıksal düzeyde doğru şekilde izole edebilir. Fiziksel kaynaklar (CPU, IOPS, bağlantılar, önbellek, bakım pencereleri) konusunda birbirlerine karşı çıkıyorlar. Kötü yazılmış bir RLS politikası değil, gürültülü bir komşuyu tanımlayan bu plandır.

Provizyon kodunda doğrulanan Aurabase modeli, varsayılan olarak bir ara uzlaşmayı korur: proje başına özel bir Postgres veritabanı, paylaşılan bir küme üzerinde, ancak kesinlikle tek bir kuruluş için ayrılmış, tamamen ayrılmış bir küme iş düzeyi için ayrılmıştır. Doğru seçim, adanmışlığın her zaman en iyi seçenek olacağı refleksine değil, gerçek kısıtlamalarınıza bağlıdır.