इलास्टिक खोज में जटिल संबंधपरक डेटा को कैसे संग्रहीत करें, इसका संक्षेप में वर्णन करें

पारंपरिक डेटाबेस में, डेटा संबंध का वर्णन तीन, एक-से-एक, एक से कई और कई-से-कई संबंधों से अधिक कुछ भी नहीं है। यदि संबंध से संबंधित डेटा है, तो हम आम तौर पर तालिका बनाते समय मुख्य विदेशी कुंजी जोड़ते हैं। डेटा लिंक स्थापित करें, फिर क्वेरी या सांख्यिकी में जुड़ने के माध्यम से डेटा को पुनर्स्थापित करें या पूरा करें, और अंत में हमें जो परिणाम डेटा की आवश्यकता है उसे प्राप्त करें, फिर ElasticSearch में परिवर्तित करें, इन रिलेशनल डेटा से कैसे या कैसे निपटें।

हम सभी जानते हैं कि ElasticSearch एक NoSQL प्रकार का डेटाबेस है, जो रिश्तों के प्रसंस्करण को कमजोर करता है, क्योंकि फुल-टेक्स्ट सर्च फ्रेमवर्क जैसे ल्यूसिन, एसईसी और सोलर में उच्च प्रदर्शन आवश्यकताएं हैं। एक बार ज्वाइन ऑपरेशन होने के बाद, प्रदर्शन बहुत खराब हो जाएगा, इसलिए खोज ढांचे का उपयोग करते समय, हमें रिलेशनल डेटाबेस के रूप में खोज इंजन का उपयोग करने से बचना चाहिए।

बेशक, वास्तविक डेटा निश्चित रूप से संबंधित है, तो आप इन संबंधपरक डेटा के साथ कैसे निपटते हैं और प्रबंधित करते हैं?

हर कोई जानता है कि जोंस डेटा का समर्थन करने के लिए पैदा हुआ सही है, जब तक कि डेटा की मानक जेसन संरचना, चाहे कितनी भी जटिल हो, चाहे कितनी भी परतें हों, उन्हें संग्रहीत किया जा सकता है, और फिर उन्हें संरक्षित और विश्लेषित किया जा सकता है, पुनः प्राप्त किया जा सकता है। । इस तंत्र में, रिश्तों को संभालने और प्रबंधित करने के तीन मुख्य तरीके हैं:

सबसे पहले, बहु-परत संरचना के जोंस डेटा को स्वचालित रूप से संग्रहीत करने के लिए फ़ील्ड प्रकार के ओब्जेक्ट और सरणी [ऑब्जेक्ट] का उपयोग करें।

यह es का डिफ़ॉल्ट तंत्र है, अर्थात हमने कोई मैपिंग सेट नहीं किया है, सीधे es सर्वर में एक जटिल json डेटा डालें, सफलतापूर्वक सम्मिलित भी कर सकते हैं, और पुनर्प्राप्ति का समर्थन कर सकते हैं, (यह इसलिए किया जा सकता है क्योंकि es डिफ़ॉल्ट गतिशील मैपिंग है , जब तक मानक जसन संरचना डाली जाती है, स्वचालित रूप से रूपांतरित हो जाएगी, निश्चित रूप से, हम मैपिंग प्रकार को भी नियंत्रित कर सकते हैं, जैसे कि डायनेमिक मैपिंग और स्टेटिक मैपिंग के अंदर, स्थिर मैपिंग को भी सख्त प्रकार, कमजोर प्रकार, सामान्य प्रकार, में विभाजित नहीं किया जाता है। यहाँ विस्तार करें आधिकारिक वेबसाइट से सीख सकते हैं) निम्न डेटा में से एक के रूप में:

{
  "नाम": "ज़च",
  "गाड़ी"  : [
    {
      "द मेक": "शनि",
      "मॉडल": "SL"
    },
    {
      "द मेक": "सुबारू",
      "मॉडल": "इम्प्रेसज़ा"
    }
  ]
}

परिणामस्वरूप संग्रहण संरचना निम्न के समान है:

{
  "नाम": "ज़च",
  "car.make": ["शनि", "सुबारू"]
  "car.model": ["SL", "Imprezza"]
}

चूँकि अंतर्निहित ल्यूसिन बहु-मूल्यवान भंडारण के लिए एक प्राकृतिक समर्थन है, इसलिए यह ऊपर एक सरणी संरचना जैसा दिखता है। वास्तव में, es को इस क्षेत्र में बहु-मूल्य वाले क्षेत्र के रूप में संग्रहीत किया जाता है।

