PgDog’un Gerçek Postgres Uygulama Mimarilerindeki Yeri

PostgreSQL yönlendirmesi, çoğu ekibin kabul ettiğinden çok daha erken bir uygulama sorunu haline gelir. Veritabanı hâlâ veritabanıdır, ancak çoğaltıcılar, havuzlama, hata durumu veya shard’lama olasılığı eklediğiniz an, uygulamanız tek bir sunucuya bağlı kalmayı bırakır ve trafik politikasına bağımlı hale gelir. Bu politika, okumaların nereye gideceğini, işlemler içinde olanları, düşüş modunun nasıl çalıştığını ve kuyruk işçilerinin HTTP istekleriyle aynı şekilde davranıp davranmayacağını belirler.

İşte PgDog için gerçek mesele budur. Bu yalnızca daha güzel bir ara yüzü olan bir PostgreSQL aracı değildir. Bazı ekiplerin ORM yapılandırması içinde yönlendirmenin sonsuza kadar gizli kalacağı efsanesini aştığının bir işareti.

Benim görüşüm net: PgDog, yönlendirme politikasının altyapı haline gelmesini istediğinizde ilginçtir, çerçeve davranışı yerine. Eğer genellikle bağlantı havuzlamasına ihtiyacınız var ise PgBouncer ile kalın. Eğer okunma, çoğaltıcılar, hata durumu ve tutarlılık kuralları Laravel hizmetlerine, Node kayıtlarına, işçilere ve scriptlere sızıyorsa, daha akıllı bir yönlendirme katmanı, mimari anlamda pek çok şeyin anlamlı hale gelmeye başladığını gösterir.

PostgreSQL Yönlendirmesi Genellikle Gizli Teknik Borçtur

Pek çok sistem, veritabanı ölçeklendirmesi için yanlış zihinsel modele başvurur. Takımlar, PostgreSQL’de bir verimlilik sorununu çözdüklerini düşünürken, uygulamada koordinasyon sorunları yaratıyorlar.

İlk belirti kolayca tanınır: çok fazla bağlantı. PHP-FPM işçileri artar, kuyruk tüketicileri genişler, arka plan işleri kısa ömürlü oturumlar açar ve PostgreSQL, sorgu çalıştırmak yerine bağlantı değişiminin kaynaklarını boşa harcamaya başlar. İşte o anda insanlar havuzlama ekler ve bir hafta boyunca akıllı hissettiklerini düşünürler.

İkinci belirti daha tehlikelidir: şimdi bir ana, bir veya daha fazla çoğaltıcı var ve “okumalar buraya, yazmalar oraya” gibi kaba bir kural uygulanmaya başlanır. Uygulama bu kuralı taşımaya başlar. Bazen veritabanı soyutlama katmanında yaşar. Bazen özel repository koduna sızar. Bazen de “bu uç nokta her zaman birincil olmalı çünkü çoğaltıcı checkout sonrası geride kalıyor.” gibi kabile bilgisi haline gelir.

İşte burada mimari kaymalar başlar. HTTP uygulamanız güvenli bir okuma yönlendirmesini bilirken, kuyruk işçiniz bilmeyebilir. Raporlama işiniz uygulama konteynerini tamamen atlayabilir ve doğrudan bağlantı kurabilir. Göç scriptleriniz aynı kuralları göz ardı edebilir. Sonuç, tek bir veritabanı mimarisi değil, aynı marka adıyla giyinmiş birkaç tutarsız mimaridir.

Bu yüzden yönlendirmenin önemi, duyulduğundan çok daha fazla. Uygulama topolojiyi fazla bildiğinde, her çalışma zamanı, davranışın potansiyel bir ayrım noktası haline gelir.

Daha temiz bir zihinsel model şudur:

• uygulama iş taleplerini ifade etmeli
• altyapı topoloji taleplerini yönlendirmeli
• ikisi arasındaki sınır net kalmalı

Bu sınır, bir proxy veya yönlendirme katmanının resmi hale getirmeye çalıştığı tam yerdir.

Yerel PostgreSQL İstemcilerinin Size Neleri Verdiği ve Neleri Veremediği

