Kafka hızlıdır — ben Postgres kullanacağım

 (topicpartition.io)
2 puan yazan GN⁺ 2025-10-31 | 1 yorum | WhatsApp'ta paylaş
  • Postgres’in publish/subscribe (pub-sub) ve kuyruk (queue) performansı benchmark edilerek, tek bir veritabanının da mesajlaşma sisteminin yerini alabileceği gösteriliyor
  • Tek bir 4vCPU düğümde saniyede 5.036 yazma ve 25.183 okuma, 3 düğümlü replikasyon ortamında da benzer throughput korunuyor; uçtan uca gecikme 186 ms (p99) seviyesinde
  • Büyük bir 96vCPU düğümde 238MiB/s yazma, 1.16GiB/s okuma elde edildi; CPU kullanımı %10’un altında kalarak rahat bir işleme kapasitesi doğrulandı
  • Kuyruk testlerinde de tek düğüm bazında saniyede 2.885 işlem, replikasyon ortamında ise 2.397 işlem mümkün; bu da çoğu şirket ölçeği için yeterli performans anlamına geliyor
  • Karmaşık dağıtık sistemler yerine yalnızca Postgres altyapısıyla da birkaç MB/s ölçeğinde iş yüklerinin işlenebileceği kanıtlanıyor; “gerektiği ana kadar basit teknolojiyi kullan” şeklindeki pratik yaklaşım vurgulanıyor

Teknoloji seçiminde iki kamp

  • Teknoloji sektörü buzzword odaklı kamp ile sağduyu odaklı kamp olarak ikiye ayrılıyor
    • İlki “gerçek zamanlı”, “sonsuz ölçeklenebilir”, “AI destekli” gibi pazarlama terimlerine kapılıyor
    • İkincisi sadelik ve pratikliği öne çıkarıyor, gereksiz karmaşıklıktan kaçınıyor
  • Son dönemde Small Data ve Postgres rönesansı olarak öne çıkan iki akım, ikinci yaklaşımı güçlendiriyor
    • Veri küçülüyor, donanım ise güçleniyor
    • Postgres, tek bir sistem olarak çeşitli amaca özel çözümlerin yerini alabiliyor (jsonb, pgvector, tsvector vb.)

Benchmark özeti

  • Amaç: Postgres’in pub/sub mesajlaşma ve kuyruk işleme tarafında ne kadar ölçeklenebildiğini ölçmek
  • Test ortamı: AWS EC2 c7i.xlarge (4vCPU) ve c7i.24xlarge (96vCPU)
  • Üç yapılandırma karşılaştırıldı
    • tek düğüm
    • 3 düğümlü replikasyon kümesi
    • büyük tek düğüm

Pub/Sub benchmark sonuçları

  • 4vCPU tek düğüm
    • 4.8MiB/s yazma (5.036msg/s), 24.6MiB/s okuma (25.183msg/s), 60 ms gecikme (p99)
    • CPU kullanımı %60, disk yazımı 46MiB/s
  • 4vCPU 3 düğümlü replikasyon
    • 4.9MiB/s yazma, 24.5MiB/s okuma, 186 ms gecikme (p99)
    • Throughput korunuyor, yıllık maliyet yaklaşık $11.514
  • 96vCPU tek düğüm
    • 238MiB/s yazma (243kmsg/s), 1.16GiB/s okuma (1.2Mmsg/s), 853 ms gecikme (p99)
    • CPU kullanımı %10’un altında, darboğaz partition başına yazma hızı
  • Sonuç: düşük ve orta ölçekli iş yüklerinde Kafka ile rekabet edebilecek düzeyde, basit bir yapı ile bile onlarca MB/s işlenebiliyor

Queue benchmark sonuçları

  • SELECT FOR UPDATE SKIP LOCKED tabanlı basit kuyruk implementasyonu
  • 4vCPU tek düğüm
    • 2.81MiB/s (2.885msg/s), 17.7 ms gecikme (p99), CPU %60
  • 4vCPU 3 düğümlü replikasyon
    • 2.34MiB/s (2.397msg/s), 920 ms gecikme (p99), CPU %60
  • 96vCPU tek düğüm
    • 19.7MiB/s (20.144msg/s), 930 ms gecikme (p99), CPU %40~60
  • Tek düğümle bile çoğu işletmenin kuyruk throughput ihtiyacı karşılanabiliyor

Postgres kullanma kararı

  • Çoğu durumda varsayılan tercih olarak Postgres mantıklı
    • Mesajları SQL ile debug etmek, değiştirmek ve join etmek mümkün
    • Kafka’ya kıyasla operasyonel olarak daha sade ve bakımı daha kolay
  • Kafka yüksek performans için optimize edilmiştir, ancak küçük ölçekli iş yükleri için fazla ağır bir seçim olabilir
  • Donald Knuth’un “erken optimizasyon tüm kötülüklerin köküdür” uyarısı alıntılanıyor
    • Birkaç MB/s seviyesine kadar Postgres yeterli

