PgBouncer vs Supavisor vs PgCat: hangi Postgres havuzlayıcı?

PgBouncer simge durumuna küçültür, Supavisor çok kiracılı ölçekte havuz oluşturur, PgCat ham havuzlamaya ağ işlevleri ekler. Her ne kadar sıklıkla aynı sayfalarda dönem dönem karşılaştırılsalar da, üçünden hiçbiri diğer ikisinin yerini doğrudan almaz.

Sütunlar sırasıyla: PgBouncer, Supavisor, PgCat. Her projenin resmi dosyalarına göre mimari özellikleri, dağıttığınız sürümde onaylanacak, ekosistem bu noktada hızla gelişiyor.

PgBouncer yalnızca tek bir şey yapar: Postgres bağlantılarını herhangi bir ek işlev olmadan havuzda tutar. Bu kasıtlı olarak dar kapsam, uzun ömürlülüğünü ve üretimdeki çoğu Postgres yığınında temel yapı taşı olarak benimsenmesini büyük ölçüde açıklamaktadır.

Three pooling modes are available. Session mode opens one server connection per client connection, the most permissive. Transaction mode reuses a server connection between several clients, released at each end of a transaction. Statement mode goes even further, and is rarely used in production. It is the transaction mode that brings the real pooling gain, but it imposes strict rules. Any session state (SETvariables, advisory locks, LISTEN/NOTIFY) does not survive beyond a transaction. We detail these rules and their pitfalls in our dedicated article on the transaction pooling mode of PgBouncer.

Geçmişte tek işlem olan PgBouncer örneği, varsayılan olarak tek bir CPU çekirdeği kullanır. Aynı bağlantı noktasının arkasında birden fazla örneğin çalıştırılması (SO_REUSEPORTaracılığıyla), bir başlangıç ​​tasarım özelliği değil, projenin daha yeni bir gelişimidir. Kimlik doğrulama tarafında PgBouncer, bir rolün parolasını dinamik olarak çözmek için her bağlantıda yürütülen bir SQL işlevi olan yapılandırılabilir bir auth_queryöğesini destekler. Bu mekanizma, her kullanıcıyı önceden listeleyen statik bir dosyaya bağlı kalmayı önler. Aurabase'in proje başına rolleri için kullandığı mekanizma tam olarak budur (bölüm 05).

Supavisor, PgBouncer'ın asla bu ölçekte çözmek için tasarlanmadığı bir sorunu ele alıyor. Bu, veritabanı başına bir havuzlayıcı örneği yerine, tek bir hizmetten çok sayıda farklı kiracı veritabanına hizmet vermeyi içerir. Elixir'de yazılan ve Erlang sanal makinesinde (BEAM) yürütülen proje, Supabase tarafından açık kaynak olarak kendi GitHub deposunda geliştirilmekte ve sürdürülmektedir.

Yerel çok kiracılı model gerçek yapısal farklılıktır. Klasik bir PgBouncer filosunun hedef taban başına bir süreç (veya bir dizi özel bağlantı) gerektirdiği durumlarda Supavisor farklı şekilde çalışır. Kiracıları bir HTTP yönetim arayüzü aracılığıyla dinamik olarak kaydeder ve gelen her bağlantıyı, hizmeti yeniden başlatmadan doğru veritabanına yönlendirir. Supabase, tam da bu nedenle kendi Bulut projelerini PgBouncer'dan Supavisor'a taşıdı. Her veritabanı için bir tane içeren klasik bir havuz kümesi, yüz binlerce projeyi barındıran çok kiracılı bir buluta ölçeklenmez.

Bu mimari tercihin belgelenmiş bir dezavantajı var. Gelişmiş vakalarda PgBouncer ile özellik benzerliğinin, projenin başlatılmasından sonra istikrara kavuşması zaman aldı. İki örnek: LISTEN/NOTIFYöğesinin belirli davranışları ve işlem modunda hazırlanan ifadelerin hassas yönetimi. Uygulamanızın bu belirli davranışlara bağlı olup olmadığını geçişten önce sürümünüzü kontrol edin.