Herhangi bir proxy eklemeden önce, resmi PostgreSQL yığının zaten neler yapabileceğine dürüst olmakta fayda var.

libpq bağlantı katmanı birden fazla host, target_session_attrs ve load_balance_hosts desteklemektedir; PostgreSQL belgelerinde, istemcilerin birincili seçebileceği, bir bekleme sunucusunu tercih edebileceği veya bağlantı kurulumu sırasında host seçimlerini rastgele yapabileceği açıklanmaktadır: libpq bağlantı parametreleri. Bu yararlıdır ve pek çok ekip bunu yeterince kullanmamaktadır.

Bağlantı kurma konusundaki dayanıklılığınız için yalnızca bu istemci özellikleriyle beklediğinizden daha ileriye gidebilirsiniz:

host=db-primary,db-replica-1,db-replica-2
port=5432,5432,5432
target_session_attrs=read-write
load_balance_hosts=random
connect_timeout=2

Bu tür bir kurulum, bazı önemli şeyleri simplifiye eder:

• birden fazla host listelendiğinde yazılabilir bir düğüm seçmek
• belirli yalnızca okuma istemcileri için bekleme sunucularını tercih etmek
• hardcoding tek bir IP ile failover sağlamak
• DNS hilelerine dayanımı azaltmak

Ancak burada bir sınır vardır: yerel istemci host seçimi bağlantı zamanında gerçekleşir, sorgu zamanında değil. Bir istemci bağlandığında, sonraki her sorgu o arka planda kalır, bağlantı düşene veya geri dönene kadar.

Bu, istemci yerel özelliklerin çoğu büyüyen uygulamaların karşılaştığı gerçek yönlendirme sorunlarını çözmediği anlamına gelir:

• bir son nokta arkasında okumaları ve yazıları ayırmak
• işçiler, web istekleri ve scriptlerin aynı kuralları izlemesini sağlamak
• lock’lu okuma veya yazma CTE’leri gibi sorgu düzeyindeki uç durumları ele almak
• failover ve çoğaltıcı trafik politikasını merkezileştirmek
• uygulama bağlantı mantığını yeniden yazmadan shard’lama yolunda bir adım atmak

Yani soru, PostgreSQL istemcilerinin failover bilincine sahip bağlantılar yapıp yapamayacağı değil. Soru, ekibinizin sorguya duyarlı bir yönlendirme politikası ihtiyacı olup olmadığıdır.

Eğer cevap hayır ise, bir proxy eklemeyin. Eğer cevap evet ise, ORM’in tüm bunları temiz bir şekilde absorbe edebileceğini varsaymak, kötü bir mimari doğurur.

PgDog Gerçekten Nereye Oturuyor

PgDog, bir PostgreSQL bağlantı havuzlayıcısı, yük dengeleyici ve shard’lama proxy’si olarak kendini konumlandırır. İlginç olan, bu etiket değil. İlginç olan, yük dengeleyicisinin PostgreSQL sorgularını anlaması yoluyla çalışmasıdır, yalnızca bir arka planda bir kez seçim yapıp körce tünellemekten ziyade.

Resmi yük dengeleyici belgelerine göre, PgDog gelen SQL’i inceleyebilir, düz SELECT trafiğini çoğaltıcılara gönderebilir, yazmaları birinciliyere yönlendirebilir ve SELECT FOR UPDATE ve yazım üreten CTE’ler gibi önemli uç durumları ele alabilir: PgDog yük dengeleyici özeti.

Bu, uygulama yönlendirme ayrılması genellikle aşağıdaki gibi görünür:

$connection = $isWrite ? 'pgsql-primary' : 'pgsql-replica';

return DB::connection($connection)
    ->table('orders')
    ->where('user_id', $userId)
    ->latest()
    ->first();

Bu masum görünüyor. Ama bu, uzun bir bakım faturasının başlangıcıdır.

Fatura aşamalar halinde gelir:

Aşama 1: Yönlendirme Kararlarını Çoğaltıyorsunuz

Bir Laravel uygulaması bir yönlendirme yardımcı seti geliştirir. Bir Node servisi başka bir seti büyütür. Kuyruk işçileri farklı bir şey yapar. CLI görevleri her şeyin dışına çıkar. Kimse bunu fark etmez, çünkü mutlu yol hâlâ çalışır.

