Iggy.rs - Rust के साथ message streaming बनाना

 (blog.iggy.rs)
3 पॉइंट द्वारा GN⁺ 2024-01-06 | 1 टिप्पणियां | WhatsApp पर शेयर करें

शुरुआत

  • अप्रैल 2023 में, Rust सीखने का निर्णय लिया गया।
  • distributed systems और messaging के अनुभव के आधार पर message streaming platform विकसित करने का फैसला किया गया।
  • messaging systems के आंतरिक कामकाज और डेवलपर्स के trade-offs को समझना इसका उद्देश्य था।
  • Iggy.rs की शुरुआत हुई, जिसका लक्ष्य speed और lightweight message streaming platform बनाना था।

प्रोजेक्ट

  • शुरुआती Iggy ने QUIC protocol का उपयोग करके basic message exchange फीचर उपलब्ध कराया।
  • लगातार prototyping और सुधार के जरिए parallel write/read और independent streams को support करने वाला server लागू किया गया।
  • TCP और HTTP protocol support जोड़ा गया और data synchronization mechanism को optimize करके performance बेहतर की गई।
  • benchmarking के माध्यम से high throughput और low latency की पुष्टि हुई, जिसके बाद इसे long-term project में बदल दिया गया।

टीम

  • Iggy में लगभग 10 सदस्यों की टीम है, जो अलग-अलग हिस्सों में योगदान देती है।
  • core server, SDK, web UI, CLI जैसे विभिन्न प्रोजेक्ट्स में भागीदारी की जा रही है।
  • programming के प्रति जुनून साझा करने वाले, अलग-अलग अनुभव स्तर के डेवलपर्स स्वेच्छा से इसमें शामिल हुए।
  • दुनिया भर से आए external contributors की भागीदारी ने प्रोजेक्ट के प्रति भरोसा और बढ़ाया।

फीचर्स

  • high-performance, टिकाऊ log-based message streaming server।
  • high throughput, low latency, और Rust compiled language के कारण predictable resource usage।
  • multiple streams, topics, partitions support और विभिन्न transport protocols का समर्थन।
  • RESTful API, कई भाषाओं के client SDK, और binary data के साथ सीधे काम करने की सुविधा।
  • configurable server features, consumer offset का server-side storage, और message polling के कई तरीकों का समर्थन।
  • message ordering और horizontal scaling के लिए consumer groups, साथ ही message expiration और deduplication फीचर्स।
  • सभी transport protocols के लिए TLS support, optional data encryption, और message headers का समर्थन।
  • streaming server management के लिए built-in CLI और benchmarking app, तथा single binary deployment।

रोडमैप

  • GitHub Trending page पर आने के बाद users के साथ feature additions पर चर्चा हुई।
  • clustering, low-level I/O, और per-core thread architecture के जरिए performance और reliability बढ़ाने का लक्ष्य है।
  • Raft consensus mechanism पर प्रयोग, io_uring के जरिए I/O operations को बेहतर करना, और monoio runtime के उपयोग की योजना है।

भविष्य

  • general-purpose message streaming platform बनाना और OS तथा hardware limits को चुनौती देना लक्ष्य है।
  • आसान उपयोग वाली integrated platform के रूप में विभिन्न programming languages, CLI, और web UI को support करने की योजना है।
  • community के feedback और ideas के माध्यम से आगे बढ़ने का लक्ष्य है।

GN⁺ की राय

  • Iggy.rs, Rust-आधारित message streaming platform है, जिसका लक्ष्य high performance और low latency है।
  • open source project के रूप में यह दुनिया भर के डेवलपर्स की स्वैच्छिक भागीदारी और योगदान से लगातार बढ़ रहा है।
  • clustering, low-level I/O optimization, और per-core thread architecture जैसी innovative technologies के जरिए distributed systems की performance limits को पार करने की इसकी महत्वाकांक्षी कोशिश दिलचस्प है, और इस क्षेत्र में रुचि रखने वालों के लिए यह बहुत उपयोगी प्रोजेक्ट है।

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

