Elasticsearch और MongoDB को Rust और RocksDB से बदलने का तरीका

 (radar.com)
4 पॉइंट द्वारा GN⁺ 2025-08-10 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • Radar रोज़ाना एक अरब से अधिक API requests संभालने वाला जियोस्पैशियल इंफ्रास्ट्रक्चर प्रदान करता है, और परफॉर्मेंस तथा स्केलेबिलिटी की समस्या हल करने के लिए अपने पुराने Elasticsearch और MongoDB को स्वयं विकसित HorizonDB पर स्थानांतरित कर गया।
  • HorizonDB Rust में बनाया गया है और इसमें RocksDB, S2, Tantivy, FST, LightGBM, FastText जैसे कई ओपन-सोर्स टूल्स को जोड़कर एक हाई-परफॉर्मेंस जियोस्पैशियल डेटाबेस बनाया गया।
  • पुराने ढाँचे में Elasticsearch और MongoDB की स्केलिंग लागत व जटिलता अधिक थी, जिससे संचालन कठिन हो रहा था।
  • HorizonDB सिंगल मल्टीथ्रेडेड प्रोसेस मॉडल पर चलता है और लागत में कटौती, प्रदर्शन सुधार और उच्च विश्वसनीयता हासिल करता है।
  • कुल मिलाकर डेवलपमेंट प्रोडक्टिविटी और ऑपरेशनल दक्षता में बड़ी वृद्धि हुई, जिससे नए डेटा या फीचर्स की त्वरित लागू क्षमता बढ़ गई।
  • डेटा को पहले Apache Spark से प्री-प्रोसेस करके AWS S3 में वर्ज़न-वार सेव किया जाता है, और डेवलपर्स इसे लोकल वातावरण में भी आसानी से रन/टेस्ट कर सकते हैं।
  • इसी तरह Mongo और Elasticsearch क्लस्टरों को बंद करके खर्च में बड़ी कटौती की गई और फीचर डेवलपमेंट की गति व डेटा प्रोसेसिंग दक्षता दोनों में सुधार हुआ।

परिचय एवं पृष्ठभूमि

  • Radar दुनिया भर के सैकड़ों मिलियन डिवाइसों पर प्रतिदिन एक अरब से अधिक API कॉल प्रोसेस करने वाला जियोलोकेशन इंफ्रास्ट्रक्चर प्लेटफॉर्म है
    • मुख्य API: Geocoding, Search, Routing, Geolocation compliance आदि
  • डेटा स्केल और उत्पाद बढ़ने के साथ हाई-परफॉर्मेंस, स्केलेबिलिटी और लागत की समस्या तुरंत महत्वपूर्ण हो गई।
  • इसे हल करने के लिए Rust में लिखा गया HorizonDB अपनाया गया, जो कई लोकेशन-सर्विस फीचर्स को एक ही हाई-परफॉर्मेंस बाइनरी से देता है
    • प्रति कोर 1,000 QPS हैंडलिंग
    • फॉरवर्ड जियोकोडिंग की मीडियन लेटेंसी 50ms, रिवर्स जियोकोडिंग <1ms
    • सामान्य हार्डवेयर पर लाइनियर स्केलिंग संभव

पुराने सिस्टम की सीमाएँ

  • पहले की संरचना: फॉरवर्ड जियोकोडिंग के लिए Elasticsearch और रिवर्स के लिए MongoDB
  • समस्याएँ:
    • Elasticsearch क्वेरी को सभी shards में distribute करती थी और समय-समय पर बैच अपडेट की जरूरत थी
    • MongoDB में बड़े बैच इनजेशन कठिन था, साथ ही अतिरिक्त संसाधन आवंटन और भरोसेमंद rollback फीचर का अभाव था

HorizonDB आर्किटेक्चर लक्ष्य

  • Efficiency - सामान्य हार्डवेयर पर रनिंग, अनुमानित auto-scaling, सभी जियो एंटिटीज़ के लिए एकल डेटा स्रोत
  • Operationality - डेटा एसेट को दिन में कई बार build/प्रोसेस करना, बदलाव और rollback आसान, ऑपरेशन सरल
  • डेवलपर अनुभव - लोकल एनवायरनमेंट में रन करने की क्षमता, बदलाव और टेस्टिंग में आसानी

उपयोग तकनीकी स्टैक