Aşama 2: Tutarlılık Hataları Bağlama Duyarlı Hale Gelir

Bir kullanıcı fatura bilgilerini günceller ve takviye edilmiş bir çoğaltıcıdan okunan bir sayfaya yeniden yönlendirilir. Destek, kişilerin sadece yazmalardan sonra ve yalnızca bir istek yolunda oluşan hatayı tutarlı bir şekilde yeniden üretemez.

Aşama 3: Olay Davranışı Keyfi Hale Gelir

Bir çoğaltıcı yavaşlar veya kaybolur. Bir hizmet birinciliğe taşar. Diğeri zaman aşımına uğruyor. Bir raporlama işçisi, yönlendirme mantığı eski bir scriptten kopyalandığı için tek sağlıklı düğümü delip geçer.

İşte o anda yönlendirme katmanı, bir rahatlık olmaktan daha fazlasına dönüşmektedir ve uygulama kodundan politikayı kaldırmakla ilgilidir.

PgDog için en güçlü argüman, “veritabanımız devasa değil.” değil, “topoloji politikamız birçok istemci aracılığıyla tutarlı bir şekilde uygulanmalıdır ve her uygulama çalışma zamanının doğru işleyeceğine artık güvenmiyoruz” şeklindedir.

PgBouncer ve PgDog: Kapsam Kararı, Abartı Kararı Değildir

Pek çok ekip PgDog’u değerlendirirken önce gerçekten PgBouncer’a mı ihtiyacınız olduğunu sormalıdır.

PgBouncer hâlen birçok sistem için daha temiz bir cevap. Temel acı, bağlantı dönüşümüyse, çok fazla uygulama sürecinden kaynaklanan arka uç baskısıysa veya hafif havuzlamaya ihtiyacınız varsa, PgBouncer hala zorlanacak bir şey değil. Temel, kanıtlanmış ve operasyon açısından anlaması daha kolaydır.

Sınırları da iyi belgelenmiştir. Resmi PgBouncer özellik matrisi, işlem havuzlamasının istemci beklentilerini önemli şekillerde değiştirdiğini gösteriyor. Oturum düzeyindeki özellikler, SET/RESET, LISTEN, oturum danışmanlık kilitleri ve bazı geçici tablo davranışları burada aynı şekilde çalışmıyor: PgBouncer özellikleri.

Bu değişim çoğu kez kabul edilebilir. Birçok web uygulaması bununla yaşayabilir. Ancak farklı bir sorunu çözdüğü unutulmamalıdır.

PgBouncer Ne Zaman Doğru Bir Cevaptır

• temel acınız çok fazla bağlantı ise
• topolojiniz hala basitse
• okuma yönlendirmesi sınırlı veya zaten uygulamada belirginse
• uygulama ve veritabanı arasında en az hareket eden parçayı istemek
• sorguya duyarlı proxy davranışını üstlenmeye hazır değilseniz

PgDog Daha İkna Edici Hale Gelir

• uygulamalardan topolojiyi gizleyen tek bir PostgreSQL son noktası istiyorsanız
• birden fazla yürütme ortamında okumaları/yazmaları yönlendirme ihtiyacınız varsa
• çalışan süreçlerinizin ve CLI işlerinizin web uygulaması gibi davranması gerekiyorsa
• failover davranışı politika tarafından değil, çerçeve tarafından yönlendirilmelidir
• shard’lama, günümüz bağlantı stratejisini etkilemek için yeterince gerçekçi olabilirse

Son nokta önemlidir. Şu anda sharding yapmasanız bile, takımlar genellikle her uygulama sürecinin derinliklerinde bir ana bilgisayar varsayımı yerleştirerek bir karmaşa yaratırlar. Bir proxy, opsiyon sunabilir. Yanlış olan, bu karmaşıklık vergisini sorunun gerçek olmadığı zamandan önce ödemektir.

Benim tarafım burada tutucudur. PgDog’ı, geleceğe dönük görünmesi nedeniyle eklemeyin. Şu anda yönlendirme davranışınız yeterince parçalanmışsa, merkezi hale getirmeyi gerektirir.