1 टिप्पणियां

 
GN⁺ 2024-01-06
Hacker News की राय
  • ऐसी कहानियाँ ही शुरू में मुझे software की तरफ लेकर आई थीं
    अलग-अलग कारण होने पर भी एक ही लक्ष्य की ओर साथ काम करना, और सिर्फ़ पैसों का इनाम ही एकमात्र मकसद न होना—यह बात आदर्श लगती है
    प्रोजेक्ट के लिए शुभकामनाएँ, और अगर दूसरी alternatives के साथ तुलना हो तो यह समझना आसान होगा कि यह प्रोजेक्ट कहाँ फिट बैठता है
    • शुरुआत भी बिल्कुल इसी तरह हुई थी, और कभी न कभी दूसरे tools के साथ benchmark और comparison भी शामिल करने का इरादा है
  • idea भी अच्छा है और blog post भी
    लेखक विनम्र, ईमानदार और रचनात्मक project leader जैसा लगता है
    • टीम सच में शानदार है
      सबने इस कोशिश में इसलिए साथ आने का फैसला किया क्योंकि वे इसमें मज़ा भी लेना चाहते थे
  • QUIC से शुरुआत करना सच में बहुत तेज़-तर्रार और समझदार चुनाव लगता है
    यह SCTP जैसी उपयोगी multi-streaming देता है, इसलिए starting point के तौर पर अच्छा है, पहले से इस्तेमाल करने लायक अच्छी libraries भी बहुत हैं, और आगे और बेहतर तथा optimized होने की संभावना भी काफ़ी है: https://github.com/xileteam/awesome-quic?tab=readme-ov-file#...
    यह ऐसा स्वाभाविक क्षेत्र है जहाँ सिर्फ़ मौजूदा से थोड़ा बेहतर transport protocol इस्तेमाल करने से भी बड़ा फ़ायदा मिल सकता है, इसलिए आने वाले 10 साल का QUIC रोमांचक लगता है
    • मैं कुछ नया आज़माना चाहता था, इसलिए QUIC से शुरुआत की
      लेकिन अभी implemented TCP protocol QUIC से थोड़ा तेज़ है, शायद इसलिए क्योंकि extra tuning अभी कम हुई है
      और जोड़ूँ तो MacOS पर QUIC, Linux की तुलना में धीमा है
  • यह JetStream का direct competitor लगता है? एक साल से भी कम समय में इतनी प्रगति काफ़ी प्रभावशाली है
    https://docs.nats.io/nats-concepts/jetstream
    • JetStream, Kafka, Redpanda, RabbitMQ Streams, Fluvio जैसी message streaming solutions काफ़ी हैं
  • यह Kafka और Rust में लिखे Kafka competitor Fluvio से कैसे compare होता है, साफ़ नहीं है
    क्या यह RabbitMQ जैसी message queue के ज़्यादा क़रीब है?
    https://www.fluvio.io/
    • यह message stream है, इसलिए Kafka, Redpanda, RabbitMQ Streams plugin के ज़्यादा क़रीब है
      Fluvio एक असली product है और उसके पीछे company भी है, इसलिए वह ज़्यादा mature है, लेकिन Iggy को एक competitive message streaming solution बनाने के लिए हमारे अपने ideas हैं
    • क्या Fluvio का लक्ष्य Flink और Kafka दोनों को replace करना नहीं है? अभी-अभी पता चला, इसलिए समझने की कोशिश कर रहा हूँ
  • कुछ साल पहले मैंने एक दोस्त के साथ Go में ऐसा ही कुछ बनाया था
    https://github.com/thibauts/styx
    • यह काफ़ी similar लगता है
      जानना चाहूँगा कि आपने इस पर काम आगे क्यों नहीं बढ़ाया
  • कभी न कभी इसे आज़माना चाहूँगा। लेकिन उससे पहले शायद मुझे Rust सीखनी पड़ेगी
    और हाँ, site की aesthetic sense मुझे पसंद आई
    • कई SDK हैं, और blog Rust Zola engine का इस्तेमाल करता है
    • blog post में दूसरी programming languages के SDK का भी ज़िक्र है, इसलिए लगता है कि Rust सीखे बिना भी इसका इस्तेमाल किया जा सकता है
  • यह पोस्ट देखकर मुझे Fluvio की शुरुआती दिशा फिर से निकालकर देखने का मन हुआ
    हम एक छोटी टीम हैं, जिसने पिछले कई दशकों में अलग-अलग domains की data-centric applications के साथ लंबा रिश्ता रखा है, और Java व JVM की जगह Rust और WebAssembly आधारित data streaming पर दांव लगा रही है
    जून 2021 में CTO ने Fluvio का vision जिस पोस्ट में समझाया था, वह यहाँ है: https://news.ycombinator.com/item?id=38880743
    comparison से जुड़े सवाल बार-बार आ रहे हैं, इसलिए Fluvio की तरफ़ की सामग्री भी साझा कर सकता हूँ। documentation का काम लंबा है, लेकिन जो अभी हमारे पास है वह बाँट सकता हूँ। Iggy ने भी सच में बहुत अच्छा काम किया है
  • यह सच में शानदार idea और project है
    लेकिन इसे इस्तेमाल करने से पहले मुझे दो बातें समझनी होंगी: server instance एक से ज़्यादा कैसे चलाए जा सकते हैं, और एक से ज़्यादा चलने पर servers के बीच filesystem interaction कैसे होता है
    • blog post में लिखा है कि यह single node पर चलता है। अभी cluster support नहीं है
      जब cluster support आ जाएगा, तब यह Kafka से compete कर सकता है
  • monoio चुनना थोड़ा surprising है
    मेरी जानकारी में इसके लिए nightly compiler चाहिए, और project maintain करने के लिहाज़ से यह अच्छा चुनाव नहीं माना जाता
    • nightly की ज़रूरत तो है, लेकिन features सिर्फ़ पाँच इस्तेमाल होते हैं, और उनमें से एक को external crate जोड़कर हटाया जा सकता है
      बाक़ी भी ज़्यादातर बहुत extreme features नहीं हैं। मैंने code बहुत गहराई से नहीं देखा, लेकिन सब समझ में आने वाला लगता है। उदाहरण के लिए, एक feature standard library API है जो uninitialized container बनाने के लिए है, जिससे copies हटाई जा सकती हैं
      stable पर चलने वाले glommio और monoio की तुलना नहीं की, लेकिन यह दिलचस्प होगा
    • Monoio सबसे high-performance runtime जैसा लगता है और इस्तेमाल में भी आसान है
      इसलिए bleeding edge approach चुनी गई। वैसे भी io_uring और दूसरी optimizations लागू करने में कई महीने और लगेंगे, और core के कुछ हिस्सों को फिर से लिखते हुए per-core thread structure की ओर जाने की संभावना है