में डेटा मॉडलिंग उतनी स्पष्ट नहीं है जितनी रिलेशनल डेटाबेस के साथ काम करते समय होती है। पारंपरिक रिलेशनल डेटाबेस के विपरीत जो डेटा नॉर्मलाइज़ेशन और SQL जॉइन पर निर्भर करते हैं, इलास्टिक्सर्च को रिश्तों के प्रबंधन के लिए वैकल्पिक तरीकों की आवश्यकता होती है। इलास्टिक्सर्च इलास्टिकसर्च में संबंधों को प्रबंधित करने के लिए चार सामान्य समाधान हैं: अनुप्रयोग-पक्ष जोड़ डेटा विसामान्यीकरण नेस्टेड फ़ील्ड प्रकार और नेस्टेड क्वेरीज़ माता-पिता-बच्चे के रिश्ते इस ब्लॉग में, हम चर्चा करेंगे कि आप नेस्टेड फ़ील्ड प्रकार और पैरेंट-चाइल्ड संबंधों का उपयोग करके संबंधों को संभालने के लिए अपने डेटा मॉडल को कैसे डिज़ाइन कर सकते हैं। हम इन दो तकनीकों के लिए आर्किटेक्चर, प्रदर्शन निहितार्थ और उपयोग के मामलों को कवर करेंगे। नेस्टेड फ़ील्ड प्रकार और नेस्टेड क्वेरीज़ इलास्टिकसर्च नेस्टेड संरचनाओं का समर्थन करता है, जहाँ ऑब्जेक्ट में अन्य ऑब्जेक्ट हो सकते हैं। नेस्टेड फ़ील्ड प्रकार मुख्य दस्तावेज़ के भीतर JSON ऑब्जेक्ट होते हैं, जिनके अपने अलग-अलग फ़ील्ड और प्रकार हो सकते हैं। इन नेस्टेड ऑब्जेक्ट को अलग, छिपे हुए दस्तावेज़ों के रूप में माना जाता है जिन्हें केवल नेस्टेड क्वेरी का उपयोग करके एक्सेस किया जा सकता है। नेस्टेड फ़ील्ड प्रकार उन संबंधों के लिए उपयुक्त हैं जहाँ डेटा अखंडता, नज़दीकी युग्मन और पदानुक्रमिक संरचना महत्वपूर्ण हैं। इनमें एक-से-एक और एक-से-कई संबंध शामिल हैं जहाँ एक मुख्य इकाई होती है। उदाहरण के लिए, एक ही दस्तावेज़ में किसी व्यक्ति और उनके कई पते और फ़ोन नंबरों का प्रतिनिधित्व करना। नेस्टेड फ़ील्ड प्रकारों के साथ, Elasticsearch पूरे दस्तावेज़, साथ ही पैरेंट और नेस्टेड ऑब्जेक्ट को एक ही Lucene ब्लॉक और सेगमेंट पर संग्रहीत करता है। इससे क्वेरी की गति तेज़ हो सकती है क्योंकि संबंध एक दस्तावेज़ में समाहित होता है। नेस्टेड फ़ील्ड प्रकार और नेस्टेड क्वेरी का उदाहरण आइए टिप्पणियों वाले ब्लॉग पोस्ट का एक उदाहरण देखें। हम ब्लॉग पोस्ट के नीचे टिप्पणियों को रखना चाहते हैं ताकि उन्हें एक ही दस्तावेज़ में एक साथ आसानी से क्वेरी किया जा सके। गिटहब जूली-मिल्स { "post_id": "1", "title": "Introduction to Elasticsearch Data Modeling", "content": "Exploring various data modeling options in Elasticsearch.", "comments": [ { "comment_id": "101", "text": "Great overview of data modeling!" }, { "comment_id": "102", "text": "Looking forward to more content." } ] } नेस्टेड फ़ील्ड प्रकार और नेस्टेड क्वेरीज़ के लाभ नेस्टेड ऑब्जेक्ट संबंधों के लाभों में निम्नलिखित शामिल हैं: डेटा को समान ल्यूसीन ब्लॉक और सेगमेंट में संग्रहीत किया जाता है: समान ल्यूसीन ब्लॉक और सेगमेंट में नेस्टेड ऑब्जेक्ट्स को संग्रहीत करने से क्वेरीज़ तेज़ हो जाती हैं, क्योंकि डेटा कोलोकेटेड होता है। डेटा अखंडता: क्योंकि संबंध एक ही दस्तावेज़ के भीतर बनाए रखे जाते हैं, यह नेस्टेड क्वेरीज़ में सटीकता सुनिश्चित कर सकता है। दस्तावेज़ डेटा मॉडल: NoSQL डेटा मॉडल से परिचित डेवलपर्स के लिए आसान है, जहां आप दस्तावेज़ों और उनके भीतर नेस्टेड डेटा की क्वेरी कर रहे हैं। नेस्टेड फ़ील्ड प्रकार और नेस्टेड क्वेरीज़ की कमियाँ : नेस्टेड ऑब्जेक्ट्स वाले दस्तावेज़ के किसी भी भाग पर पूरे दस्तावेज़ को पुनः अनुक्रमित करने की आवश्यकता होती है, जो मेमोरी-गहन हो सकता है, खासकर यदि दस्तावेज़ बड़े हैं या अद्यतन अक्सर होते हैं। अद्यतन अकुशलता अद्यतन, सम्मिलित और हटाने के लिए : यदि आपके पास विशेष रूप से बड़े नेस्टेड फ़ील्ड वाले दस्तावेज़ हैं, तो इसका प्रदर्शन पर प्रभाव पड़ सकता है। ऐसा इसलिए है क्योंकि खोज अनुरोध पूरे दस्तावेज़ को पुनः प्राप्त करता है। बड़े नेस्टेड फ़ील्ड के साथ क्वेरी प्रदर्शन : कई स्तरों वाली नेस्टेड संरचनाओं में क्वेरी चलाना अभी भी जटिल हो सकता है। ऐसा इसलिए है क्योंकि क्वेरी में नेस्टेड क्वेरी के भीतर नेस्टेड क्वेरी शामिल हो सकती हैं, जिससे कम पठनीय कोड बन सकता है। नेस्टिंग के कई स्तर जटिल हो सकते हैं माता-पिता-बच्चे के रिश्ते पैरेंट-चाइल्ड मैपिंग में, दस्तावेज़ों को पैरेंट और चाइल्ड प्रकारों में व्यवस्थित किया जाता है। प्रत्येक चाइल्ड दस्तावेज़ का पैरेंट दस्तावेज़ के साथ सीधा संबंध होता है। यह संबंध चाइल्ड दस्तावेज़ में एक विशिष्ट फ़ील्ड मान के माध्यम से स्थापित होता है जो पैरेंट की आईडी से मेल खाता है। पैरेंट-चाइल्ड मॉडल एक विकेंद्रीकृत दृष्टिकोण को अपनाता है जहाँ पैरेंट और चाइल्ड दस्तावेज़ स्वतंत्र रूप से मौजूद होते हैं। पैरेंट-चाइल्ड जॉइन संस्थाओं के बीच एक-से-कई या कई-से-कई संबंधों के लिए उपयुक्त हैं। एक ऐसे एप्लिकेशन की कल्पना करें जहाँ आप कंपनियों और संपर्कों के बीच संबंध बनाना चाहते हैं और कंपनियों और संपर्कों के साथ-साथ विशिष्ट कंपनियों के संपर्कों को भी खोजना चाहते हैं। एलास्टिकसर्च पैरेंट-चाइल्ड जॉइन को परफॉरमेंस देने वाला बनाता है, क्योंकि यह इस बात पर नज़र रखता है कि कौन से पैरेंट किस चाइल्ड से जुड़े हैं और दोनों एंटिटी एक ही शार्ड पर रहते हैं। जॉइन ऑपरेशन को स्थानीयकृत करके, एलास्टिकसर्च व्यापक अंतर-शार्ड संचार की आवश्यकता से बचता है, जो प्रदर्शन में बाधा बन सकता है। माता-पिता-बच्चे के रिश्तों का उदाहरण आइए ब्लॉग पोस्ट और टिप्पणियों के लिए पैरेंट-चाइल्ड संबंध का उदाहरण लें। प्रत्येक ब्लॉग पोस्ट, यानी पैरेंट, में कई टिप्पणियाँ, यानी चाइल्ड हो सकती हैं। पैरेंट-चाइल्ड संबंध बनाने के लिए, आइए डेटा को इस प्रकार अनुक्रमित करें: PUT my-index-000001 { "mappings": { "properties": { "post_id": { "type": "keyword" }, "post_id": { "type": "join", "relations": { "post": "comment" } } } } } मूल दस्तावेज़ एक पोस्ट होगा जो इस प्रकार दिखाई देगा: { "post_id": "1", "title": "Introduction to Elasticsearch Data Modeling", "content": "Exploring various data modeling options in Elasticsearch." } तब चाइल्ड दस्तावेज़ एक टिप्पणी होगी जिसमें post_id होगी जो उसे उसके पैरेंट दस्तावेज़ से जोड़ेगी। { "comment_id": "101", "text": "Great overview of data modeling!", "post_id": "1" } माता-पिता-बच्चे के रिश्तों के लाभ अभिभावक-बाल मॉडलिंग के लाभों में निम्नलिखित शामिल हैं: : पैरेंट-चाइल्ड रिलेशनशिप में, पैरेंट और चाइल्ड डॉक्यूमेंट अलग-अलग होते हैं और एक अद्वितीय पैरेंट आईडी द्वारा लिंक किए जाते हैं। यह सेटअप रिलेशनल डेटाबेस मॉडल के करीब है और ऐसी अवधारणाओं से परिचित लोगों के लिए अधिक सहज हो सकता है। रिलेशनल डेटा मॉडल जैसा दिखता है : चाइल्ड डॉक्यूमेंट को पैरेंट डॉक्यूमेंट या अन्य चाइल्ड डॉक्यूमेंट को प्रभावित किए बिना जोड़ा, संशोधित या हटाया जा सकता है। यह विशेष रूप से तब लाभदायक होता है जब बड़ी संख्या में चाइल्ड डॉक्यूमेंट को लगातार अपडेट करने की आवश्यकता होती है। ध्यान दें कि चाइल्ड डॉक्यूमेंट को किसी अन्य पैरेंट के साथ जोड़ना अधिक जटिल प्रक्रिया है क्योंकि नया पैरेंट किसी अन्य शार्ड पर हो सकता है। अपडेट दक्षता : चूंकि संतान दस्तावेजों को अलग-अलग संग्रहीत किया जाता है, इसलिए वे अधिक मेमोरी और भंडारण-कुशल हो सकते हैं, विशेष रूप से उन मामलों में जहां महत्वपूर्ण आकार के अंतर वाले कई संतान दस्तावेज हों। विषम संतानों के लिए अधिक उपयुक्त माता-पिता-बच्चे के रिश्तों की कमियाँ माता-पिता-बच्चे के रिश्तों की कमियां इस प्रकार हैं: : अलग-अलग इंडेक्स में दस्तावेज़ों को जोड़ने से क्वेरी निष्पादन के दौरान कम्प्यूटेशनल कार्य बढ़ जाता है, जिससे फिर से प्रदर्शन प्रभावित होता है। नोट करता है कि पैरेंट-चाइल्ड क्वेरीज़ नेस्टेड ऑब्जेक्ट्स की क्वेरी करने की तुलना में 5-10 गुना धीमी हो सकती हैं। महंगी, धीमी क्वेरीज़ इलास्टिकसर्च : पैरेंट-चाइल्ड रिलेशनशिप ज़्यादा मेमोरी और कैश संसाधनों का उपभोग कर सकते हैं। इलास्टिक्सर्च पैरेंट-चाइल्ड रिलेशनशिप का एक मैप बनाए रखता है, जो बड़ा हो सकता है और महत्वपूर्ण मेमोरी का उपभोग कर सकता है, खासकर दस्तावेजों की उच्च मात्रा के साथ। मैपिंग ओवरहेड : चूंकि पैरेंट और चाइल्ड दोनों दस्तावेज़ एक ही शार्ड पर रहते हैं, इसलिए क्लस्टर में असमान डेटा वितरण का संभावित जोखिम है। कुछ शार्ड दूसरों की तुलना में काफी बड़े हो सकते हैं, खासकर अगर कई चाइल्ड वाले पैरेंट दस्तावेज़ हों। इससे में चुनौतियाँ आ सकती हैं। शार्ड आकार प्रबंधन Elasticsearch क्लस्टर को प्रबंधित करने और स्केल करने : यदि आपको आवश्यकता है, तो पैरेंट-चाइल्ड संबंध इस प्रक्रिया को जटिल बना सकते हैं। आपको यह सुनिश्चित करना होगा कि इस तरह के ऑपरेशन के दौरान संबंध अखंडता बनाए रखी जाए। शार्ड रीबैलेंसिंग या नोड अपग्रेड जैसे नियमित क्लस्टर रखरखाव कार्य अधिक जटिल हो सकते हैं। यह सुनिश्चित करने के लिए विशेष ध्यान रखा जाना चाहिए कि इन प्रक्रियाओं के दौरान पैरेंट-चाइल्ड संबंध बाधित न हों। रीइंडेक्सिंग और क्लस्टर रखरखाव डेटा को रीइंडेक्स करने या शार्डिंग रणनीति बदलने की इलास्टिकसर्च के पीछे की कंपनी हमेशा यह सलाह देगी कि आप पैरेंट-चाइल्ड रिलेशनशिप के रास्ते पर जाने से पहले एप्लीकेशन-साइड जॉइन, डेटा डीनॉर्मलाइजेशन और/या नेस्टेड ऑब्जेक्ट्स करें। इलास्टिक नेस्टेड क्वेरीज़ और पैरेंट-चाइल्ड रिलेशनशिप की फ़ीचर तुलना नीचे दी गई तालिका नेस्टेड फ़ील्ड प्रकारों और क्वेरीज़ तथा पैरेंट-चाइल्ड संबंधों की विशेषताओं का संक्षिप्त विवरण प्रदान करती है, ताकि डेटा मॉडलिंग दृष्टिकोणों की तुलना की जा सके। नेस्टेड फ़ील्ड प्रकार और नेस्टेड क्वेरीज़ माता-पिता-बच्चे के रिश्ते परिभाषा किसी ऑब्जेक्ट को किसी अन्य ऑब्जेक्ट के भीतर रखता है पैरेंट और चाइल्ड दस्तावेज़ों को एक साथ जोड़ता है रिश्तों एक-से-एक, एक-से-अनेक एक-से-अनेक, अनेक-से-अनेक क्वेरी गति आम तौर पर पैरेंट-चाइल्ड संबंधों की तुलना में तेज़ होता है क्योंकि डेटा एक ही ब्लॉक और सेगमेंट में संग्रहीत होता है सामान्यतः नेस्टेड ऑब्जेक्ट्स की तुलना में 5-10 गुना धीमी होती है, क्योंकि क्वेरी के समय पैरेंट और चाइल्ड दस्तावेज़ों को जोड़ा जाता है। क्वेरी लचीलापन पैरेंट-चाइल्ड क्वेरीज़ की तुलना में कम लचीला है क्योंकि यह क्वेरी के दायरे को प्रत्येक नेस्टेड ऑब्जेक्ट की सीमाओं के भीतर सीमित करता है क्वेरी करने में अधिक लचीलापन प्रदान करता है क्योंकि पैरेंट या चाइल्ड दस्तावेज़ों को एक साथ या अलग-अलग क्वेरी किया जा सकता है डेटा अपडेट नेस्टेड ऑब्जेक्ट्स को अपडेट करने के लिए पूरे दस्तावेज़ को पुनः अनुक्रमित करना आवश्यक था चाइल्ड डॉक्यूमेंट को अपडेट करना आसान है क्योंकि इसके लिए सभी डॉक्यूमेंट को पुनः अनुक्रमित करने की आवश्यकता नहीं होती है प्रबंध सरल प्रबंधन क्योंकि सब कुछ एक ही दस्तावेज़ में समाहित है अलग-अलग अनुक्रमण और पैरेंट तथा चाइल्ड दस्तावेजों के बीच संबंधों को बनाए रखने के कारण प्रबंधन अधिक जटिल है बक्सों का इस्तेमाल करें पदानुक्रम के कई स्तरों के साथ जटिल डेटा को संग्रहीत और क्वेरी करें ऐसे रिश्ते जहां माता-पिता कम और बच्चे अधिक हों, जैसे उत्पाद और उत्पाद समीक्षा रिलेशनशिप मॉडलिंग के लिए इलास्टिकसर्च के विकल्प जबकि इलास्टिक्सर्च के लिए कई वर्कअराउंड प्रदान करता है, जिसमें नेस्टेड क्वेरीज़ और पैरेंट-चाइल्ड रिलेशनशिप शामिल हैं, यह स्थापित है कि ये मॉडल अच्छी तरह से स्केल नहीं करते हैं। बड़े पैमाने पर अनुप्रयोगों के लिए डिज़ाइन करते समय, मूल SQL जॉइन क्षमताओं, के साथ वैकल्पिक दृष्टिकोण पर विचार करना समझदारी हो सकती है। SQL-स्टाइल जॉइन रॉकसेट रॉकसेट एक खोज और विश्लेषण डेटाबेस है जिसे SQL खोज, एकत्रीकरण और किसी भी डेटा पर जुड़ने के लिए डिज़ाइन किया गया है, जिसमें डीपली नेस्टेड JSON डेटा भी शामिल है। जैसे ही डेटा रॉकसेट में स्ट्रीम किया जाता है, इसे डेटाबेस के कोर डेटा स्ट्रक्चर में एनकोड किया जाता है जिसका उपयोग डेटा को तेज़ी से प्राप्त करने के लिए स्टोर और इंडेक्स करने के लिए किया जाता है। रॉकसेट डेटा को इस तरह से इंडेक्स करता है कि यह अपने SQL-आधारित क्वेरी ऑप्टिमाइज़र का उपयोग करके जॉइन सहित तेज़ क्वेरी की अनुमति देता है। नतीजतन, SQL जॉइन का समर्थन करने के लिए किसी अपफ़्रंट डेटा मॉडलिंग की आवश्यकता नहीं होती है। इलास्टिकसर्च के साथ चुनौतियों में से एक यह है कि डेटा अपडेट होने पर संबंध को कुशल तरीके से कैसे संरक्षित किया जाए। इसका एक कारण यह है कि इलास्टिकसर्च अपाचे ल्यूसीन पर बनाया गया है, जो अपरिवर्तनीय खंडों में डेटा संग्रहीत करता है, जिसके परिणामस्वरूप सभी दस्तावेज़ों को फिर से अनुक्रमित करने की आवश्यकता होती है। रॉकसेट रॉकएसडीबी का उपयोग करता है, जो मेटा द्वारा ओपन-सोर्स किया गया एक कुंजी-मूल्य स्टोर है और डेटा म्यूटेशन के लिए बनाया गया है, ताकि पूरे दस्तावेज़ों को फिर से अनुक्रमित किए बिना फ़ील्ड-स्तरीय अपडेट का कुशलतापूर्वक समर्थन किया जा सके। वास्तविक दुनिया के उदाहरण का उपयोग करके इलास्टिक्सर्च और रॉकसेट की तुलना करना आइए, Elasticsearch में पैरेंट-चाइल्ड संबंध दृष्टिकोण की तुलना Rockset में से करें। SQL क्वेरी उपरोक्त अभिभावक-बाल संबंध उदाहरण में, हमने दो दस्तावेज़ प्रकार बनाकर अनेक टिप्पणियों वाले पोस्ट का मॉडल तैयार किया: पोस्ट या मूल दस्तावेज़ प्रकार टिप्पणियाँ या चाइल्ड दस्तावेज़ प्रकार हमने पैरेंट और चाइल्ड दस्तावेज़ों के बीच संबंध स्थापित करने के लिए एक अद्वितीय पहचानकर्ता, पैरेंट आईडी का उपयोग किया। क्वेरी समय पर, हम किसी विशिष्ट पोस्ट के लिए टिप्पणियाँ प्राप्त करने के लिए Elasticsearch DSL का उपयोग करते हैं। रॉकसेट में, पोस्ट वाले डेटा को एक संग्रह में संग्रहीत किया जाएगा, जो रिलेशनल दुनिया में एक तालिका होगी, जबकि टिप्पणियों वाले डेटा को एक अलग संग्रह में संग्रहीत किया जाएगा। क्वेरी के समय, हम SQL क्वेरी का उपयोग करके डेटा को एक साथ जोड़ देंगे। यहां दोनों दृष्टिकोण एक साथ प्रस्तुत हैं: इलास्टिकसर्च में अभिभावक-बच्चे के रिश्ते POST /blog/posts/1 { "title": "Elasticsearch Modeling", "content": "A post about data modeling in Elasticsearch" } POST /blog/comments/2?parent=1 { "text": "Great post!" } POST /blog/comments/3?parent=1 { "text": "I learned a lot from this." } किसी पोस्ट को उसके शीर्षक और उसकी सभी टिप्पणियों के आधार पर प्राप्त करने के लिए, आपको निम्नलिखित प्रकार से क्वेरी बनानी होगी। GET /posts/_search { "query": { "bool": { "must": [ { "match": { "title": "Exploring Elasticsearch Models" } } ] } }, "inner_hits": { "_source": ["text"], "name": "comments", "path": "comments" } } रॉकसेट में SQL इस डेटा को क्वेरी करने के लिए, आपको बस एक सरल SQL क्वेरी लिखनी होगी। SELECT p.title, p.content, c.text FROM posts p JOIN comments c ON p.post_id = c.post_id WHERE p.post_id = 1; यदि आपके पास कई डेटा सेट हैं जिन्हें आपके एप्लिकेशन के लिए जोड़ने की आवश्यकता है, तो रॉकसेट इलास्टिक्सर्च की तुलना में अधिक सीधा और स्केलेबल है। यह संचालन को भी सरल बनाता है क्योंकि आपको अपने डेटा को फिर से तैयार करने, अपडेट प्रबंधित करने या संचालन को फिर से अनुक्रमित करने की आवश्यकता नहीं होती है। इलास्टिकसर्च में संबंधों का प्रबंधन इस ब्लॉग में नेस्टेड फील्ड प्रकारों और नेस्टेड क्वेरीज़, तथा एलास्टिकसर्च में पैरेंट-चाइल्ड संबंधों का अवलोकन प्रदान किया गया है, जिसका लक्ष्य आपके कार्यभार के लिए सर्वोत्तम डेटा मॉडलिंग दृष्टिकोण निर्धारित करने में आपकी सहायता करना है। नेस्टेड फ़ील्ड प्रकार और क्वेरीज़ एक-से-एक या एक-से-कई संबंधों के लिए उपयोगी हैं जहाँ संबंध एक ही दस्तावेज़ में बनाए रखा जाता है। इसे संबंध प्रबंधन के लिए एक सरल और अधिक स्केलेबल दृष्टिकोण माना जाता है। अभिभावक-बालक संबंध मॉडल एक-से-अनेक से लेकर अनेक-से-अनेक संबंधों के लिए अधिक उपयुक्त है, लेकिन इसमें जटिलता भी बढ़ जाती है, विशेष रूप से तब, जब संबंधों को एक विशिष्ट शार्ड तक सीमित रखने की आवश्यकता होती है। यदि आपके एप्लिकेशन की प्राथमिक आवश्यकताओं में से एक मॉडलिंग संबंध है, तो रॉकसेट पर विचार करना समझदारी हो सकती है। रॉकसेट डेटा मॉडलिंग को सरल बनाता है और SQL जॉइन का उपयोग करके रिलेशनशिप मैनेजमेंट के लिए अधिक स्केलेबल दृष्टिकोण प्रदान करता है। आप आज ही $300 क्रेडिट के साथ करके इलास्टिकसर्च और रॉकसेट के प्रदर्शन की तुलना और तुलना कर सकते हैं। निःशुल्क परीक्षण शुरू