Gerçek Tasarım İşleri Hata Modlarındadır

Herhangi bir yönlendirme katmanı, çoğaltıcıların sağlıklı olduğu, lag’ın düşük olduğu ve trafiğin öngörülebilir olduğu durumlarda iyi görünür. Sistem stres altındayken karar gerçek oluyor.

PgDog belgeleri, tüm SELECT sorgularının eşit olduğunu varsaymadığı için bazı uzun bir gerçekliği açık bir şekilde sunar. Bir sorgu SELECT ile başlayabilir, ancak aynı zamanda bir yazma yolunun operasyonel bir parçası olabilir.

Örnek 1: Lock’lu okumalar, çoğaltıcı okumalar değildir.

Yaygın bir kuyruk şeması şu şekilde görünmektedir:

BEGIN;

SELECT id, payload
FROM jobs
WHERE status = 'pending'
ORDER BY id
FOR UPDATE SKIP LOCKED
LIMIT 1;

UPDATE jobs
SET status = , started_at = NOW()
WHERE id = $1;

COMMIT;

Eğer yönlendirme modeliniz dize eşleşmesine veya ORM düzeyindeki içgörülere dayanıyorsa, burada bozulur. İlk ifade satırları okur, ancak aynı zamanda kilitler edinir ve doğrudan bir yazma iş akışına katılır. PgDog, SELECT FOR UPDATE yönetimini açıklar çünkü ciddi bir yönlendirme katmanının bunun birincil üzerinde olması gerektiğini anlaması gerekir.

Eğer uygulamanız bu mantığı dağınık bir kodda barındırıyorsa, her uygulama yolunun aynı nüansı hatırlamasını sağlamak zorunda kalırsınız.

Örnek 2: Üst düzey bir SELECT hala yazabilir.

WITH created AS (
          INSERT INTO audit_log (user_id, action)
          VALUES ($1, )
          RETURNING id, user_id
    )
    SELECT u.id, u.email, c.id AS audit_id
    FROM users u
    JOIN created c ON c.user_id = u.id
    WHERE u.id = c.user_id;

Bu, basit okuma/yazma ayırma mantığını bozan türde bir sorgudur. Rapor gibi görünür, ancak CTE durumu değiştirir. PgDog, yazma CTE denetimini belirtir çünkü gerçek SQL, “ifadenin başındaki fiil” kadar basit değildir.

Çoğaltıcı lag’ı bir dipnot değildir.

Hatta kurnaz bir proxy, eşzamanlı çoğaltma lag’ını ortadan kaldıramaz. Eğer sisteminiz birincilde yazım yapar ve hemen ardından bir çoğaltıcıdan bağımlı durumu okumaya çalışıyorsanız, uygulama düzeyinde bir tutarlılık kararı vermek zorundasınız.

Bu karar açık olmalıdır. Bazı akışların yazımdan sonra birincilden okuma gereksinimi vardır:

• checkout ve ödeme onayı
• kimlik doğrulama veya rol değişiklikleri
• envanter ve stok rezervasyonu
• herhangi bir akış, bayat okumaların kullanıcıya görünür çelişkiler yaratmasına neden olabilir.

Diğer akışlar genellikle çoğaltıcılardan okumaları tolere edebilir:

• gösterge panelleri
• raporlama
• arama sonuçları süslemesi
• analitik ve iç ofis içgörüleri

Başarısızlık, çoğaltıcıları kullanmamaktır. Başarısızlık, her okuyucunun aynı doğruluk gereksinimlerine sahip olduğunu varsaymaktır.

Düşük performans modu, kesinti öncesinde tasarlanmalıdır.

PgDog, birincilin aynı zamanda okumaları karşılayıp karşılaması gerektiği ve çoğaltıların kullanılamadığı zamanlarda okuma trafiğini geçici olarak emip ememeyeceği gibi seçenekleri belgeleriyle açıklar. Bu operasyonel olarak faydalıdır. Ayrıca, gerçek bir karar vermenizi zorlar: çoğaltıcılar başarısız olduğunda, geçici hizmet mi, yavaş ama doğru hizmet mi, yoksa bazı trafik türleri için sert bir başarısızlık mı istersiniz?