PgCat açıkça Rust'ta yazılan PgBouncer'a alternatif olarak konumlandırılmıştır. Ne PgBouncer ne de Supavisor'un yerel olarak katıştırmadığı klasik havuzlamaya ağ işlevleri ekler. Özellikle üçü: bölüm anahtarına göre uygulama parçalama, okuma replikaları arasında yük dengeleme ve başarısız bir replikadan otomatik olarak yük devretme. Proje, bugün PostgresML tarafından devralınmadan ve sürdürülmeden önce Instacart'ta doğdu.

Somut olarak, PgCat normalde iki farklı katmanın üstleneceği rolü oynayabilir: bir bağlantı havuzlayıcısı ve çeşitli Postgres örnekleri arasında yönlendirme için bir uygulama proxy'si. Verilerini zaten elle parçalayan bir ekip, kodunu PgCat ile basitleştirebilir. Okumaları dahili olarak geliştirilen kopyalar arasında dağıtmaya yönelik mantık için de aynı şey geçerlidir: özel bir ağ katmanı doğrudan onun yerini alır.

Tam tersi bir uzlaşma da mevcut: PgCat, PgBouncer'dan çok daha küçük bir dokümantasyon ve üretim geri bildirimi ekosistemine sahip daha genç bir projedir. Parçalama ve yük devretme işlevlerini benimsemek aynı zamanda yalnızca havuzlama kapasitesine değil, bu belirli bileşenin olgunluğuna da bağlı olmayı kabul etmek anlamına gelir.

Aurabase deposu, PgBouncer'ı her ikisi de işlem modunda olmak üzere iki ayrı katmanda dağıtır. Paylaşılan filo için Helm grafiği, paylaşılan veri düzleminin (deploy/helm/aurabase/templates/infra/pgbouncer.yaml, görüntü edoburu/pgbouncer) önünde özel bir PgBouncer dağıtımını tanımlar. Tahsis edilmiş bir örnekteki kiracı için, hazırlayıcı, CloudNativePG tarafından yerel olarak yönetilen bir Pooler kaynağı oluşturur (deploy/cnpg/tenant-pooler.yaml, k8s_tenant.rstarafından oluşturulur). İkisi de Supavisor veya PgCat kullanmıyor. Kod, bu seçimden önce yapılan açık bir karşılaştırmayı belgelemiyor. Öte yandan, PgBouncer'ın yerel havuzlama tuğlası olduğu gerçeğiyle tutarlı olarak CloudNativePG ekosistemiyle derin ve halihazırda operasyonel bir entegrasyon gösterir.

Ancak her şey havuzlayıcıdan geçmiyor ve bu, kodun kendisinde belgelenen kasıtlı bir seçimdir. PostgREST, asla PgBouncer aracılığıyla değil, Postgres'e canlı olarak bağlı kalır. Helm grafiği yorumu bunun nedenini açıkça ortaya koyuyor: işlem havuzu oluşturma, pgrstkanalındaki bir LISTEN'ye bağlı olan şema yeniden yüklemesini bozacaktır. Bu mekanizma, istemciler arasındaki geri dönüştürülmüş sunucu bağlantılarıyla uyumlu değildir.aura-db yönetim havuzu (şema, DDL, oturum danışma kilitleri) de aynı temel nedenden dolayı doğrudan bağlantıda kalır. İşlem kapsamlı olmayan SET search_path ve oturum kilitleri, işlem modu havuzlayıcısında hayatta kalamaz.

# Veri düzlemi aura-db: PgBouncer aracılığıyla her şey işlem kapsamlıdır (SET LOCAL)
DATABASE_URL: postgresql://aura_authenticator:...@pgbouncer:5432/aura_db_master

# Havuz yöneticisi (DDL, iç gözlem): Postgres'te DIRECT, asla PgBouncer
# SET search_path YEREL olmayan + oturum kilitleri işlem havuzunu bozar
ADMIN_DATABASE_URL: postgresql://aura:...@postgres:5432/aura_db_master