फिर, खोज करते समय, प्रतीक संबंधित सामग्री को पुनः प्राप्त कर सकता है। डेटा के ऐसे टुकड़े में वास्तव में डेटा और रिश्ते शामिल हैं। यह एक-से-एक रिश्ते की तरह दिखता है। एक व्यक्ति कई कारों का मालिक है। लेकिन वास्तव में, यह एक सख्त रिश्ता नहीं है, क्योंकि ल्यूसिन की निचली परत समतल होती है, जिससे कई कारों का डेटा वास्तव में एक साथ मिलाया जाता है, आप अकेले इस व्यक्ति से कार नहीं ले सकते। डेटा, क्योंकि पूरा डेटा एक संपूर्ण है, कोई फर्क नहीं पड़ता कि क्या ऑपरेशन पूरे डेटा को वापस कर दिया जाएगा।

दूसरा, बहुस्तरीय संबंधों के साथ डेटा संग्रहीत करने के लिए नेस्टेड [ऑब्जेक्ट] प्रकार का उपयोग करें

परिदृश्य 1 में, हमने इंगित किया है कि सरणी में संग्रहीत सरणी ऑब्जेक्ट कड़ाई से संबंधित नहीं हैं, क्योंकि दूसरी परत के डेटा को अलग नहीं किया गया है। यदि आप अलग करना चाहते हैं, तो आपको डेटा संरचना को स्पष्ट रूप से परिभाषित करने के लिए नेस्टेड प्रकार का उपयोग करना होगा। केवल इस तरह से, दूसरी परत के कई कार डेटा एक दूसरे से स्वतंत्र होते हैं, अर्थात, एक निश्चित कार का डेटा अलग से प्राप्त या पूछताछ किया जा सकता है।

एक ही json डेटा:

{
  "नाम": "ज़च",
  "गाड़ी"  : [
    {
      "द मेक": "शनि",
      "मॉडल": "SL"
    },
    {
      "द मेक": "सुबारू",
      "मॉडल": "इम्प्रेसज़ा"
    }
  ]
}

परिदृश्य 1 में, अंतिम es डेटा के एक टुकड़े को दूसरे प्रकार में संग्रहीत करेगा, और यदि कार के प्रकार को नेस्टेड घोषित किया जाता है, तो अंतिम में संग्रहीत es की संख्या 3 प्रदर्शित करेगी, यहां बताएं कि 3 कैसे आ रहा है = 1 रूट दस्तावेज़ + 2 कार दस्तावेज़, नेस्टेड डिक्लेरेशन प्रकार, प्रत्येक उदाहरण एक नया दस्तावेज़ है, इसलिए इसे क्वेरी करते समय स्वतंत्र रूप से क्वेरी की जा सकती है, और प्रदर्शन खराब नहीं है, क्योंकि es के नीचे एक ही डेटा होगा एक शार्प ल्यूसिन का सेंगमेंट नुकसान यह है कि अद्यतन की लागत अपेक्षाकृत बड़ी है, प्रत्येक उप-दस्तावेज़ अद्यतन को संपूर्ण संरचना के सूचकांक का पुनर्निर्माण करना चाहिए, इसलिए नेस्टेड नेस्टेड बहु-स्तरीय संबंधों के परिदृश्यों के लिए उपयुक्त है जो अक्सर अद्यतन नहीं होते हैं।

नेस्टेड प्रकार के डेटा, आपको प्रभावी होने के लिए इसकी निर्दिष्ट क्वेरी और एकत्रीकरण विधियों का उपयोग करने की आवश्यकता है, साधारण ईएस क्वेरी केवल क्वेरी स्तर 1 या रूट स्तर की विशेषताओं, नेस्टेड विशेषताओं की जांच नहीं की जा सकती है, यदि आप जांचना चाहते हैं, तो आपको एम्बेडेड सेट का उपयोग करना होगा। प्रश्न या एकत्रीकरण।

नेस्टेड एप्लिकेशन के दो मोड हैं:

  • नेस्टेड क्वेरी
    प्रत्येक क्वेरी छँटाई सहित एकल दस्तावेज़ के भीतर मान्य है
  • नेस्टेड एकत्रीकरण या फ़िल्टरिंग
    एक ही स्तर के सभी दस्तावेज विश्व स्तर पर मान्य हैं, जिसमें छँटाई छँटाई भी शामिल है

तीसरा, माता-पिता / बच्चों का रिश्ता

अभिभावक / बच्चों का पैटर्न नेस्टेड के समान है, लेकिन एप्लिकेशन फ़ोकस अलग है।

