MongoDB के बंधनों के साथ नीचे

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

और अब कोई JSON के लिए अपने आंशिक समर्थन के साथ Postgres पर लौट रहा है ...

लेकिन, सौभाग्य से, यह पहले से ही जाली है, मानगो का एक पूर्ण-प्रतिस्थापन, एक पूर्ण-अर्ध-संरचित बिग डेटा DBMS AsterixDB पहले से ही हमारे लिए जल्दबाजी कर रहा है। इस परियोजना का नेतृत्व यूसीआई के प्रोफेसर माइकल कैरी ने किया है, जो महान डीबीएमएस के अग्रणी माइकल स्टोनब्रेकर के प्रशिक्षु हैं।

यह परियोजना बिग डेटा के क्षेत्र में एक शोध पहल के रूप में शुरू हुई और शुरू में मैपरेड और एसक्यूएल के लिए एक सामान्य स्टैक बनाने पर ध्यान केंद्रित किया। लेकिन, कुछ साल पहले, यह एक बड़ा डेटा JSON DBMS बनाने का निर्णय लिया गया था। माइकल कैरी के अनुसार, "एस्टरिक्सबेडो मैंगो सही है।" एस्टरिक्सडीबी की मुख्य विशेषताएं क्या हैं?

1. योजना। हां, यह योजना अभी भी उपयोगी है, और आपको इससे पूरी तरह छुटकारा पाने की आवश्यकता नहीं है। मुझे यकीन है कि किसी भी JSON रिपॉजिटरी में, कुछ फ़ील्ड पहले से ज्ञात हैं, फिक्स्ड हैं और उन्हें बदला नहीं जा सकता है। लेकिन स्वाभाविक रूप से, एस्टेरिक्स आपको पूरी डेटा योजना को पूरी तरह से डिजाइन करने के लिए मजबूर नहीं करता है। आप बिना स्कीम के रह सकते हैं। लेकिन, यदि आप थोड़े से क्रम में लाना चाहते हैं, तो हम उन क्षेत्रों को रखते हैं जो डेटा स्कीमा में तय किए जाते हैं और बाकी को "खुला" छोड़ देते हैं। यह क्या देता है? सम्मिलित करने के दौरान डेटा की जाँच करना, अधिक कॉम्पैक्ट स्टोरेज, आपके पास जहां है, उसका एक दृश्य प्रतिनिधित्व।

primerchik:

 ओपन के रूप में टाइप TwitterUserType बनाएँ {
         स्क्रीन-नाम: स्ट्रिंग,
         लैंग: स्ट्रिंग,
         friends_count: int32,
         statuses_count: int32,
         नाम: स्ट्रिंग,
         followers_count: int32
     }

हमने TwitterUserType डेटा प्रकार बनाया, इसमें सभी सूचीबद्ध फ़ील्ड निश्चित हैं, लेकिन चूंकि यह प्रकार खुला है, इसलिए आप अन्य फ़ील्ड्स में मनमाना जोड़ सकते हैं। अब, इस प्रकार के आधार पर, हम "पैरेंट" प्रकार बना सकते हैं:

 टाइप करें TweetMessageType बंद {
         tweetid: स्ट्रिंग,
         उपयोगकर्ता: TwitterUserType,
         प्रेषक-स्थान: बिंदु?
         भेजें-समय: डेटाइम,
         संदर्भित विषय: {{स्ट्रिंग}},
         संदेश-पाठ: स्ट्रिंग
     }

यहां हम "उपयोगकर्ता" फ़ील्ड देखते हैं, जिसका प्रकार TwitterUserType से मेल खाता है। मैंने कोड में चढ़ाई नहीं की है, लेकिन मुझे लगता है कि किसी भी प्रकार के नाम को बताए बिना तुरंत नेस्टेड संरचनाओं का वर्णन करना संभव है। लेकिन, भले ही, मुझे यकीन नहीं है कि इस तरह की कार्यक्षमता जल्द ही दिखाई देगी।

AsterixDB द्वारा समर्थित आह, हाँ, डेटा प्रकार:

• बूलियन
• Int8 / Int16 / Int32 / Int64
• फ्लोट
• दोहरा
• तार
• बिंदु - ज्यामिति
• रेखा - ज्यामिति
• आयत ज्यामिति
• वृत्त - ज्यामिति
• बहुभुज - ज्यामिति
• तिथि
• समय
• datetime
• अवधि / वर्ष-माह-अवधि / दिन-समय-अवधि
• अंतराल - समय अंतराल, AsterixDB समय अंतराल के लिए एलेन के तर्क को लागू करता है, एक भयानक बात है, लेकिन यह उपयोगी हो सकता है

खैर, नेस्टेड प्रकार:

• अभिलेख
• OrderedList
• UnorderedList

