DiceDB yayınlandı

 (dicedb.io)
5 puan yazan GN⁺ 2025-03-18 | 1 yorum | WhatsApp'ta paylaş
  • DiceDB, açık kaynaklı, yüksek performanslı, duyarlı bir bellek içi (in-memory) veritabanıdır
  • Ağırlıklı olarak önbellek olarak kullanılır ve sorgu aboneliği (query subscription) aracılığıyla gerçek zamanlı veri güncellemeleri sağlar
  • Modern donanım için optimize edilmiştir; yüksek throughput ve düşük gecikme sunar
  • Kullanımı kolay ve tanıdık bir arayüz sunar; ayrıca açık kaynaktır
  • Performans benchmark'ı
    • Hetzner CCX23 makinesinde (4 vCPU, 16GB RAM), diğer bellek içi veritabanlarıyla karşılaştırmalı throughput ve GET/SET gecikme süreleri
    • Throughput (ops/sec): DiceDB 15655, Redis 12267
    • GET p50(ms): DiceDB 0.227327, Redis 0.270335
    • GET p90(ms): DiceDB 0.337919, Redis 0.329727
    • SET p50(ms): DiceDB 0.230399, Redis 0.272383
    • SET p90(ms): DiceDB 0.339967, Redis 0.331775

İlgili okumalar

1 yorum

 
GN⁺ 2025-03-18
Hacker News görüşleri

  • Bu kodda çok sayıda hata var

    • Örneğin, ExpandID fonksiyonu cycleMap'ten okurken paket düzeyindeki global mutex'i kilitlemiyor
    • NextID fonksiyonu cycleMap'e yazarken paket düzeyindeki global mutex'i kilitliyor
    • Yazmalar kendi aralarında senkronize ediliyor, ancak okumalarla senkronize edilmiyor; bu yüzden ExpandID ile NextID eşzamanlı çağrıldığında yarış durumu oluşabilir
    • Hobi projesi olarak idare eder, ancak üretimde kullanılabilecek bir sistemden oldukça uzak

  • DiceDB kod tabanına bakarken tasarımla ilgili birkaç sorum var

    • Bu projenin hedefini ve tasarım mantığını anlamak istiyorum
    • Ana bellek içi depolamanın kilitli standart bir Go map'i gibi göründüğünü düşünüyorum
    • Bunun yinelemeli geliştirme için geçici bir tercih mi olduğunu, yoksa daha optimize veri yapıları için uzun vadeli bir plan olup olmadığını merak ediyorum
    • DiceDB'nin reaktif mekanizması, özellikle de tüm izleme komutlarının yeniden çalıştırılması, ilgi çekici
    • Eval fonksiyonunun istemci tarafı komutlarını yürüttüğü görülüyor; bu da daha karmaşık izleme komutları için bir temel atıyor gibi duruyor
    • Tüm komutların yeniden çalıştırılmasının arkasındaki temel motivasyonun ne olduğunu merak ediyorum
    • Yeniden çalıştırma hesaplama açısından pahalı olabilir; performans darboğazlarının nasıl ele alındığını merak ediyorum
    • Bu "yeniden çalıştırma" yaklaşımının ölçeklenebilirlik ve tutarlılık açısından diğer yöntemlerle nasıl kıyaslandığını merak ediyorum
    • GET.WATCH dışında daha karmaşık izleme komutlarını destekleme planı olup olmadığını merak ediyorum
    • Bu tasarım tercihinin trade-off'larını ve projenin hedefleriyle ne kadar uyumlu olduğunu merak ediyorum

  • Bu teknolojinin gerçekte ne olduğunu açıklayan bir cümle olup olmadığını merak ediyorum

  • Rastlantı araçlarının veri depolama teknolojilerine isim olarak verilmesi eğlenceli

  • DiceDB, rastgele sonuçlar döndüren şaka amaçlı bir veritabanı adı gibi geliyor

  • 4vCPU ve num_clients=4 koşullarındaki benchmark sonuçları çok farklı görünmüyor

    • Reaktif yapı umut verici görünüyor, ancak cache olarak pratik kullanımı düşük gibi
    • Örneğin, istemci abone durumundayken makine çökerse reaktivitenin ne olacağını merak ediyorum

  • DiceDB ile Redis performans karşılaştırması

    • DiceDB'nin throughput'u saniyede 15655 ops, Redis'in ise 12267 ops
    • GET p50 ve p90 ile SET p50 ve p90 yanıt sürelerinin karşılaştırması

  • GET istekleri için 20ms harcanması bana mantıklı gelmiyor

    • Mevcut açık kaynak implementasyonlarla çok fazla deneyimim yok, ancak önceki işimde bellek içi yanıt süreleri onlarca ila yüzlerce mikrosaniyeydi
    • io_uring kullanıldığında daha iyi zamanlamalar beklerdim
    • NVMe'den okuyup 6 düğüm üzerinde kurtarma yapıldığında onlarca milisaniye sürebilir
    • Tek düğümlü bir RAM veritabanında bu rakamların çıkmasını anlamıyorum

  • Düşük gecikmeli, yüksek throughput'lu açık kaynak anahtar-değer depoları konusunda deneyimi olan var mı?

    • Belirli bir implementasyon önerebilecek biri var mı, merak ediyorum

  • PubSub'ın teslim semantiği hakkında bilgi almak istiyorum

    • Best-effort / en fazla bir kez teslim mi, yoksa yeniden deneme var mı merak ediyorum
    • Mesajın teslim edilebildiği ya da başarısız olabildiği senaryoların neler olduğunu merak ediyorum

  • Hetzner CCX23 makinesinde saniyede 15655 ops, bellek içi bir veritabanı için yavaş

    • Bunun suçu ağ gecikmesine atılamaz
    • supermassivedb.com Go ile yazılmış ve çok daha yüksek performans veriyor
    • Dice'ın darboğazları araştırılmalı

  • Nubmq'ya kıyasla çok daha yavaş