DiceDB लॉन्च

 (dicedb.io)
5 पॉइंट द्वारा GN⁺ 2025-03-18 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • DiceDB एक ओपन सोर्स, उच्च-प्रदर्शन, रिएक्टिव in-memory डेटाबेस है
  • इसका मुख्य उपयोग cache के रूप में होता है, और query subscription के माध्यम से real-time data updates प्रदान करता है
  • यह आधुनिक हार्डवेयर के लिए ऑप्टिमाइज़ किया गया है, जिससे उच्च throughput और कम latency मिलती है
  • यह उपयोग में आसान और परिचित इंटरफ़ेस देता है तथा ओपन सोर्स है
  • Performance benchmark
    • Hetzner CCX23 मशीन (4 vCPU, 16GB RAM) पर अन्य in-memory डेटाबेस के साथ throughput और GET/SET latency की तुलना
    • 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

संबंधित पढ़ाई

1 टिप्पणियां

 
GN⁺ 2025-03-18
Hacker News की राय

  • इस कोड में कई bugs हैं

    • उदाहरण के लिए, ExpandID फ़ंक्शन cycleMap से पढ़ते समय package-global mutex को lock नहीं करता
    • NextID फ़ंक्शन cycleMap में लिखते समय package-global mutex को lock करता है
    • writes आपस में synchronized हैं, लेकिन reads के साथ synchronized नहीं हैं, इसलिए ExpandID और NextID को एक साथ call करने पर race condition हो सकती है
    • hobby project के लिए ठीक है, लेकिन production-ready system से काफ़ी दूर है

  • DiceDB codebase को देखकर design पर कुछ सवाल हैं

    • मैं इस project के goal और design logic को समझना चाहता हूँ
    • मुख्य in-memory store एक locked standard Go map जैसा दिखता है
    • यह जानना चाहूँगा कि क्या यह iterative development के लिए अस्थायी विकल्प है, या long term में किसी ज़्यादा optimized data structure की योजना है
    • DiceDB का reactive mechanism, खासकर पूरे watch command का re-execution, दिलचस्प है
    • Eval फ़ंक्शन client-side command चलाता हुआ लगता है, और यह ज़्यादा complex watch command के लिए आधार तैयार करता दिखता है
    • मैं जानना चाहता हूँ कि पूरे command को फिर से चलाने की मुख्य motivation क्या है
    • re-execution computationally महँगा हो सकता है, इसलिए performance bottleneck को कैसे handle किया जाता है, यह जानना चाहूँगा
    • scalability और consistency के लिहाज़ से यह "re-execution" approach दूसरी methods की तुलना में कैसी है, यह भी जानना चाहूँगा
    • GET.WATCH के अलावा क्या और complex watch command support करने की योजना है, यह भी जानना चाहूँगा
    • इस design choice के trade-offs क्या हैं और क्या यह project के goals के साथ align करता है, यह जानना चाहूँगा

  • मैं जानना चाहता हूँ कि क्या कहीं ऐसा कोई वाक्य है जो समझाए कि यह तकनीक वास्तव में है क्या

  • data storage technology के नाम के रूप में chance के tool का इस्तेमाल करना मज़ेदार है

  • DiceDB नाम किसी ऐसे joke database जैसा लगता है जो random result लौटाता हो

  • 4vCPU और num_clients=4 पर benchmark result में बहुत बड़ा फ़र्क नहीं है

    • reactive पहलू promising लगता है, लेकिन cache के रूप में इसकी practicality कम दिखती है
    • उदाहरण के लिए, अगर client subscribe किए हुए हों और machine down हो जाए, तो reactivity का क्या होगा, यह जानना चाहूँगा

  • DiceDB और Redis का performance comparison

    • DiceDB का throughput 15655 ops प्रति सेकंड है, Redis का 12267 ops
    • GET p50 और p90, SET p50 और p90 response time की तुलना

  • यह समझ नहीं आता कि GET request पर 20ms क्यों लग रहे हैं

    • मौजूदा open source implementations के साथ मेरा ज़्यादा अनुभव नहीं है, लेकिन पिछली नौकरी में in-memory response time दर्जनों से लेकर सैकड़ों microseconds तक था
    • io_uring इस्तेमाल करने पर इससे बेहतर timing की उम्मीद होगी
    • NVMe से पढ़कर 6 nodes पर recovery करने में दर्जनों milliseconds लग सकते हैं
    • single-node RAM DB में ऐसे numbers आना समझ से बाहर है

  • मैं जानना चाहता हूँ कि क्या किसी को low-latency, high-throughput open source key-value store का अनुभव है

    • क्या कोई किसी specific implementation की recommendation कर सकता है

  • मैं PubSub की delivery semantics के बारे में जानना चाहता हूँ

    • क्या यह best-effort / at-most-once delivery है, या इसमें retries हैं
    • किन scenarios में message deliver हो सकता है या fail हो सकता है, यह जानना चाहूँगा

  • Hetzner CCX23 मशीन पर 15655 ops प्रति सेकंड in-memory database के हिसाब से धीमा है

    • इसके लिए network latency को दोष नहीं दिया जा सकता
    • supermassivedb.com Go में लिखा गया है और इससे कहीं ज़्यादा performance देता है
    • Dice के bottleneck की जाँच करनी चाहिए

  • Nubmq की तुलना में काफ़ी धीमा है