लवचिक शोधात जटिल रिलेशनल डेटा कसा संचयित केला जातो त्याचे थोडक्यात वर्णन करा

पारंपारिक डेटाबेसमध्ये, डेटा रिलेशनशिपचे वर्णन तीन, एक टू-वन, एक-ते-अनेक आणि अनेक-अनेक-संबंधांपेक्षा अधिक काही नाही. जेव्हा डेटा संबंधांशी संबंधित असतो, तेव्हा टेबल तयार करताना आम्ही सहसा मुख्य परदेशी की जोडतो. डेटा कनेक्शन स्थापित करा, क्वेरी किंवा आकडेवारीमधील दुव्यांद्वारे डेटा पुनर्संचयित करा किंवा त्यांना पूर्ण करा. नंतर आवश्यक परिणाम डेटा पुनर्प्राप्त करा आणि या रिलेशनल डेटाचा आपण कसा वा कसा सामना करावा हे लवचिक शोधात रूपांतरित करा.

आपल्या सर्वांना हे माहित आहे की इलास्टिक सर्च हा एक NoSQL डेटाबेस आहे जो संबंध प्रक्रियेस कमकुवत करतो कारण लुइसिन, एसएस आणि सोलर सारख्या पूर्ण-मजकूर शोध फ्रेमवर्कमध्ये उच्च कार्यक्षमता आवश्यक असते. एकदा जॉइन ऑपरेशन झाल्यावर कामगिरी खूप खराब आहे. शोध चौकट वापरताना, आपण यापुढे रिलेशनल डेटाबेस म्हणून शोध इंजिन वापरू नये.

अर्थात, वास्तविक तारखा नक्कीच संबंधित आहेत. तर मग आपण या रिलेशनल डेटाशी कसे व्यवहार करता आणि आपण ते कसे व्यवस्थापित करता?

प्रत्येकास ठाऊक आहे की जेएसओएन डेटाचे समर्थन करण्यासाठी हे डिझाइन केले गेले आहे, जोपर्यंत मानक जेएसओएन डेटा स्ट्रक्चर कितीही जटिल असो, कितीही स्तरांचे घरटे असले तरी ते ईएस मध्ये संग्रहित केले जाऊ शकतात आणि नंतर क्वेरी आणि विश्लेषण केले जाऊ शकतात. संबंध हाताळण्यासाठी आणि व्यवस्थापित करण्यासाठी या यंत्रणेत तीन मुख्य पद्धती आहेत:

मल्टीलेयर स्ट्रक्चरचा JSON डेटा स्वयंचलितपणे सेव्ह करण्यासाठी प्रथम फिल्ड प्रकार ऑब्जेक्ट आणि अ‍ॅरे [ऑब्जेक्ट] वापरा.

ही एस ची मानक यंत्रणा आहे, याचा अर्थ असा की आम्ही मॅपिंगची व्याख्या केलेली नाही, जटिल JSON डेटा थेट ईएस सर्व्हरमध्ये समाविष्ट करू शकतो, तो यशस्वीरित्या समाविष्ट करू शकतो आणि पुनर्प्राप्तीस समर्थन देऊ शकतो (हे शक्य आहे कारण ते डीफॉल्टनुसार डायनॅमिक मॅपिंग आहे) जोपर्यंत मानक JSON रचना स्वयंचलितपणे रूपांतरित होते, आम्ही निश्चितपणे मॅपिंग प्रकार देखील नियंत्रित करू शकतो. डायनॅमिक मॅपिंग आणि स्टॅटिक मॅपिंगमध्ये स्टॅटिक मॅपिंग देखील कठोर प्रकार, कमकुवत प्रकार, सामान्य प्रकारात विभागले गेले आहे आणि येथे यापुढे विस्तारित केले जाणार नाही. इच्छुक पक्ष अधिकृत वेबसाइटवरून शोधू शकतात) खालीलपैकी एक डेटा म्हणून:

name "नाव": "झच", "ऑटो": [{"मेक": "शनि", मॉडेल: एसएल}, {"मेक": "सुबारू", "मॉडेल": "इम्प्रेझा"}]}

परिणामी मेमरी स्ट्रक्चर खालीलप्रमाणे आहे:

{"नाव": "झच", "कार.मेक": ["शनि", "सुबारू"] "कार.मॉडेल": ["एसएल", "इम्प्रेझा"]}

मूलभूत Lucene मल्टीव्हिल्ड्यूड स्टोरेजसाठी एक नैसर्गिक आधार असल्याने, त्यावरील अ‍ॅरे स्ट्रक्चरसारखे दिसते. खरं तर, हे बहु-मूल्यवान फील्ड म्हणून या क्षेत्रात संग्रहित आहे.