Burada evrensel bir doğru cevap yoktur.

Bir ürün ekibi genellikle bu gibi kalıplar arasında karar vermek zorundadır:

1. Açık kural ile birincile geçin. Okuma trafiği birinciliğe geçerek uygulamanın işlevsel kalmasını sağlar, ancak yazma düğümü aşırı yüklenme riski taşır.
2. Yalnızca çoğaltıcılar için kapalı durumu kullanın. Bazı raporlama veya düşük öncelikli uç noktalar temiz bir şekilde düşer veya devre dışı kalır.
3. Karışık politika. Kritik kullanıcı akışları birinciliğe geri döner; önemsiz iş yükleri yükü azaltır veya kuyruk oluşturur.

Bu yalnızca bir veritabanı seçimi değildir. Stres altında ürün davranışıdır. Bir proxy politikayı uygulayabilir, ancak bunu sizin için icat edemez.

Tam Yığın Ekiplerin Yönlendirme Katmanı Eklemeden Önce Vermesi Gereken Kararlar

PgDog’ı eklemeden önce bu kararları vermemek, ekiplerin daha karmaşık bir kargaşa yaratmasına neden olur.

1. Hangi akışların okuma/yazma garantilerine ihtiyaç duyduğunu tanımlayın

Bunu “biz okumaları çoğaltıcılar için kullanıyoruz.” şeklinde basit geçiştirmeyin. Gerçek ürün yüzeylerini haritalayın. Eğer bir kullanıcı bir şeyi değiştirirse ve bunun hemen yansımasını beklerse, o yol muhtemelen eşzamansız çoğaltıcılara güvenemez.

Bu, Laravel ve Node yığınlarında senkronize kullanıcı isteklerini asenkron işler ile karıştıran senaryolarda özellikle önemlidir. Bir kuyruk işçisi, bir web isteğinin bir saniye sonra okuduğu durumu güncelleyebilir. Eğer o istek çoğaltıcıdan varsayılan olarak yönlendiriliyorsa, kullanıcı deneyimine tutarsızlık katmış olursunuz.

2. Uç nokta hikayesini standardize edin

Eğer PgDog’ı benimseyecekseniz, kazanılacak şey tutarlılıktır. Uygulamanın on yerde topolojiyi kodlamayı bırakması gerekir.

Bir Node servisi veritabanını stabil bir mantıksal uç nokta olarak değerlendirebilmelidir:

import { Pool } from 'pg';

export const pool = new Pool({
  host: process.env.PGDOG_HOST,
  port: 6432,
  database: process.env.DB_NAME,
  user: process.env.DB_USER,
  password: process.env.DB_PASSWORD,
  max: 20,
  connectionTimeoutMillis: 2000,
  idleTimeoutMillis: 30000,
});

export async function loadAccountSummary(accountId) {
  const { rows } = await pool.query(
    `
      select id, email, plan, created_at
      from accounts
      where id = $1
    `,
    [accountId]
  );

  return rows[0] ?? null;
}

Bu, her hizmete ayrı okuma ve yazma DSN’lerini kablonun her yerine sokmaktan daha iyi bir soyutlama sınırıdır ve geliştiricilerin her zaman doğru seçimi yapmasını beklemekten daha iyidir.

3. İşlemlerin yönlendirme ile nasıl etkileşime gireceğini belirleyin

Manuel olarak başlatılan işlemler genellikle sıradan kalmalıdır. Eğer bir iş birden fazla ifade içerecekse, akıllı yönlendirmenin maliyeti genellikle faydasını aşar. Çoğu ekip, belirgin bir nedenle başka şekilde yönergeler almak zorunda kalmadıkça, açık işlemleri birincilin bağlı olduğu varsayıla getirmelidir.

Bu, proxy düzeyindeki yönlendirmenin uygulama düzeyindeki sezgilerden daha güvenli olabilmesinin bir nedenidir. Yönlendirme kuralları varsayılan olarak muhafazakar kalabilir.

4. Gözlemlenebilirlik konusunda dürüst olun