MVI yaklaşımı

  • Minimum Viable Infrastructure: Kurumun zaten aşina olduğu teknolojiyle asgari düzeyde sistem kurmak
    • Postgres yaygın biçimde benimsenmiş durumda ve bu alanda insan kaynağı bulmak kolay
    • Bileşen sayısı azaldıkça arıza ve operasyon yükü de azalıyor
  • Gereksiz teknoloji eklemek kurumsal overhead yaratıyor
    • Öğrenme, izleme, dağıtım ve işletim maliyetleri artıyor

Ölçeklenebilirlik tartışması

  • Postgres gerçekten ölçeklenebilir
    • OpenAI hâlâ tek yazma instance’ına dayalı Postgres kullanıyor
    • Yüz milyonlarca kullanıcı ölçeğinde bile istikrarlı işletim mümkün
  • Çoğu şirketin büyüme hızı daha ılımlı olduğundan, teknoloji değişimine kadar yıllarca zamanı oluyor
  • “Viral olmaya göre tasarlamak” aşırı bir overdesign örneği
    • Bu durum, “Coldplay’in açılışını yapmak için Marshall amfi satın almaya benziyor” diye anlatılıyor

Sonuç

  • “Kırılana kadar Postgres kullanın”
    • Basit teknolojiyle de yeterince yüksek performans elde edilebilir
    • Gerekenden daha karmaşık dağıtık sistemler kurmak verimsizdir
    • Postgres, modern donanımla birlikte çoğu iş yükünü taşıyabilecek pratik bir seçenek sunuyor

İlgili okumalar

