PgDog - Ek bir uzantı olmadan Postgres'i shard etmeyi sağlayan araç

 (github.com/pgdogdev)
4 puan yazan GN⁺ 2025-05-29 | 1 yorum | WhatsApp'ta paylaş
  • Rust ile geliştirilen PostgreSQL için bir transaction pooler ve mantıksal replikasyon yöneticisi olarak, yatay ölçekleme ve shard etme otomasyonu sunar
  • Uzantı olmadan PostgreSQL veritabanını kolayca shard etme imkanı sağlar; yüzlerce veritabanı ve yüz binlerce bağlantıyı yönetmek için optimize edilmiştir
  • Uygulama katmanında (OSI 7) çalışan bir DB load balancer olarak, SELECT sorgularını replikalara, diğerlerini ise otomatik olarak primary'e yönlendirebilir
  • PgBouncer gibi transaction/session pooling desteklerken, aynı zamanda sorguları parse edip shard'lara otomatik yönlendirme ve sonuçları birleştirme de yapar
  • COPY ve mantıksal replikasyonu kullanarak veriyi shard'lara otomatik dağıtabilir veya mevcut DB'yi kesintisiz şekilde shard edebilir
  • Yapılandırma bir TOML dosyasıyla basitçe tanımlanabilir ve çalışma anında yeniden yapılandırma mümkündür
  • Postgres uzantısı kullanan Citus'tan farklı olarak DB dışı bir proxy olduğu için RDS, Cloud SQL gibi ortamlarda da kullanılabilir

Proje tanıtımı ve temel değerleri

  • PgDog, PostgreSQL veritabanları için kolay shard etme, mantıksal replikasyon, transaction pooling ve L7 yük dengeleme dahil her yönüyle yatay ölçeklemeyi destekleyen açık kaynaklı bir çözümdür
  • Rust diliyle geliştirildiği için yüksek performans ve güvenlik sağlar
  • PgDog, uzantı kurulumu gerektirmeden, yalnızca tek bir proxy dağıtımıyla shard etme, veri dağıtımı, hata kurtarma ve esnek load balancing sağlar
  • Rakip ürünlerden (ör. PgBouncer, PgCat) farklı olarak otomatik shard etme ve mantıksal replikasyonun tamamını desteklemesi; ayrıca çalışma sırasında yapılandırma değişikliği ve gerçek zamanlı izleme sunması güçlü yanlarıdır

Başlıca özellikler

Yük dengeleme (Load Balancer)

  • PgDog, OSI 7. katmanda çalışan bir uygulama seviyesi proxy olarak, sorguları birden fazla PostgreSQL replikası ve ana düğüm arasında dağıtarak arıza ve yük sorunlarını önlemeye yardımcı olur
  • Dağıtım stratejileri arasında round-robin, rastgele ve en az bağlantı gibi çeşitli seçenekler bulunur
  • Sorgu türünü ayırt ederek SELECT'i replikalara, diğer yazma sorgularını ise otomatik olarak ana düğüme yönlendirir
  • Health check ve arıza durumunda otomatik failover gerçekleştirir; ağ hataları veya donanım arızalarında da erişilebilirliği korur

Transaction pooling

  • PgDog, PgBouncer gibi transaction ve session pooling ile bağlantı kaynaklarını verimli yönetir; böylece yüz binlerce istemciyi az sayıda backend bağlantısıyla karşılayabilir

Sharding

  • Sorgu sözdizimini doğrudan parse ederek sharding key çıkarımı yapar ve en uygun yönlendirme algoritmasını uygular
  • Birden fazla shard veritabanı arasında cross-shard query desteği sunar; sonuçları bellekte birleştirip istemciye şeffaf şekilde iletir
  • COPY komutu çalıştırıldığında CSV parse ederek veriyi çoklu shard'lara dağıtma desteği verir; büyük hacimli yüklemeler için kullanışlıdır
  • PostgreSQL mantıksal replikasyon protokolü tabanlı olarak kesintisiz arka plan senkronizasyonu sağlar; çalışma sırasında gerçek zamanlı shard ekleme ve ölçekleme mümkündür

İzleme

  • PgBouncer tarzı yönetim veritabanı ile OpenMetrics endpoint desteğini birlikte sunar
  • Datadog gibi harici izleme araçları ve dashboard örnekleri sağlar

Yapılandırma ve çalışma zamanı

  • Başlıca ortamlar: Kubernetes (Helm chart desteği), Docker ve yerel ortam (Rust build) üzerinde kolayca dağıtılabilir ve test edilebilir
  • Genellikle yalnızca 2 yapılandırma dosyası (pgdog.toml, users.toml) yazarak minimum shard etme ve kullanıcı tabanlı işletim ortamı kurulabilir
  • Yapılandırma değerlerinin çoğu gerçek zamanlı değiştirilebilir ve süreç yeniden başlatılmadan dinamik olarak uygulanır