2. अनुरोधों की भाषा! मानगो में कभी-कभी, वह समय आता है जब आपको समूह की आवश्यकता होती है, डेटा एकत्र करते हैं, और गणना किए गए स्रोतों द्वारा पूरक स्रोत फ़ील्ड का एक निश्चित सबसेट उत्पन्न करते हैं। फिर एक भयानक सिरदर्द शुरू होता है। इसलिए, AsterixDB में सभी SQL कार्यक्षमता के साथ एक पूर्ण-क्वेरी क्वेरी भाषा है, केवल विशेष रूप से शिथिल संरचित डेटा के लिए डिज़ाइन की गई है। यह कार्यात्मक XQuery क्वेरी भाषा का एक सरलीकरण है जो XML DBMS में उपयोग किया जाता है। मैं पाठकों को XQuery के W3C विनिर्देश पर काम करने के लिए नहीं भेजूँगा, हालाँकि यदि आप चाहें, तो वेलकम के लिए! मैं AQL भाषा (Asterix Query Language) पर एक मिनी ट्यूटोरियल लिखने की कोशिश करूँगा।

क्वेरी भाषा का आधार निर्देश FLOWR (लगभग एक फूल) है: For-Let-OrderBy-Where-Return। हम यहां GroupBy भी डालेंगे, लेकिन थोड़ी देर बाद। इसे SQL में अनुवाद करके हम प्राप्त करते हैं:

SQL में लगभग FROM क्लॉज़ के लिए, यहाँ हम उन संग्रहों का चयन करते हैं जिन्हें हम चलाते हैं। क्योंकि हम उनके मूल्यों के साथ चर की एक तालिका प्राप्त करते हैं, जिसके ऊपर शेष संचालन लागू होते हैं, लगभग SQL में।

उदाहरण के लिए: के बाद

for $x in users, $y in groups

हमें फॉर्म में प्रविष्टियाँ मिलती हैं:

($x : user1, $y : group1), ($x : user1, $y: group2), ...

यह SQL में सामान्य क्रॉस-प्रोडक्ट है।

आज्ञा देना एक अतिरिक्त खंड है, यहां आप नए चर दर्ज कर सकते हैं। यह परिणाम के लिए नए tuples नहीं जोड़ता है, लेकिन बस नए चर और उनके मूल्यों को जोड़ता है।

ऑर्डरबी - सब कुछ सरल है, SQL सॉर्टिंग के बराबर।

कहाँ - फिर से, एक नियमित फ़िल्टर, एसक्यूएल कहाँ का एक पूर्ण एनालॉग।

वापसी - यहाँ हम पूछते हैं कि वास्तव में हम क्या लौटना चाहते हैं। SQL के विपरीत, जहां हम हमेशा कॉलम की एक सूची देते हैं, यहां आप किसी भी JSON संरचनाओं को ब्लॉक कर सकते हैं। और इस क्लॉज में, एक धमाकेदार नेस्टेड क्वेरीज़ के साथ, जो परिणाम के विभिन्न टुकड़ों को उत्पन्न करता है।

मुझे आशा है कि उपरोक्त सभी परेशान नहीं हैं, आइए कुछ उदाहरणों को देखें। सबसे पहले आदिम:

 डाटासेट में फेसबुक उपयोगकर्ता के लिए $ $
 जहां $ user.id = 8
 $ उपयोगकर्ता लौटाएँ

बस FacebookUsers संग्रह का चयन किया, यह Mongo के बराबर है: db.FacebookUsers.find ({"id": 8})

अधिक स्क्रिबल्स हैं, लेकिन यह सरल प्रश्नों के लिए है। जब टिन शुरू होता है, तो अनुरोध को छांटना ज्यादा आसान होगा।

अब अनुरोध अधिक दिलचस्प है, यहां हम एक जुड़ाव करेंगे और आउटपुट में एक नया डेटा प्रकार बनाएंगे:

 डाटासेट में फेसबुक उपयोगकर्ता के लिए $ $
 डेटासेट फेसबुक मेसेजेस में $ संदेश के लिए
 जहाँ $ मैसेज.ऑथोर-आईडी = $ user.id
 वापसी
   {
     "uname": $ user.name,
     "संदेश": $ message.message
   };

सब कुछ स्पष्ट प्रतीत होता है, है ना? उपयोगकर्ताओं / संदेशों के जोड़े के माध्यम से चलाने के लिए, जहां शामिल होने की स्थिति सेट करती है, वापसी फ़ील्ड नाम और संदेश के साथ एक नया JSON ऑब्जेक्ट बनाता है।

अब आइए एक JSON ऑब्जेक्ट में एक उपयोगकर्ता के सभी संदेशों को, अनाम क्षेत्र के साथ समूहीकृत करें:

 डाटासेट में फेसबुक उपयोगकर्ता के लिए $ $
 $ संदेश दें: = 
     डेटासेट फेसबुक मेसेजेस में $ संदेश के लिए
     जहाँ $ मैसेज.ऑथोर-आईडी = $ user.id
     $ message.message वापस करें
 वापसी
   {
     "uname": $ user.name,
     "संदेश": $ संदेश
   };