शोध घेताना, चिन्ह संबंधित सामग्री कॉल करू शकेल. अशा डेटा घटकात प्रत्यक्षात डेटा आणि संबंध असतात. हे एक ते अनेक नात्यासारखे दिसते. एका व्यक्तीकडे अनेक मोटारी असतात. वस्तुतः तथापि, ते कठोर संबंध नाही, कारण तळाशी असलेली ल्यूसिन थर सपाट आहे, म्हणून एकाधिक कारमधील डेटा प्रत्यक्षात मिसळला जातो. आपण या व्यक्तीकडून एकट्याने कार घेऊ शकत नाही. डेटा, संपूर्ण डेटा संपूर्ण असल्याने काय ऑपरेशन केले तरी संपूर्ण डेटा परत केला जातो.

दुसरे, बहु-स्तरीय संबंधांसह डेटा संचयित करण्यासाठी नेस्टेड प्रकार [ऑब्जेक्ट] वापरा

परिस्थिती 1 मध्ये आम्ही नोंद घेतली आहे की अ‍ॅरेमध्ये संग्रहित अ‍ॅरे ऑब्जेक्ट्स जवळपास संबंधित नाहीत कारण द्वितीय स्तराचा डेटा विभक्त नाही. आपण वेगळे करू इच्छित असल्यास, डेटा स्ट्रक्चर स्पष्टपणे परिभाषित करण्यासाठी आपल्याला नेस्टेड प्रकार वापरावा लागेल. हा एकमेव मार्ग आहे की दुस second्या शिफ्टचा मल्टी-कार डेटा एकमेकांपासून स्वतंत्र असतो, म्हणजे एखाद्या विशिष्ट कारचा डेटा स्वतंत्रपणे मिळविला जाऊ शकतो किंवा चौकशी केली जाऊ शकते.

समान JSON डेटा:

name "नाव": "झच", "ऑटो": [{"मेक": "शनि", मॉडेल: एसएल}, {"मेक": "सुबारू", "मॉडेल": "इम्प्रेझा"}]}

परिस्थिती 1 मध्ये अंतिम अंतिम प्रकारात डेटा घटक संचयित करते. जर कारचा प्रकार घरटे घोषित केला असेल तर अंतिम एकमध्ये जतन केलेली संख्या 3 दर्शवते. येथे 3 कसे येईल ते सांगा = 1 मूळ कागदजत्र + 2 कार दस्तऐवज, नेस्टेड डिक्लरेशन प्रकार, प्रत्येक उदाहरण एक नवीन कागदजत्र आहे, म्हणून जेव्हा चौकशी केली जाते तेव्हा स्वतंत्रपणे चौकशी केली जाऊ शकते आणि कार्यप्रदर्शन खराब नाही कारण उपपृष्ठात समान डेटा आहे . नकारात्मक बाजू अशी आहे की अपग्रेड खर्च तुलनेने जास्त आहेत. प्रत्येक वेळी उप-दस्तऐवज अद्यतनित केल्यावर, संपूर्ण संरचनेची अनुक्रमणिका पुन्हा तयार केली जाणे आवश्यक आहे. म्हणून, नेस्टेड बहु-स्तरीय संबंध असलेल्या परिदृश्यांसाठी योग्य आहे जे वारंवार अद्यतनित होत नाहीत.

नेस्टेड टाइप डेटा प्रभावी होण्यासाठी विशिष्ट क्वेरी आणि एकत्रित पद्धतीसह वापरला जाणे आवश्यक आहे. सामान्य क्वेरी केवळ स्तर 1 किंवा मूळ पातळीवरील विशेषता क्वेरी करू शकतात. नेस्टेड गुणधर्म तपासले जाऊ शकत नाहीत. आपण हे तपासू इच्छित असल्यास आपल्याला क्वेरी किंवा एकत्रिकरांचा एम्बेड केलेला संच वापरावा लागेल.

नेस्टेड अनुप्रयोगांमध्ये दोन मोड आहेत:

  • नेस्टेड क्वेरी प्रत्येक क्वेरी क्रमवारीसह दस्तऐवजामध्ये वैध आहे
  • नेस्टेड एकत्रीकरण किंवा फिल्टरिंग त्याच स्तरावरील सर्व कागदपत्रे फिल्टर क्रमवारीसह जागतिक स्तरावर वैध आहेत

तिसरे, पालक / मुलाचे नाते