1 yorum

 
GN⁺ 2025-10-31
Hacker News görüşleri

  • Pareto ilkesini her duruma uygulamak yanlış bir yorumdur
    Postgres'in Kafka'dan %20 çabayla kullanım senaryolarının %80'ini karşıladığını söylemek temelsiz bir iddiadır
    Pareto ilkesi yalnızca güç yasası dağılımı görülen durumlarda anlamlıdır
    Sadece Postgres'in yeterince çok kullanım senaryosunu kapsayan, istikrarlı ve kendini kanıtlamış bir araç olduğunu söylemek yeterlidir

    • Ancak kullanım senaryoları ile özellikler arasındaki eşleşmenin kendisi de bir güç yasası dağılımını izliyor olabilir diyenler de var

  • Küçük ölçekten (saatte yüzlerce olay) büyük ölçeğe (saatte trilyonlarca olay) kadar çalışmış biri olarak, önce gerçekten bir kuyruğa ihtiyaç olup olmadığını sorgulamak gerekir

    1. Basit DB polling tek başına yeterli olabilir
    2. Tek bir düğüm kaldırabiliyorsa serverless ya da tek süreçli bir yapı yeterli olabilir
    3. Dağıtık bir kuyruk gerçekten gerekmiyorsa, load balancing + REST API + asenkron retry de yeterlidir
    4. Gerçekten dağıtık bir kuyruk gerekiyorsa, Kafka gibi buna adanmış bir çözüm kullanmanın daha iyi olduğunu düşünüyorum
    • Kafka'nın aslında bir kuyruk değil, dağıtık bir log sistemi olduğunu netleştirmek gerekir. Sık sık MQ ikamesi sanılıyor
    • Startup'larda mühendisler bazen mevcut projeden çok bir sonraki kariyer adımını düşünerek karmaşık teknolojileri seçme eğiliminde oluyor
    • Kod yapısını hem PostgreSQL tabanlı kuyruk hem de Kafka tabanlı kuyrukla uyumlu tasarlarsanız, ileride geçiş yapmak kolaylaşır
    • PostgreSQL'de yazma yükü arttığında darboğaz oluşması kolaydır. Özellikle UPDATE stream'leri çok acı vericidir
    • Bir Java geliştiricisi olarak her zaman bir kuyruğa ihtiyaç duydum. DB polling, birden fazla consumer/producer ortamında baş ağrısı oluyordu. Kafka'nın consumer group ve partition yapısı durum yönetiminde çok yardımcı oldu

  • Postgres'i her amaç için kullanma yaklaşımı risklidir
    Lock ve serialization level sezgisel değildir, bu da performans darboğazlarına yol açabilir
    On yıllardır Postgres kullanıyor olsam da, kör bir inançla sistem tasarlanmaması gerektiğini düşünüyorum

    • Trafik aniden arttığında dikey ölçekleme sınırları sorun olur. Kafka trafik patlamalarını emer ama Postgres kolayca aşırı yüklenir
    • Postgres'e sürdürülebilir bir kuyruk yapısı eklenmesi güzel olurdu ama Redis seviyesinin ötesine ölçeklemek zordur ve LISTEN/NOTIFY ölçeklenmez (ilgili bağlantı)
    • Aslında tüm veri depolarında eşzamanlılık modelini anlamak gerekir. İlişkisel veritabanları arasında bile büyük farklar vardır
    • Postgres sonsuza kadar ölçeklenemez ama batch işleme ve tek satır düzeyindeki işlemlerle oldukça fazla veriyi kaldırabilir
    • Ben şahsen önce Postgres ile başlar, darboğaz oluşursa o zaman başka bir sisteme geçerim

  • SQL tabanlı event log table yaklaşımının etkili olduğunu düşünüyorum
    Ancak istemci tarafındaki araç eksikliği bir dezavantaj. Kafka'nın kütüphane ekosistemi zengin olduğu için bu konuda avantajlı
    Şirketimiz servisler arası event iletimini SQL tabanlı olarak standartlaştırdı (feedapi-spec)
    Kafka kadar olgun değil ama birden fazla storage engine'i destekleyen ortak bir kütüphane yığınına dönüşme potansiyeli var

    • LLM tabanlı kod üretim araçları geliştikçe bu tür istemci boşluklarını kapatmak kolaylaştı
    • Kafka'yı sevmeyen biri olarak bu yaklaşım bana çok daha cazip geliyor

  • İnsanlar bugünlerde yeni teknolojilere fazla kapılma eğiliminde
    Postgres harika ama soruna uygun aracı kullanmak gerekir
    Postgres pub-sub için tasarlanmadı, Kafka ise bunun için üretildi
    Her ürünün "her şeyi yapmaya çalıştığı" trendden kaçınmak gerekir. Bence herkesin tek bir işi iyi yapan araçlar kullanması daha iyi

  • “Monoton artan offset numarası” uygulamak zor bir problemdir
    Basit sequence'ler, transaction sırası ile commit zamanlaması uyuşmadığında sorun çıkarır

    • Bir yöntem, yalnızca sayaç için ayrılmış bir tablo kullanmak ve aynı transaction içinde lock ile sıralamayı garanti etmektir (referans bağlantı)
    • Lamport Clock veya Vector Clock kullanarak dağıtık ortamda sıralama da garanti edilebilir (Lamport timestamp, Vector clock)
    • Mutlak sıralamayı zorlamaktansa, numaraları batch bazında atamak ya da commit sonrasında ayrı bir sürecin sıralama vermesi daha gerçekçidir
    • “SELECT FOR UPDATE SKIP LOCKED” ile mükerrer işlemeden kaçınmak da mümkündür

  • Kafka benchmark'ının gerçekten yapılıp yapılmadığı şüpheli
    96 vCPU ortamında elde edilen sonuçlar Kafka'nın 4 vCPU ayarıyla da mümkün olabilir
    Postgres performansı anormal derecede yavaş
    Kafka'ya ihtiyaç yoksa kullanmayın ama Postgres ile 5k msg/s övünmenin bir anlamı yok

    • Redpanda (Kafka uyumlu bir implementasyon) bir dizüstü bilgisayarda bile saniyede 250 bin mesaj işler (video bağlantısı)
    • 288 vCPU ortamında bundan daha düşük performans almak israftır
    • Postgres kullanma gerekçesi sadece “zaten elimizde var” ise bunu anlarım ama yeni altyapı eklemeden önce doğrulama yapmak gerekir
    • Kafka az donanımla bile ağ bant genişliği sınırına ulaşır
    • AWS'de tek bir 24xlarge instance ile çalıştırmak verimsizdir; o maliyetle büyük bir Kafka cluster'ı işletilebilir

  • “Yeni teknolojiye takıntılı olanlar” ile “yalnızca öğrendiğine tutunanlar” diye iki uç var
    Gerçekçi mühendis bu ikisinin arasında pragmatik seçimler yapar

    • Ben üçüncü türüm: “eldeki her şey kötü, yeniler de sonunda kötü çıkacak” diye düşünen tip
    • Sonuçta önemli olan probleme makul biçimde bakıp en iyi çözümü bulma tutumudur
    • Örneğin Elasticsearch'ü Postgres ile değiştirmeye çalışmak mümkün olabilir ama arama özelliklerinin olgunluğu açısından ES çok daha üstündür

  • Kafka'nın temel özelliği consumer bazlı offset kontrolüdür
    Birden fazla ekibin aynı topic'i okuduğu ortamlarda bu vazgeçilmezdir
    Offset'i ileri geri alabilmek birçok kez hayat kurtarıcı oldu
    Postgres kuyruğunda bunun desteklenip desteklenmediğini merak ediyorum

    • Her consumer kendi offset'ini yönetse olmaz mı diyenler de var
    • Ama çoğu durumda yüksek throughput gerekmiyorsa Kafka'nın karmaşık offset yönetimine de ihtiyaç olmaz
    • Sonuçta mesele iş gereksinimlerinin hızı ile operasyonel karmaşıklık arasındaki dengedir

  • “Buzzword peşinde koşanlar kampı vs sağduyu kampı” diye bir çerçeve zaten yanlış
    Kafka'yı Postgres ile yeniden uygulamaya çalışmak sağduyu değildir
    Gerçekten Kafka seviyesinde özelliklere ihtiyaç varsa doğrudan Kafka kullanılmalıdır

    • Aslında yapılan şey Kafka'nın tamamını uygulamak değil, sadece basit iki pub-sub sorgusu oluşturmaktı