Kimlik doğrulama, statik bir userlist.txt dosyası olmadan, bölüm 02: AUTH_QUERY: SELECT * FROM pgbouncer.user_lookup($1)'de açıklanan auth_query modelini izler. Bu, proje başına dinamik olarak oluşturulan rollerin (project_<uuid>_authenticator), her yeni proje için havuzlayıcıyı yeniden dağıtmadan PgBouncer aracılığıyla kimlik doğrulaması yapmasına olanak tanıyan şeydir.

Küçük ama açıklayıcı son bir ayrıntı: Helm grafiği varsayılan olarak edoburu/pgbouncer:v1.24.1-p1 pinini koyarken, yerel k3d tezgahı v1.25.2-p0kullanıyor. Bu mimari bir tercih değil, yalnızca iki ortam arasındaki sürüm senkronizasyonunun hafif bir eksikliği; bir kod incelemesinin bir blog gönderisinden daha hızlı yakaladığı türden bir ayrıntı. Giydirmek yerine olduğu gibi belgeliyoruz. Bu havuzlayıcının hizmet verdiği şema bölümlemenin ayrıntıları içinçok kiracılı RLS yalıtımıhakkındaki makalemize bakın.

Aşağıdaki durumlarda PgBouncer'ı seçin…

• Genel olarak CloudNativePG veya Kubernetes tarafından yönetilen Postgres kümesi
• En kanıtlanmış ve en iyi belgelenmiş bilardo oyuncusunu istiyorsunuz
• Havuz oluşturucu örneği başına bir hedef tabanı size uygundur

Aşağıdaki durumlarda Supavisor'u seçin:

• Aynı hizmetin arkasında yüzlerce veya binlerce üs
• Kiracıları yeniden dağıtım olmadan bir API aracılığıyla dinamik olarak kaydetmeniz gerekiyor
• Zaten Supabase ekosistemindesiniz veya ona bağlı olmaya isteklisiniz

Aşağıdaki durumlarda PgCat'i seçin:

• Uygulama paylaşımı halihazırda mevcut veya havuz oluşturucu düzeyinde planlanıyor
• Ayrı uygulama katmanı olmadan yük dengeleme ve yük devretme kopyası
• Daha genç bir projeyle rahat, PgBouncer'dan daha az belgelenmiş

Hangi havuzlayıcı seçilirse seçilsin, Postgres'in boyutunun yerini almaz. Havuz boyutu ve sunucu max_connections birbiri ardına değil, birlikte düşünülmelidir. Çok düşük bir max_connections önündeki cömert havuz, doygunluğu bir seviyeden diğerine kaydırır. ayarlama max_connections hakkındaki kılavuzumuz, havuzunuzun boyutunu ayarlamadan önce uygulanacak boyutlandırma formülünün ayrıntılarını verir.

PgBouncer, Supavisor ve PgCat aynı aracın üç versiyonunu değil, aynı problemin üç varyasyonunu çözüyor. Platformunuz zaten Kubernetes ve CloudNativePG'ye bağlı olduğunda veya yalnızca en fazla belgelenen havuzlayıcıyı istediğinizde PgBouncer en güvenli seçim olmaya devam ediyor. Supavisor, aynı hizmetten hizmet veren belirli sayıdaki üslerin ötesinde alakalı hale geliyor. Daha genç bir projenin olgunluğunu kabul etmeniz koşuluyla, ağ düzeyinde parçalamayı ve replika yük devretmeyi kaçırırsanız, PgCat yoldan sapmaya değer.

Aurabase kodu tarafsız değil tutarlı bir seçim gösterir: İşlem modunda PgBouncer, iki düzeyde, paylaşılan filo ve tahsis edilmiş kiracı başına CNPG havuzlayıcı. PostgREST ve şema yönetimi için belgelenmiş iki istisna kalmıştır. Bu projenin kağıt üzerinde değil uygulamalı olarak dağıldığını görmek istiyorsanız, Performans sayfamız ilgili ölçüm metodolojisini belgelemektedir.