- 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 भविष्य के बड़े स्केल विस्तार के लिए तैयार है; कुछ फीचर डिज़ाइन प्रक्रियाओं पर चर्चा के लिए आगे ब्लॉग पोस्ट आएगी
अभी कोई टिप्पणी नहीं है.