Performans ve lisans

  • PgDog, Rust ve Tokio tabanlı yüksek performanslı asenkron bir ağ proxy'si olarak, veri hareketini en aza indirmeye ve performans kaybını bastırmaya odaklanır
  • Benchmark sonuçları resmî dokümantasyonda sunularak performans ölçütü belirlemeyi mümkün kılar
  • AGPL v3 açık kaynak lisansı ile sunulur; şirket içi kullanım ve özel özelleştirmelere tamamen açıktır
  • Ancak kamuya açık bulut hizmeti sunan şirketler için, kod değişikliği yapıldığında bu değişikliklerin paylaşılması şartı vardır

Proje durumu ve katkı

  • Şu anda erken aşamadadır; early adopter kullanıcıların kendi başlarına benimsemesi önerilir ve özellik bazlı kararlılık düzenli olarak güncellenmektedir
  • Özellik testleri ve benchmark çalışmaları da sürekli sürdürülmektedir
  • Açık kaynak topluluğunun katkılarına açıktır; ayrıntılar için Contribution Guidelines'a bakılabilir

Sonuç

  • PgDog, üretim ortamında PostgreSQL için yatay ölçeklenebilirlik, yüksek erişilebilirlik ve otomatik shard etme ihtiyacı duyan geliştirme ekipleri ve şirketler için güçlü bir çözüm sunar
  • Ek uzantılar veya karmaşık altyapı kurulumları olmadan hızlıca uygulanabilmesi ve özelleştirilebilmesi en büyük avantajlarından biridir

İlgili okumalar

