SmoothMQ - SQLite tabanlı Drop-in SQS alternatifi

 (github.com/poundifdef)
13 puan yazan GN⁺ 2024-07-01 | 3 yorum | WhatsApp'ta paylaş
  • SQS'nin doğrudan yerine geçebilen bir Drop-in servis olup geliştirici deneyimini büyük ölçüde iyileştirir
  • İşlevsel bir UI, görünürlük, izleme, mesaj zamanlama ve hız sınırlama özellikleri sunar
  • Herhangi bir bulutta özel bir SQS instance'ı çalıştırabilirsiniz
  • Tek bir Go binary'si olarak dağıtılır ve mevcut SQS istemcileriyle kullanılabilir
  • UI :3000 üzerinde, SQS uyumlu sunucu ise :3001 üzerinde çalışır
  • Tüm dillerdeki SQS istemcileriyle uyumludur
    • Python 
      • import boto3  
# Sadece endpoint_url'i değiştirmeniz yeterli  
sqs = boto3.client("sqs", ..., endpoint_url="http://localhost:3001";)  
sqs.send_message(QueueUrl="...", MessageBody="hello world")
      • Celery ile de sorunsuz çalışır
      • app = Celery("tasks", broker_url="sqs://...@localhost:3001")

GN⁺ görüşü

  • SmoothMQ, SQS'nin işlevlerini genişleterek geliştiricilere daha iyi bir deneyim sunuyor
  • Buluta bağımlı olmadan özel instance çalıştırabilme esnekliği sağlıyor
  • Mevcut SQS istemcilerini aynen kullanabildiğiniz için geçiş maliyeti düşük
  • UI üzerinden kuyrukları ve mesajları kolayca yönetebilmek operasyonel verimliliği artırıyor
  • Yeni bir teknolojiyi devreye alırken mevcut sistemlerle uyumluluğun yeterince değerlendirilmesi gerekiyor

İlgili okumalar

3 yorum

 
aer0700 2024-07-02

SQLite ve Postgres muhtemelen 10 yıl sonra da kullanılacak. Redis için de böyle olacağını düşünüyordum ama bugünlerde artık emin değilim.
 
superwoou 2024-07-02

Bu aralar Redis yerine ne kullanılıyor?
 
GN⁺ 2024-07-01
Hacker News görüşleri

  • k8s, kubernetes, cloud native, self-hosted, edge-enabled teknolojilerinin düşük maliyetle kullanılabilmesi fikri harika

    • rq ve minio’yu yıllardır k8s üzerinde kullandığını, son dönemde ise alternatif olarak SQLite’a dikkat kesildiğini belirtiyor
    • kişisel bulutun önemini vurguluyor ve her şeyi kamu bulutunda yapmanın uygun olmadığını düşünüyor
    • BTLE sensörlerinin doğrudan Apple Watch ile iletişim kurmasının gayet mümkün olduğunu söylüyor
    • bulutun araya girmesinin bir avantaj sağlamadığını, yeni nesil araçlarda bunun düzeltilmesi gerektiğini savunuyor

  • SQLite’ın tek bir sunucuda çalıştığını, çoğu durumda işe yarasa da %100 güvenilir olmadığını belirtiyor

    • kuyruk sunucusu çökerse SQS’nin çalışmaya devam etme olasılığı daha yüksek
    • en iyi senaryoda çalışabilir ama SQS ile aynı güvenilirliği sunmayacaktır

  • ölçek ve benchmark dışında, SQS kullanan özellik/birim test modülleri için faydalı bir araç

  • barındırılan bir kuyruk sistemi hedefleniyor; SQS’den daha ucuz olup performanstan ödün vermemesi amaçlanıyor

    • Backblaze ve Minio’nun S3 alanında başardığı gibi, kuyruk sistemlerinde de benzer bir başarı hedefleniyor

  • AWS API uyumlu servisler yazmayı sevdiğini söylüyor ve Dyna53 projesinden bahsediyor

  • LocalStack ile SQS ve birçok AWS servisi test/geliştirme için kullanılabilir; iyi dokümante edilmiş ve açık kaynaklıdır

  • popüler servisler için basit self-hosted alternatifler üreten projeleri seviyor

    • Litestream ile büyük sorunlar olmadan çalışmasının beklendiğini, backend depolama ayarı yapmadan geçici bir kuyruk sistemi olarak çok iyi olacağını söylüyor

  • proje yapısına dair hızlı bir öneri:

    • models/ dizinindeki tüm struct’ların kök dizine taşınmasını öneriyor
    • bunun paket kullanıcılarının q.Message ve q.Queue gibi kısa ve temiz isimler kullanmasını sağlayacağını, ayrıca kullanıcının kendi "models" paketine sahip olması durumunda isim çakışmasını önleyeceğini belirtiyor

  • ElasticMQ’dan bahsediyor; Docker ortamında SQS simülasyonu için kullandığını söylüyor

  • foreign key desteğinin devre dışı bırakılmasına rağmen veritabanı şemasında neden hâlâ kullanıldığını soruyor

    • "TODO: check for errors" yorumunun ve foreign key constraint kontrollerini kapatıyor gibi görünen kısımların, bunu denemekte tereddüt yaratığını söylüyor