यहां हमने उपकुंजी को जाने दिया और सभी उपयोगकर्ता संदेशों की एक सूची को $ संदेश चर में सौंपा। उसी को प्राप्त करने के लिए एक और विकल्प:

  डाटासेट में फेसबुक उपयोगकर्ता के लिए $ $
 वापसी
   {
     "uname": $ user.name,
     "संदेश": 
               डेटासेट फेसबुक मेसेजेस में $ संदेश के लिए
               जहाँ $ मैसेज.ऑथोर-आईडी = $ user.id
               $ message.message वापस करें
   }; 

मैं व्यक्तिगत रूप से अनुरोध के दूसरे रूप को अधिक पसंद करता हूं, डेटा "अग्रिम रूप से" तैयार करने और ऑब्जेक्ट में डालने के बजाय, हम तुरंत एक नेस्टेड अभिव्यक्ति लिखते हैं।

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

वास्तव में, हमने AQL की मूल बातें कवर की हैं, हम अंतिम प्रश्न लिखेंगे:

  
   डाटासेट TwitterUser में $ उपयोगकर्ता के लिए
   $ user.name द्वारा अलग
   $ user.followers_count desc द्वारा ऑर्डर
   सीमा २
   $ उपयोगकर्ता लौटाएँ

यहाँ हम कई मानक SQL चिप्स एक साथ देख सकते हैं - अलग, ऑर्डर द्वारा, सीमा। यह स्पष्ट लगता है कि अनुरोध क्या कर रहा है: पहला, यह उपयोगकर्ता के नाम, डुप्लिकेट को हटाता है, पहले 2 मान लौटाता है और परिणाम बनाता है।

क्या भूल गए? इकाइयों? यहां सब कुछ काफी सरल है - समग्र AQL में सिर्फ एक साधारण कार्य है जो एक इनपुट के रूप में मूल्यों की एक सूची लेता है। AsterixDB में सभी परिचित समुच्चय शामिल हैं, और एक साथ 2 संस्करणों में: पूरी तरह से SQL संगत और अधिक मानव (जो याद करता है कि SQL कुल के अंदर NULL को कैसे संभालता है?)। और निश्चित रूप से आप अपना खुद का लिख ​​सकते हैं।

AsterixDB के साथ और क्या अच्छा है? क्वेरी प्रोसेसिंग सिस्टम का आधार - बीजगणित परत - एक लचीली बीजगणितीय प्रणाली है जो भविष्य में वितरित DBMS के लिए उच्च गुणवत्ता वाली लागत आधारित क्वेरी अनुकूलक लिखने की अनुमति देगा। जबकि अनुकूलन विकास के प्रारंभिक चरण में है, यह सूचकांक को अच्छी तरह से उठाता है, लेकिन अभी भी कोई आँकड़े और वास्तविक अनुकूलन नहीं हैं (हालांकि स्वीकार्य परिणाम प्रश्नों में संकेत द्वारा प्राप्त किए जा सकते हैं)। कई प्रकार के Indeskes भी हैं - B- ट्री, कीवर्ड - पूर्ण-पाठ खोज के लिए उल्टे सूचियाँ, ज्यामिति के लिए R-Tree, समान खोजों के लिए n-gram।

AsterixDB जावा में लिखा गया है, आप पहले से ही अपने यूडीएफ (उपयोगकर्ता परिभाषित फ़ंक्शन) को जावा या जाइथॉन में जोड़ सकते हैं, उन लोगों के लिए जो पायथन से प्यार करते हैं।

एस्टेरिक्स में संगति कमजोर है, अलग-अलग दस्तावेजों के स्तर पर ACID, जैसा कि MongoDB में है। दस्तावेजों या संग्रह की एक श्रृंखला को प्रभावित करने वाली कोई लेनदेन सहायता योजना नहीं। जी हां, ऐसा लगता है जैसे यह सभी पर सूट करता है।

खैर, अब मैं आशा की एक चिंगारी आशा करता हूं कि यह संभव होगा, सिद्धांत रूप में, मोंगोबीडी से एक अधिक सामान्य मंच पर जाने के लिए, वरीयता प्राप्त, यह डेवलपर्स के युद्ध के रूप तक इंतजार करना बाकी है।

क्या पूरा होना बाकी है?

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

इसलिए यदि आप किनारे पर इंतजार नहीं करना चाहते हैं, तो आप अपनी आस्तीन ऊपर रोल कर सकते हैं और लोगों को इस शांत चीज़ को पूरा करने में मदद कर सकते हैं।

Asterix DBMS ।