पालक / मुलाची पॅटर्न नेस्टेड पद्धती प्रमाणेच आहे, परंतु अ‍ॅप्लिकेशनचे लक्ष भिन्न आहे.

जेव्हा पालक / मुले संघटना व्यवस्थापित करण्यासाठी वापरल्या जातात तेव्हा ते प्रत्येक शार्डच्या स्मृतीत रिलेशनल टेबल ठेवते. पुनर्प्राप्त करताना, संबंधित डेटा हॅज-पेरेंट आणि हॅसचल्ड फिल्टरद्वारे पुनर्प्राप्त केला जातो. मूळ दस्तऐवज आणि उप-दस्तऐवज या मोडमध्ये वापरले जातात. याची पर्वा न करता, क्वेरी कार्यक्षमता नेस्टेड मोडच्या तुलनेत किंचित कमी आहे कारण समान दस्तऐवजावर पेस्ट केल्यावर मूळ दस्तऐवज आणि उप-दस्तऐवज मार्गात पसरलेले आहेत, परंतु ते त्याच Lucene सेटिंग्ज निर्देशांकात असतील याची शाश्वती नाही, म्हणूनच कॉल कामगिरी काहीसे कमी. प्रत्येक वेळी आपल्यास स्टोरेज रिलेशन टेबलमधून डेटा असोसिएशन माहिती मिळविणे आवश्यक आहे. त्यासाठी वेळही लागतो. नेस्टेड दस्तऐवजांचा फायदा असा आहे की मूळ दस्तऐवज किंवा उप-दस्तऐवज अद्यतनित केला आहे. इतर कागदपत्रांवर परिणाम होत नाही. म्हणूनच, सामान्य बहु-स्तरीय संबंध अद्यतनित करण्यासाठी पालक / मूल मोड वापरणे चांगले.

मूळ दस्तऐवजाचा असाइनमेंट प्रकार:

Assoc "संघटना": Pers "व्यक्ती": Name "नाव": type "प्रकार": "स्ट्रिंग"}}}}

शाखा दस्तऐवजाच्या असाइनमेंटचा प्रकार:

House "घरे": {"_ पालक": Type "प्रकार": "व्यक्ती"}, "अट": type "प्रकार": "स्ट्रिंग"}}}

डेटा घालताना आपण प्रथम मूळ कागदजत्र समाविष्ट करणे आवश्यक आहे:

curl -XPUT लोकल होस्ट: 9200 / चाचणी / व्यक्ती / zach / -d 'name "नाव": "Zach"}

नंतर जेव्हा आपण एखादा उप-दस्तऐवज घालता तेव्हा आपल्याला एक मार्ग फील्ड जोडण्याची आवश्यकता असते:

$ कर्ल-एक्सपोस्ट लोकल होस्टः 9200 / घरे? पालक = zach -d 'state "राज्य": "ओहियो"} l कर्ल -XPOST लोकल होस्ट: 9200 / चाचणी / घरे? पालक = zach -d 'State "राज्य": "दक्षिण कॅरोलिना"}

सारांश:

पद्धत एक:

  1. सोपी, वेगवान आणि शक्तिशाली
  2. एक ते दोन संबंध टिकवून ठेवण्यात चांगले
  3. कोणतीही विशेष विनंती आवश्यक नाही

पद्धत दोन:

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

पद्धत तीन:

  1. एकापेक्षा जास्त रिलेशनशियल डेटा असल्यास, मेमरी पूर्णपणे स्वतंत्र आहे, परंतु ती त्याच शार्डमध्ये आहे, म्हणून वाचन आणि क्वेरी कार्यप्रदर्शन दुसर्‍या पद्धतीच्या तुलनेत किंचित कमी आहे.
  2. आपल्याला अतिरिक्त मेमरी आवश्यक असल्यास, प्रशासकीय संबंधांची सूची ठेवा
  3. दस्तऐवज अद्यतनित केल्याने इतर उप-कागदपत्रांवर परिणाम होणार नाही, म्हणून वारंवार वापरलेले देखावे अद्यतनित केले जाऊ शकतात.
  4. क्रमवारी आणि मूल्यांकन प्रक्रिया अवजड आहेत आणि अतिरिक्त स्क्रिप्ट कार्य समर्थन आवश्यक आहे

प्रत्येक पद्धतीची स्वतःची योग्य अनुप्रयोग परिस्थिती असते. सराव मध्ये, आम्हाला वास्तविक व्यवसायाच्या परिस्थितीनुसार योग्य संचयन पद्धत निवडण्याची आवश्यकता आहे