RocksDB, S2, Tantivy, FSTs, LightGBM, FastText जैसे कई ओपन-सोर्स का इस्तेमाल करते हुए डेटा को Apache Spark से प्री-प्रोसेस करके Rust में S3 पर versioned फाइलों के रूप में सेव किया जाता है

  • Rust

    • Mozilla द्वारा विकसित एक सिस्टम प्रोग्रामिंग लैंग्वेज
    • कम्पाइल टाइम और मेमोरी सेफ्टी की गारंटी, बिना garbage collection के भी बड़े इंडेक्स की मेमोरी का पूर्वानुमेय प्रबंधन संभव
    • Null handling, pattern matching जैसी हाई-लेवल abstractions के कारण जटिल सर्च रैंकिंग लॉजिक को आसानी से व्यक्त किया जा सकता है
    • single-process multi-threaded डिज़ाइन, SSD पर सैकड़ों GB डेटा प्रोसेस करने के लिए ऑप्टिमाइज़्ड

  • RocksDB

    • हाई-परफॉर्मेंस LSM ट्री आधारित इन-प्रोसेस स्टोरेज
    • माइक्रोसेकंड-स्तरीय response, बड़े डेटा पर भी स्थिर गति

  • S2

    • Google की spatial indexing लाइब्रेरी जो पृथ्वी को क्वाड्रंट-जैसे विभाजन में बाँटकर point-polygon queries को तेज़ करती है
    • Radar ने C++ S2 लाइब्रेरी के लिए अपना Rust binding बनाया है और इसे जल्द ही ओपन सोर्स में रिलीज़ करेगा

  • FSTs (Finite State Transducers)

    • कार्यकुशल string compression और prefix search डेटा संरचना
    • यह मानकर कि क्वेरी का 80% भाग नियमित “happy-path” होता है, केवल कुछ MB मेमोरी में लाखों paths cache किए जा सकते हैं

  • Tantivy

    • Lucene-जैसी in-process inverted index लाइब्रेरी
    • Elasticsearch जैसी बाहरी सेवा के बजाय इसे अपनाने के कारण:
      • सर्च क्वालिटी - डायनेमिक कीवर्ड एक्सटेंशन जैसी उन्नत खोज को UML communication latency के बिना संभाल पाना
      • ऑपरेशनल सरलता - सब कुछ single प्रोसेस में प्रोसेस होना, बड़े इंडेक्स भी memory mapping से आसान स्केलिंग

  • FastText

    • अपने कॉर्पस और लॉग से train किए गए FastText मॉडल से शब्द embeddings बना कर ML applications में उपयोग करना
    • टाइपो और अज्ञात शब्दों पर मजबूत, साथ ही आसपास के vectors की semantic similarity से सर्च की semantic understanding संभव

  • LightGBM

    • Query intent classification, query-internal attribute tagging जैसी कई LightGBM मॉडल का उपयोग
    • उदाहरण: “New York” जैसी स्थान-संबंधी query में address खोज छोड़ना, जबकि “841 Broadway” के लिए POI/जियो क्षेत्र खोज छोड़ना

  • Apache Spark

    • सैकड़ों मिलियन डेटा पॉइंट्स को 1 घंटे के भीतर high-speed प्रोसेस करने की क्षमता, join/aggregation performance बेहतर करने हेतु jobs को लगातार बेहतर किया गया
    • अंतिम डेटा S3 में सेव होता है, जिससे Amazon Athena या DuckDB जैसे टूल से SQL-based परिणाम खोज संभव है

HorizonDB लागू करने के परिणाम

  • सेवा काफी तेज़, ऑपरेशन्स सरल, और विश्वसनीयता में सुधार
  • डेवलपमेंट टीम नए फीचर और डेटा स्रोतों को एक दिन में लागू कर मूल्यांकन कर सकती है
  • Mongo, Elasticsearch आदि बड़े क्लस्टर और कई microservices बंद करने से हर महीने दसियों हजार डॉलर की बचत हुई
  • Radar भविष्य के बड़े स्केल विस्तार के लिए तैयार है; कुछ फीचर डिज़ाइन प्रक्रियाओं पर चर्चा के लिए आगे ब्लॉग पोस्ट आएगी

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