संघों का प्रबंधन करने के लिए माता-पिता / बच्चों का उपयोग करते समय, es प्रत्येक शार्द की याद में एक संबंधपरक तालिका रखता है। जब पुनर्प्राप्त किया जाता है, तो संबंधित डेटा has_parent और has_child फ़िल्टर द्वारा प्राप्त किया जाता है। इस मोड में, पैरेंट डॉक्यूमेंट और सबडिमेक्शंस का उपयोग किया जाता है। यह स्वतंत्र भी है, क्वेरी का प्रदर्शन नेस्टेड मोड से थोड़ा कम होगा, क्योंकि मूल दस्तावेज़ और सबडैक्जिशन को सम्मिलित किए जाने पर मार्ग के माध्यम से उसी हिस्से में वितरित किया जाएगा, लेकिन यह समान ल्यूसिन सेंगेंडे इंडेक्स में होने की गारंटी नहीं है खंड, इसलिए पुनर्प्राप्ति प्रदर्शन थोड़ा कम है। इसके अलावा, हर बार जब आप पुनः प्राप्त करते हैं, तो आपको मेमोरी संबंध तालिका से डेटा एसोसिएशन की जानकारी प्राप्त करने की आवश्यकता होती है। इसमें एक निश्चित समय भी लगता है। नेस्टेड का लाभ यह है कि मूल दस्तावेज या उप-साक्ष्य अद्यतन किया जाता है। यह अन्य दस्तावेजों को प्रभावित नहीं करता है, इसलिए अक्सर बहु-स्तरीय संबंधों को अपडेट करने के लिए माता-पिता / बच्चों के मोड का उपयोग करना सबसे उपयुक्त है।

मूल दस्तावेज़ का मानचित्रण प्रकार:

{
  "मैपिंग": {
    "व्यक्ति" :{
      "नाम": {
        "टाइप": "स्ट्रिंग"
      }
    }
  }
}

मानचित्रण का प्रकार

{
  "घरों": {
    "_परेंट": {
      "टाइप": "व्यक्ति"
    },
    "राज्य": {
      "टाइप": "स्ट्रिंग"
    }
  }
}

डेटा सम्मिलित करते समय, आपको पहले मूल दस्तावेज़ सम्मिलित करना होगा:

कर्ल -XPUT लोकलहोस्ट: 9200 / टेस्ट / व्यक्ति / zach / -d '
{
  "नाम": "ज़च"
}

तब जब आप एक सबडामेंक्ट सम्मिलित करते हैं, तो आपको एक रूटिंग फ़ील्ड जोड़ने की आवश्यकता होती है:

$ कर्ल -XPOST लोकलहोस्ट: 9200 / घर? माता-पिता = zach -d '
{
  "राज्य": "ओहियो"
}
$ कर्ल -XPOST लोकलहोस्ट: 9200 / परीक्षण / घर? माता-पिता = zach -d '
{
  "राज्य": "दक्षिण कैरोलिना"
}

सारांश में:

विधि एक:

  1. सरल, तेज और उच्च प्रदर्शन
  2. एक-से-एक संबंध बनाए रखने में अच्छा
  3. कोई विशेष पूछताछ की आवश्यकता नहीं है

विधि दो:

  1. चूंकि अंतर्निहित परत को उसी ल्यूसीन सेंगमेंट में संग्रहीत किया जाता है, इसलिए रीड एंड क्वेरी प्रदर्शन तुलना विधि तेज है।
  2. एक एकल उप-सांचे को अद्यतन करने से संपूर्ण डेटा संरचना का पुनर्निर्माण होगा, इसलिए यह अक्सर नेस्टेड दृश्यों को अपडेट करने के लिए उपयुक्त नहीं है।
  3. एक-से-कई और कई-से-कई संग्रहण संबंध बनाए रख सकते हैं

विधि तीन:

  1. एकाधिक संबंधपरक डेटा, भंडारण पूरी तरह से स्वतंत्र है, लेकिन एक ही शार्क में मौजूद है, इसलिए पढ़ने और क्वेरी का प्रदर्शन दूसरी विधि की तुलना में थोड़ा कम है।
  2. अतिरिक्त मेमोरी की आवश्यकता है, प्रबंधन संबंध सूची को बनाए रखें
  3. दस्तावेज़ को अपडेट करने से अन्य उप-दस्तावेज़ प्रभावित नहीं होते हैं, इसलिए यह अक्सर उपयोग किए जाने वाले दृश्यों को अपडेट करने के लिए उपयुक्त है।
  4. सॉर्टिंग और स्कोरिंग ऑपरेशन बोझिल हैं और अतिरिक्त स्क्रिप्ट फ़ंक्शन समर्थन की आवश्यकता होती है

प्रत्येक विधि का अपना उपयुक्त अनुप्रयोग परिदृश्य होता है, इसलिए व्यवहार में, हमें वास्तविक व्यावसायिक परिदृश्य के अनुसार उचित भंडारण विधि का चयन करना होगा