1 yorum

 
GN⁺ 2025-05-29
Hacker News görüşleri

  • Lev’i selamlayıp şu anda 40TB ölçeğinde bir Postgres veritabanını shard etmek için PgDog ile şirket içinde doğrudan kurulan bir çözümü karşılaştırdığını anlatıyor; Vitess for PostgreSQL benzeri çalışan bir çözüme ihtiyaç duyduklarını söylüyor. Scatter-gather özelliğine ek olarak etcd benzeri bir yapıya dayalı yapılandırma yönetimi, shard bölme ve tüm shard’lara şema değişikliklerini uygulayan best-effort transaction’ların da gerektiğini vurguluyor. pg_query.rs ile query rewrite deneyimini soruyor; AST tiplerinin değiştirilemez olması ve deep clone eksikliği nedeniyle yeniden yazımda zorlandığını paylaşıyor. Sonunda Visitor pattern destekleyen sqlparser crate’ini kullandığını ve shadow table’lar ile logical replication tabanlı olarak PostgreSQL için online şema değişikliği üzerine bir yan proje geliştirdiğini anlatıyor.

    • İş birliği teklifine sevindiğini söyleyip iletişim bilgisini paylaşıyor. Yapılandırma yönetiminin zaten K8s veya çeşitli CD araçlarıyla çözülebileceğini ve PgDog yapılandırma reload senkronizasyonunun mümkün olduğunu açıklıyor. Best-effort transaction ile tüm shard’larda şema değişikliğinin hâlihazırda çalıştığını, idempotent şema değişikliklerinin en iyisi olduğunu ama hata durumunda two-phase commit’in de değerlendirilebileceğini belirtiyor. Shard bölmenin logical replication ile yapılabileceğini örnek vererek Instacart’ta 10TB+ deneyiminden bahsediyor: replication slot açtıktan sonra N instance’a restore etme, shard numarası uyuşmayan verileri silme ve logical replication ile yeniden senkronize etme sürecini paylaşıyor. Pg 17’deki logical replication’ı streaming replica üzerinde kullanarak paralel bölme fikrinden ve foreign table ile veriyi doğrudan COPY etme yönteminden de söz ediyor. pg_query.rs’in artık mutable çalışıyor gibi göründüğünü, son dönemde gerçekten query rewrite ve query generation için aktif biçimde kullandığını, %100 Postgres parser tabanlı olmasının önemli bir avantaj olduğunu vurguluyor. deparse özelliğinin çeşitli yerlerde bulunmasının da karmaşık işleri mümkün kıldığını ekliyor.

  • Vitess for Postgres diye bir şey varsa, Yugabyte zaten o rolü oynamıyor mu diye soruyor.

  • Temel özelliklere bakınca küçük göründüğünü ama PgDog ile uygulama koduna dokunmadan okumaları read replica’ya, yazmaları primary’ye ayırabilmenin çok büyük bir avantaj olduğunu düşünüyor. Birçok uygulamanın R/W ayrımını doğrudan desteklemediğini, bu yüzden bunu proxy seviyesinde çözmenin geçmişte ciddi performans artışı sağladığını paylaşarak projeyi övüyor.

    • Bu özelliğin zaten pgcat’te de kullanılabildiğini belirtiyor ve pgcat bağlantısını paylaşıyor.

    • Instacart’ta Makara ile R/W ayrımı yaptıklarını, ancak Python ya da Go gibi farklı dil ortamlarında bunu her seferinde aynı şekilde uygulamanın oldukça zahmetli olduğunu paylaşıyor.

  • Projeyi etkileyici bulduğunu, ancak tamamen otomatik shard etme fikrine biraz mesafeli yaklaştığını söylüyor. Genelde shard etmenin tenancy sınırlarında yapıldığını ve bu sınırların aşılmasının bir miktar sürtünme yaratmasını tercih ettiğini açıklıyor. Shard’lar arası join’lerin performans, bellek ve CPU açısından shard içi join’lerden farklı olduğunu, bunun daha net görünür kılınması gerektiğini düşünüyor. Yine de projenin kendisinden şüphe duymadığını ve çok sayıda kullanım alanı olacağını belirtiyor.

    • Neden özellikle sürtünme istendiğini soruyor; shard’lar arası join performans sorunlarının çoğunun iyi anlaşıldığını ve gerçek zamanlı metriklerle izlenebildiğini, sonuçta her iki yaklaşımın da gerektiğini, join’i uygulama kodunda yapma alternatifinin ise pek arzu edilir olmadığını ekliyor.

  • Bir süredir PgDog’u takip ettiğini ve çok etkileyici bulduğunu söylüyor; çıkışı için tebrik edip gelişiminin sürmesini dilediğini belirtiyor.

    • 15 yıllık yolculuğun daha yeni başladığını söylüyor.

  • Ağ katmanında şeffaflık ve uyumluluğu koruyarak dağıtık sorguları ele almasının asıl çekicilik olduğunu düşünüyor. Belgelerdeki mevcut kısıtların doğal olduğunu, bunun çeşitli trade-off’lar gerektireceğini beklediğini söylüyor. Bunun nasıl çözüleceğini merak ettiğini ve ek tartışmalar varsa katılmak istediğini belirtiyor.

  • PgDog benzeri çözümlerde en büyük zorluğun, shard edilmiş karmaşık sorguları son %1’e kadar doğru biçimde işlemek ya da anormal sorguları tespit etmek ve aynı zamanda izolasyon ile tutarlılığı tam olarak garanti etmek olduğunu söylüyor.

  • Belgeleri görür görmez önce Unique Index desteğine baktığını, ancak bunun hâlâ query rewrite ve ayrı bir execution engine gerektirdiği için desteklenmemesinin üzücü olduğunu söylüyor. Yine de potansiyel gördüğünü ve umutlandığını ekliyor.

    • Küçük bir ödün karşılığında tüm shard’larda benzersiz primary key üretiminin zaten desteklendiğini belirtiyor ve ilgili belge bağlantısını paylaşıyor. Cross-shard unique index uygulamasının her sorguda kontrol gerektirdiği için maliyetli olduğunu, bu konuda fikirlere açık olduğunu söylüyor.

  • Bunun yıllardır gördüğü en ilginç Postgres projelerinden biri olduğunu vurguluyor. Verilen benchmark’ların yalnızca temel connection pooling’i kapsıyor gibi göründüğünü, query parsing veya shard’lar arası join devreye girdiğinde sonuçların nasıl olacağını merak ettiğini söylüyor.

    • Query parser’ın cache’lendiğini, prepared query veya placeholder kullanıldığında yalnızca lock ve hash lookup eklendiğini, bu yüzden neredeyse maliyetsiz olduğunu açıklıyor. Shard’lar arası join’de ise filtreler ideal değilse query işleme maliyetinin yükselebileceğini ve sonuç kümesi büyük olduğunda diske paging gerekebileceğini tahmin ediyor. Önceliğin OLTP olduğunu, join’leri mümkün olduğunca pushdown etmeye çalıştıklarını ve yakında shard’lar arası join talebinin de artacağını öngörüyor.

  • Postgres ölçeklenebilirliği için gerçekten gerekli bir yenilik olduğunu söyleyerek çıkışı kutluyor.

  • Projenin son derece harika göründüğünü ve çıkışı tebrik ettiğini söylüyor.

    • Bunun yıllara yayılan emeğin sonucu olduğunu vurguluyor.