1 टिप्पणियां

 
GN⁺ 2025-08-10
Hacker News टिप्पणी

  • मुझे इस बात का अफ़सोस है कि इसमें विस्तृत जानकारी कम है और शायद कोई ओपन सोर्स प्लान भी मौजूद नहीं है। अगर आप ES (ElasticSearch) का विकल्प खोजते हुए यह लेख क्लिक करके आए हैं, तो मैं typesense.org और duckdb.org (खासकर spatial प्लगइन सहित) की सिफारिश करना चाहूँगा। दोनों सेवाओं का spatial डेटा पर परफॉर्मेंस बहुत अच्छा है, और DuckDB कम बदलाव वाले डेटा पर production में इस्तेमाल करने के लिए भी बेहद उपयुक्त लगता है। क्लस्टर/शार्डिंग सेटअप में भी यह पूरी तरह ओपन सोर्स है। कोई व्यक्तिगत संबंध नहीं—यह सिर्फ़ मेरे वास्तविक उपयोग अनुभव पर आधारित सुझाव है।

    • ये दोनों प्रोजेक्ट सच में शानदार हैं; हमारी टीम DuckDB को डेटा लेक वैलिडेशन और सरल डेटा प्रोसेसिंग में सक्रिय रूप से इस्तेमाल कर रही है। आगे सिस्टम के अलग-अलग हिस्सों को विस्तार से समझाने वाले अतिरिक्त ब्लॉग पोस्ट जोड़ने की योजना है। एक ही पोस्ट में बहुत ज्यादा सामग्री डालने से पढ़ना कठिन हो सकता है, इसलिए हमने कंटेंट को विभाजित करने का फैसला किया।

    • ऐसे ओपन सोर्स प्रोजेक्ट उपलब्ध होने के लिए हमेशा आभारी रहता हूँ, लेकिन अपने प्रोजेक्ट में इन्हें इंटीग्रेट करना आसान नहीं लगता। पहले हमने duckdb और spatial तथा SQLite extensions को static link करके build करने की कोशिश की थी, लेकिन अलग-अलग SQLite symbol versions की वजह से build फेल हो जाता था, और तभी लगा कि यह काम कठिन है।

    • DuckDB में शार्डिंग या क्लस्टरिंग क्या सच में बिल्कुल नहीं है? अलग से कोई server भी नहीं होता (HTTP Server Extension को छोड़कर)।

    • Typesense का परफॉर्मेंस वाकई शानदार है, और developer experience भी बहुत संतोषजनक।

    • क्या ओपन सोर्स करना चाहिए और क्या नहीं—यह साफ नहीं है। क्या इसे Rust code के तौर पर open-source किया जाना चाहिए? यह खुद को DB कहता है, लेकिन असल में पूरी stack का ही डिटेल्ड वर्णन लगता है।

  • नौकरी के पेज पर पहले बेनिफिट के रूप में 'office काम करने वाली संस्कृति' को हाइलाइट करना मुझे मज़ाकिया लगा; सच में जिज्ञासा है कि commute कैसे कोई benefit हो सकता है।

    • commute बनाम WFH सिर्फ़ travel time का मुद्दा नहीं है; इसमें काम का माहौल, work-life balance आदि कई चीज़ें आती हैं। मेरे अनुभव में, यदि commute 30 मिनट से कम हो और पैदल या साइकिल से जाया जा सके, तो यह बहुत अच्छा लगता है—exercise हो जाती है, सोच साफ़ होती है और घर से काम पर जाने का transition भी आसान होता है। 2020 में जब मैं पूरी तरह remote था, उसी जगह काम और आराम करने के कारण धीरे-धीरे मुश्किल बढ़ी, और रोज़ ऑफिस के बाद एक घंटे की walk से मैं मानसिक तौर पर काफी बेहतर होता था। बस, जब सार्वजनिक परिवहन या हाईवे से एक घंटे से ज्यादा का आना-जाना होता था, तो वह कठिन लगता था।

    • मुझे लगता है कि office culture को वास्तविक लाभकारी बनने के लिए smart लोगों से सीखने का मौका, दोस्त बनाने का मौका, free food/drinks और DDR मशीन जैसी चीज़ें होनी चाहिए। मेरी आखिरी office experience में ऐसा कुछ भी नहीं था; माहौल उल्टा ऐसा था जैसे घर से काम करने को एक बड़े पैमाने पर बढ़ा दिया गया हो—थोड़ा उदास।

    • कुछ लोग office commute को सच में पसंद कर सकते हैं, हर व्यक्ति अलग होता है।

    • मैं WFH से ज्यादा commute को प्राथमिकता देता हूँ—यानी कोई-कोई व्यक्ति निश्चित रूप से मानता है कि commute ही benefit है।

  • मुझे जिज्ञासा है कि यह सिस्टम OSM (OpenStreetMap) डेटा के लिए ओपन सोर्स ElasticSearch/OpenSearch engine Photon में मदद करेगा या नहीं। अधिकांश OSM apps में search अनुभव कमजोर होता है और typos भी ठीक से handle नहीं होते, जबकि Photon ने इस समस्या पर एक छोटा सुधार लाया है। Photon GitHub लिंक

    • इस केस में मुझे लगता है कि LMDB पर बना सिस्टम बेहतर फिट होगा। FYI, OSM Express पहले से ही LMDB का उपयोग करता है। OSM Express Wiki लिंक

  • एक मेटा-टाइप की टिप्पणी है, लेकिन मुझे यह देखकर खुशी होती है कि खुद का data storage/query engine डिजाइन, और उससे जुड़े ब्लॉग पोस्ट फिर से बढ़ रहे हैं। 2010s में ऐसा एक बूम था और हाल में फोकस AI की तरफ़ चला गया था।

    • मुझे लगता है वह बूम AI की वजह से नहीं था; अधिकतर चीज़ें आख़िर में काम की नहीं निकलीं। मौजूदा सिस्टमों को tuning या scaling करके performance निकालना पर्याप्त होता है, इसलिए अत्यधिक specialized custom stack अक्सर जरूरी नहीं रहा। जो company कोई internal storage/query system बेचने का प्लान नहीं रखती, उनके लिए यह आख़िरकार संसाधन-संपन्न कंपनियों में NIH (Not Invented Here) syndrome बन जाता है।

    • नोSQL/alternative databases एक समय में ट्रेंड की तरह फैले, लेकिन बाद में ज्यादातर कंपनियों के लिए Postgres अकेले ही पर्याप्त है—यह बात साफ हो गई और वह उत्साह ठंडा पड़ गया।

    • अभी भी पता नहीं कि सच में आगे कितना innovation बाकी है; प्रयोगात्मक data stores की तुलना में भरोसेमंद और validated उत्पाद बेहतर लगते हैं।

  • article शीर्षक में भाषा नाम “Rust” का होना अजीब लगता है; reader शायद confuse हो जाए कि Rust क्या replace कर रहा है—ElasticSearch या MongoDB।

  • यह article बहुत अधिक इन-डेप्थ नहीं है; उदाहरण के लिए डेटा शार्डिंग स्ट्रैटेजी, indexing और सेवाओं के बीच समयांतराल, फेल नोड हैंडलिंग, तथा distributed systems में latency जैसी कई key बातें नहीं हैं।

  • search डोमेन में काम करने वाले के तौर पर मैं हाल में यह देखना दिलचस्प पाता हूँ कि कितनी कंपनियाँ वास्तव में "ElasticSearch replacement" को target कर रही हैं।

    • लेखक मैं ही हूँ। ऑपरेशनल एंगल से, "distributed system" समस्या को "monolithic system" में बदलने की strong motivation थी। हाल में यह स्पष्ट हुआ कि केवल hardware से भी पर्याप्त संसाधन उपलब्ध हैं, इसलिए हमने RocksDB और Tantivy जैसे embedded storage systems चुने। memory-mapping की मदद से पूरे ग्लोब को कवर करने जैसी स्थिति भी meet की जा सकती है, और cloud में RAM आसान है। ES/Mongo के वर्तमान state को अलग से manage किए बिना ही data backfill और updates सरल हो गए—नए node पर एक ही binary से पूरा reindex करके S3 पर भेज दिया।

    • ElasticSearch cluster को operate और manage करने में अक्सर वास्तविक production database से कहीं अधिक मेहनत और समय लगता है। इसलिए कई scenarios में मैं पूरी ES features वाली setup देने के बजाय कम फीचर्स वाली, simpler और कम टूटने वाली alternative चुनना पसंद करता हूँ।

  • यह देखना रोचक है कि कई कंपनियाँ अपनी ज़रूरत के हिसाब से solutions combine कर रही हैं—खासकर यह कि कई कंपनियाँ शुरुआत में full custom stack बनाने की बजाय उपलब्ध commercial open source tools से शुरू कर रही हैं, यह सकारात्मक है। वैसे, Tantivy से मुझे Quickwit notice हुआ, जो Lucene-based ES जैसा लगता है। Quickwit GitHub लिंक

    • tantivy ही :)

  • Rocks, Level का fork है, और Level data corruption जैसे bugs के लिए काफी जाना-पहचाना नाम है। दोनों systems production में खूब इस्तेमाल हुए, लेकिन जब मैं Level इस्तेमाल कर रहा था तब ops team को service चले रहने के लिए error handling में भारी मेहनत करनी पड़ी। ऐसी company ब्लॉग पोस्ट शायद ही कभी किसी नए stack के drawbacks या गंभीर issues को ईमानदारी से discuss करती हैं; बड़ी कंपनियों के tech talks भी अंततः अपने ही story marketing बन जाते हैं।

    • RocksDB पहले ही LevelDB से अलग हो गया था, और industry तथा academia दोनों में इसका बड़ा सुधार हुआ है। अब मुझे लगता है कि यह LevelDB जैसा toy database नहीं रहा। शायद कुछ अभी अज्ञात drawbacks हों, लेकिन RocksDB में गंभीर issue आने की संभावना मुझे कम लगती है।

    • मेरा अनुभव थोड़ा अलग है: पिछले 4 सालों में हमने हजारों servers (प्रति server कई TB data) पर RocksDB चलाया, और RocksDB से error की कोई घटना नहीं देखी।

  • Elasticsearch keyword देखकर क्लिक किया, लेकिन यह देखकर हैरानी हुई कि मुझे radar.com के बारे में पता ही नहीं था। मुझे इसमें दिलचस्पी हुई क्योंकि मेरी जरूरत के हिसाब से यह एक reasonable price पर autocomplete feature दिखा रहा था।