Postgres kuyruk teknolojisini seçmek

• Postgres Queue iyi olsa da ana akım olmamasının nedeni: diğer kuyruk teknolojilerinin daha büyük ölçeklenebilirlik sunduğuna dair yaygın düşünce
• webapp.io gibi şirketler, ölçeklenebilirlikten çok operasyonel sadeliğe, bakım kolaylığına ve aşinalığa önem vererek Postgres kuyruğunu seçti
• Postgres kuyruk teknolojisinin bileşenleri
  • yeni işleri bildirme ve dinleme (pub/sub) ile karşılıklı dışlama (row locks)
  • bu ikisi, 2016'da çıkan Postgres 9.5'ten beri sağlanıyor
• Postgres'i bu şekilde kullanmanın "hackvari" olduğuna dair sektördeki yaygın düşünceye karşı çıkılıyor ve Postgres'in küçümsenecek bir kuyruk teknolojisi olmadığı savunuluyor
• Uzun süre çalışan işleri işlemek için kuyruk aracı olarak Redis, Apache Kafka, RabbitMQ, Amazon SQS gibi teknolojiler tercih edilegeldi
• Teknoloji sektörünün "ölçek" takıntısı eleştiriliyor; bunun uğruna sadelikten, bakım kolaylığından ve geliştiricinin bilişsel yükünü azaltmaktan vazgeçilmesi sorgulanıyor
• Yazar, teknik karar verirken hâlihazırda kullanılan ve iyi anlaşılan teknolojilerin de değerlendirilmesi gerektiğini öneriyor
• Zaten kullanılan ve iyi anlaşılan "sıkıcı teknolojileri" seçmeyi tavsiye ediyor
• "Çıkış yolunu inşa etmek" kavramı tanıtılıyor; yani iş işleme için uygulama kodunun kuyruktan bağımsız olması gerektiği anlatılıyor
• Yazar, başkalarını da Postgres kuyruk teknolojisini değerlendirmeye ve varsayılan tercih olarak "sıkıcı teknolojileri" benimsemeye teşvik ederek sonuca varıyor

[GN⁺]

Hacker News görüşleri

• Kafka'nın sadeliği, kalıcılığı ve hata toleransı kabul edilse de, dağıtık yapısı çoğu kullanım senaryosunda ek karmaşıklık yaratabilir.
• Postgres kuyruğu, Redis kuyruğunun yerini alabilir, ancak SQS kuyruğunun yerini alamaz.
• Postgres, sistem devreye alındıktan sonra 400 milyondan fazla olayı işlemek için kullanıldı ve günde yaklaşık 1 milyon olayı işledi.
• Sıradan tablolar kullanıp SELECT FOR UPDATE SKIP LOCKED uygulamak, tüm ORM/Query DSL çerçevelerinde çalışan basit bir yaklaşımdır.
• LISTEN/NOTIFY kullanarak PostgreSQL'i bir pub/sub veri yolu olarak kullanmanın başlıca dezavantajı, LISTEN'in bir oturum özelliği olması nedeniyle statement düzeyinde connection pooling ile uyumlu olmamasıdır.
• Postgres'i uygulama kuyruğu olarak kullanmak, işlemsellik avantajı sunduğu için zamanlanmış asenkron işler bundan fayda sağlar.
• Postgres, kuyruk için ölçeklenebilir; ancak AWS, GCP, Azure üzerinde SQS veya başka bir kuyruk yığınını kurmak daha basittir ve amaca daha uygun şekilde tasarlanmıştır.
• Postgres, GitHub CI instance'larında 1200 jobs/s ile benchmark çalıştırdı ve ek worker'larla 5000 jobs/s seviyesine ölçeklendi.
• Elixir'in Oban'ını kullanan Postgres, arka plan işleri etrafındaki işlemsel anlambilimin pratikte doğrulandığı, günlük yüz binlerce ila milyonlarca işi tek tek işlemek için kullanıldı.
• 47M işin işlendiği bir uygulama, VACUUM için SKIP LOCKED, gecikmeli işler, yeniden denemeler, durum güncellemeleri ve "en az bir kez" gibi maliyetli kalıpları uygulamak için indeksli dayanıklı depolamanın avantajlarını vurgular.