Düşük gözlemlenebilirlik ile bir yönlendirme katmanı, bir suçlama makinesi haline gelir. Eğer gecikme artarsa, bunun problemin proxy’den, bir çoğaltıcıdan, birincilden, belirli bir sorgu sınıfından mı yoksa uygulama havuz davranışından mı kaynaklandığını bilmeniz gerekir.

En azından ekiplerin aşağıdakilere görünürlük beklemesi gerekir:

• arka ucun sağlık durumu ve yasak durumu
• yönlendirme düzeyindeki gecikme ve hata oranı
• çoğaltıcının doyumu ile birincilin doyumu
• düşük performans modunda taşma davranışı
• bağlantı havuz baskısı ve kuyruklama

Eğer bunları gözlemleyemiyorsanız, bir proxy eklemek olayı daha da kötüleştirebilirken, mimariyi daha iyi hale getirebilir.

5. Shard’lamayı bir yol haritası sinyali olarak değil, bir gösteriş sinyali olarak ele alın

PgDog’ın daha geniş vaadi sharding içerir. Bu yalnızca alan modeliniz, kiracı sınırları veya büyüme yolları bunun olasılığını artırıyorsa önemlidir. Şu anki karmaşıklığı tek başına justifiye etmemeli.

Ancak ekibinizin ileride kiracı bölümlendirmesi, bölgesel veri yerleşimi veya sıcak nokta izolasyonu gibi konular beklemesi durumunda, her istemcinin topolojiyi yeniden öğrenme zorunda kalmamasını sağlamak için öncelikle bir erişim katmanı tercih etmek makul olabilir.

Mantıklı Bir Benimseme Yolu

Daha akıllı bir yönlendirme katmanını benimsemenin en iyi yolu, büyük bir kesinti ile değil.

Basit başlayın:

• öncelikle bağlantı davranışını stabilize edin
• tutarlılık duyarlı akışları belgeleyin
• gerçekten güvenli bir şekilde offload edilebilecek okuma hacmini ölçün
• bir hizmet türü veya ortam için proxy’yi tanıtın
• üretim hazır olarak çağırmadan önce düşük performans modunu doğrulayın

Bir konfigürasyon iskeleti şu şekilde görünebilir:

[general]
load_balancing_strategy = "round_robin"
read_write_split = "exclude_primary"

[[databases]]
name = "app"
role = "primary"
host = "10.0.0.10"
port = 5432

[[databases]]
name = "app"
role = "replica"
host = "10.0.0.11"
port = 5432

[[databases]]
name = "app"
role = "replica"
host = "10.0.0.12"
port = 5432

Bu zorluk değil. Zor kısım, uygulama semantikalarının yalnızca beyan ettiğiniz yönlendirme politikasıyla eşleşip eşleşmediğini doğrulamaktır.

Bayat okuma toleransı, işlem beklentileri ve geri dönüş davranışını haritalamamış bir ekip, akıllı bir proxy dağıtmıyor. Karmaşayı altyapıya outsource ediyor.

Pratik Karar Kuralı

PgDog, PostgreSQL yönlendirmesinin yalnızca veritabanı ekibinden kaçtığı ve uygulama tasarımını şekillendirmeye başladığı zamanlarda mantıklıdır. Eğer çoğaltıcılar, hata durumu ve trafik politikası, repository’lere, işçilere ve çerçeve yapılandırmasına sızıyorsa, bu kuralların merkezileştirilmesi iyi bir mimari hareketidir.

Eğer sorununuz hala çoğunlukla bağlantı sayısıysa, PgBouncer’ı seçin ve yığını daha küçük tutun. Eğer sorununuz artık birçok istemci aracılığıyla politika tutarlılığı ise, PgDog daha ciddi bir araçtır.

Basit bir kural şöyledir: topoloji, ürün davranışının bir parçası haline geldiğinde bir yönlendirme katmanı ekleyin, yalnızca altyapı detayları olarak değil. Bu noktada sorunu uygulama kodunun içine gizlemek genellikle daha maliyetli bir seçimdir.

Tam gönderiyi QCode’da okuyun: https://qcode.in/pgdog-smarter-postgres-routing-apps/