🧚 👆🏻 🔴 NewSQL: SQL कहीं भी नहीं जा रहा है 🌬️ 👨‍👨‍👦‍👦 🤚🏿

NoSQL प्रवृत्ति लगभग 10 साल पुरानी है, और आप किसी भी निष्कर्ष और सामान्यीकरण को सुरक्षित रूप से आकर्षित कर सकते हैं। हम ऐसा करेंगे और NoSQL के विकास के बारे में बात करेंगे।

याद करें कि NoSQL का जन्म कैसे हुआ। आइए देखें कि इसमें क्या अच्छा है और क्या बुरा, और समय की कसौटी पर क्या खरा उतरा है। आइए उन विशेषताओं का विश्लेषण करें जो पहले से ही SQL में हैं, और जो अब NoSQL DBMS में दिखाई देती हैं। हम NoSQL के अद्वितीय मूल्यों को उजागर करते हैं, और कल बाजार पर क्या होगा, इस पर थोड़ा आगे देखें।

और टेंटनूल डीबीएमएस के डेवलपर और वास्तुकार कोन्स्टेंटिन ओसिपोव ( @kostja ), जिन्होंने RIT ++ 2017 में अपनी रिपोर्ट में NewSQL रुझानों के बारे में बात की थी, इससे हमें मदद मिलेगी, क्योंकि वास्तुकार को यह समझना चाहिए कि डेटाबेस की दुनिया में क्या हो रहा है ताकि कम से कम पहिए को मजबूत करें।

स्पीकर के बारे में : अब कोन्स्टेंटिन ओसिपोव टारनटूल पर काम कर रहा है, लेकिन पहले MySQL के विकास में भाग लिया था, और जब कोन्स्टेंटिन ने एक नए डेटाबेस पर काम करना शुरू किया, तो वह बहुत उलझन में था कि ऐसा क्यों किया जाना चाहिए, अगले डेटाबेस की आवश्यकता क्यों थी। विशेष रूप से, NoSQL के लिए रवैया बहुत संदेहपूर्ण था, जैसा कि "अंडर-एसक्यूएल"।

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

योजना

पृष्ठभूमि । याद करें कि NoSQL का जन्म कैसे हुआ, क्या अच्छा है और क्या बुरा है।
देखते हैं कि NoSQL समय की कसौटी पर खड़ा है ।
NoSQL SQL : N1QL और CQL। आइए उन विशेषताओं का विश्लेषण करें जो पहले से ही SQL में हैं, और जो अब NoSQL DBMS में दिखाई देती हैं।
NoSQL पहले से ही मर चुका है, और NewSQL का अभी तक जन्म नहीं हुआ है: NoSQL में SQL से कितनी गर्म, ट्यूब SQL भिन्न होती है।
NoSQL के अद्वितीय मूल्य । हम देखेंगे कि 10 साल के प्रयास में क्या अच्छा हुआ और आगे क्या होगा।
मल्टी-मॉडल डेटाबेस और न्यूएसक्यूएल । चलो थोड़ा आगे देखते हैं कि कल बाजार पर क्या होगा।

NoSQL सिद्धांत

बहुत से लोग अब NoSQL अवधि के लिए छड़ी करने की कोशिश कर रहे हैं, लेकिन यह 2009 में व्यापक रूप से अपनाया गया जब हैशटैग #nosql दिखाई दिया। Last.FM के डेवलपर ने वितरित डेटाबेस मिटैप के लिए इस टैग का आविष्कार किया।

उसके बाद, टैग ने ट्विटर पर लोकप्रियता हासिल करना शुरू कर दिया, और NoSQL निराशा के लिए एक नाली टैंक या फ़नल बन गया, जैसा कि मैं इसे कहता हूं - पारंपरिक डेटाबेस के साथ काम करने के कई वर्षों में जमा हुआ निराशा।

NoSQL हताशा के लिए एक रास्ता है, एक टैग जो हर किसी के पास पर्याप्त SQL सुविधाएँ नहीं है, अपने आप को विनियोजित करता है।

इस हताशा को किसी तरह से संरचित और निर्धारित करने की आवश्यकता है कि ज्यादातर लोग पारंपरिक DBMS में पसंद नहीं करते थे। NoSQL के निर्माण के लिए हम कार्यों के 3 बड़े ब्लॉकों को अलग कर सकते हैं:

क्षैतिज स्केलिंग;
नए डेटा मॉडल;
संगति के नए मॉडल।

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

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

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

डेटा मॉडल और स्केल मॉडल का विलय वास्तव में समस्या है जो रिलेशनल मॉडल का उपयोग करके हल किया गया था। 70 के दशक में आपका स्वागत है।

नए डेटा मॉडल के अलावा, NoSQL ने नए स्थिरता मॉडल लागू किए हैं। हां, हां, फिर से यह प्रसिद्ध कैप-प्रमेय । कैप प्रमेय के बारे में बात करना मुझे हर समय खुश करता है - आखिर इसकी जरूरत किसे है? जैसा कि दूसरी ताजगी का कोई स्टर्जन नहीं है, इसलिए एक को छोड़कर डेटा की स्थिरता के बारे में सवाल का कोई अन्य जवाब नहीं है: डेटाबेस को इस स्थिरता की गारंटी देनी चाहिए । इसलिए, स्थिरता के नए मॉडल भी हैं, मेरी राय में, एक मरने की प्रवृत्ति।

NoSQL आज

जिस थीसिस को मैं सबसे पहले व्यक्त करना चाहता हूं, वह है पूरे NoSQL आंदोलन में बची:

क्षैतिज स्केलिंग;
~~नए डेटा मॉडल~~ दस्तावेज़ और ग्राफ़ डेटा मॉडल;
~~संगति के नए मॉडल।~~

नए डेटा मॉडल के बारे में शोधों में से, लगभग डेढ़ जीवित रहे और स्थिरता मॉडल के बारे में थीसिस पूरी तरह से मर गए।

मौत की टोपी

कुछ संगतता मॉडल क्यों नहीं बच पाए?

● अंतिम स्थिरता: मुद्रास्फीति
कौन एक डेटाबेस का उपयोग करता है जिसमें एक कार्यशील वेक्टर घड़ी होती है और एप्लिकेशन का व्यावसायिक तर्क इस दिशा में सक्षम होता है? - कोई नहीं। कौन डेटाबेस का उपयोग करता है जिसमें CRDT (संघर्ष-मुक्त प्रतिकृति डेटा प्रकार) हैं? Riak का उपयोग कौन कर रहा है? - कोई नहीं। लोग क्या उपयोग करते हैं? अधिक बार PostgreSQL, कम अक्सर अन्य ठिकानों, उदाहरण के लिए, MongoDB।

● MongoDB: परमाणु को अलग-थलग कर दिया जाता है, लेन-देन को 3.xx में जोड़ा जाता है
इस डेटाबेस में अतुल्यकालिक प्रतिकृति है। यह समझने में बहुत आसान बात है, हालांकि, वास्तव में, अतुल्यकालिक प्रतिकृति के 4 प्रकार हैं । लेन-देन डेटा की प्रतिकृति एक स्थानीय रूप से प्रतिबद्ध होने के बाद हो सकती है; इससे पहले कि लेनदेन स्थानीय रूप से प्रतिबद्ध हो।

यही है, मुख्य डेटाबेस के लिए प्रतिबद्ध बिंदु को प्रतिरूप के साथ-साथ विभिन्न तरीकों से भी कमिट किया जा सकता है।

स्थानीय लॉग के लिए एक प्रविष्टि पहले से ही बनाई गई है, लेकिन यह अभी तक प्रतिकृति में प्रवाहित नहीं हुई है। मान लीजिए कि आप कम से कम एक प्रतिकृति के लिए उसके लिए प्रतीक्षा करना चाहते हैं। उड़ गए - का मतलब उड़ान नहीं है। पहुंचे - इसका मतलब यह नहीं है कि यह प्रतिकृति पर स्थानीय पत्रिका को लिखा गया था।

प्रारंभ में, MongoDB में एक मोड था: अनुरोध सर्वर पर आता है, डेटाबेस ने ठीक उत्तर दिया - यह डिस्क पर अभी तक नहीं आया है, न ही लॉगबुक के लिए - यह कहीं नहीं गया। इसके कारण, सब कुछ बहुत तेज़ी से काम करता है, लेकिन फिर उन्होंने इसके लिए MongoDB की आलोचना करना शुरू कर दिया, और बाद में डिफ़ॉल्ट रूप से 3+ जारी किया, आखिरकार, यह पहली बार पत्रिका को लेनदेन लिखना शुरू किया, और उसके बाद ही ग्राहक को एक पुष्टिकरण भेजें।

यही है, यहां तक कि अतुल्यकालिक प्रतिकृति अर्थ मॉडल का एक रस है। इसलिए, डेवलपर्स के विस्तृत चक्र को समझने के लिए संगतता मॉडल बहुत जटिल हैं, और लेनदेन और तुल्यकालिक प्रतिकृति विदेशी मॉडल के वर्गीकरण की जगह ले रहे हैं ।

संगति मॉडल की मृत्यु की पृष्ठभूमि के खिलाफ, वास्तव में अधिक कठोर स्थिरता के विकास में एक दिलचस्प प्रवृत्ति अभी भी है। रेडिस में लेनदेन होते हैं, हालांकि मैं उन्हें लेनदेन नहीं कहूंगा, लेकिन एक वास्तविक लेनदेन की कीमत पर, इसके बिना विवाद है।

आइए देखें NoSQL में लेनदेन का इतिहास। प्रारंभ में, MongoDB ने दस्तावेज़-स्तरीय परमाणुता को लागू किया। तब डेवलपर्स को अनुमति देने के लिए एक अलग निष्पादन मोड जोड़ा गया था, यदि वे वास्तव में चाहते हैं, तो कई दस्तावेजों को परमाणु रूप से अपडेट करें।

● रेडिस लेनदेन
NoSQL के भोर में, डेवलपर को पूरे व्यापार मामले को एक टोकरी-दस्तावेज़ में रखने की पेशकश की गई थी। एक संपूर्ण प्रवाह डोमेन संचालित डिज़ाइन कहलाता है, जो इस विकृति को डिज़ाइन पैटर्न के रैंक तक बढ़ा देता है। वास्तव में, अगर सब कुछ एक दस्तावेज़ में संग्रहीत किया जाता है, तो परमाणुता को सरलता से प्राप्त किया जाता है: आपने एक लेनदेन, एक व्यवसाय प्रक्रिया और एक दस्तावेज़ में एक परमाणु परिवर्तन किया है।

लेकिन यह पता चला है कि यह काम नहीं करता है। भंडारण अतिरेक से बचने के लिए डेटा को सामान्य करने की आवश्यकता है। उन्हें विश्लेषणात्मक प्रश्नों के लिए सामान्यीकृत करने की आवश्यकता है। अंत में, डेटा मॉडल विकसित हो रहा है - और दस्तावेज़ जो कल एक व्यवसाय परिदृश्य के लिए आवश्यक सभी जानकारी को बचा सकता है, आज इसे विस्तारित और पूरक करने की आवश्यकता है।

क्या परमाणु की समस्याएं प्रदर्शित होती हैं? कितनी बारीकी से डेटा मॉडल स्थिरता मॉडल से संबंधित हैं - लेनदेन और सिंक्रोनस प्रतिकृति के आगमन से NoSQL के अधिकांश मॉडल अनावश्यक हो जाते हैं।

डेटा मॉडल

अब अगली कहानी के बारे में बात करते हैं - डेटा मॉडल के साथ कहानी।

SQL के बाद आविष्कार किए गए डेटा मॉडल के समूह:

मुख्य मूल्य
दस्तावेज़ की;
वाइड कॉलम स्टोर;
डेटा संरचना सर्वर (रेडिस के लिए);
ग्राफ़ डेटाबेस।

कूल! हमारे पास बहुत सारे डेटा मॉडल हैं! और वे कितने अच्छे हैं?

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

Hyperconvergence हमारे जीवन में इतनी अच्छी तरह से आ गई है कि आज भी खड़ी स्केल्ड मशीनों के अंदर, यदि कोई हो, पहले से ही क्षैतिज रूप से स्केलेबल सॉफ्टवेयर है - तो देखो, PureStorage कैसे काम करता है या, अगर आपको याद है, तो रात तक, Nutanix। बेशक, वे लोगों को अलमारियाँ बेचते हैं, लेकिन इन अलमारियाँ एक होस्टिंग प्रदाता में साधारण रैक की तरह अंदर व्यवस्थित होती हैं।

यही है, क्षैतिज स्केलिंग एक प्रवृत्ति है जो सभी पर दबाव डालती है, जिसमें नए डेटा मॉडल के आविष्कारक भी शामिल हैं। तो कौन से डेटा मॉडल क्षैतिज स्केलिंग के लिए अच्छे हैं, और कौन से बुरे हैं?

क्षैतिज स्केलिंग के लिए यह अच्छा है या बुरा? जवाब, वास्तव में, काफी विवादास्पद है, हम बाद में इस पर लौटेंगे।

Redis

जब Redis ने Redis क्लस्टर जोड़ा, तो यह पता चला कि सभी डेटा मॉडल ऑपरेशन पैमाने सामान्य रूप से क्षैतिज नहीं हैं।

यह दस्तावेज़ीकरण का एक उद्धरण है जहां वे लिखते हैं कि कुछ उनके लिए एक विशेष शार्क पर काम करता है, और कुछ वास्तव में एक वास्तविक क्लस्टर में काम करता है।

इस दृष्टिकोण की मूलभूत समस्या MySQL की तरह ही है, जिसे हमने उठाया और हाथ मिलाया। यही है, डेवलपर के दो डेटा मॉडल हैं:

एक में, वह संबंधपरक बीजगणित के ढांचे के भीतर सोचता है।
फिर, जब वह स्वतंत्र शार्किंग के बारे में सोचता है, तो वह शार्क-रिलेशनल बीजगणित के डेटा मॉडल में सोचता है।

एक अच्छा डेटा मॉडल सार्वभौमिक होना चाहिए । संबंधपरक बीजगणित के बारे में क्या सुंदर है - एक प्रक्षेपण का परिणाम एक संबंध है, किसी भी ऑपरेटर का परिणाम एक संबंध है। और जैसे ही हम मैन्युअल रूप से क्लस्टर पर MySQL को बनाना शुरू करते हैं, हम खो देते हैं।

हालाँकि, Redis एक Redis क्लस्टर जोड़ता है क्योंकि हर कोई क्षैतिज रूप से स्केल करना चाहता है ।

ग्राफ़ डेटाबेस

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

आइए स्केलिंग ग्राफ DBMSs की समस्या को देखें - SQL DBMSs बहुत समान स्केलिंग बाधाओं का सामना करते हैं।

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

मान लीजिए कि हमने कुछ अलग किया - उन्होंने एक अच्छे शार्डिंग फंक्शन के साथ सब कुछ लिया और तोड़ा। हम एक निश्चित हैश की गणना करते हैं, बेतरतीब ढंग से हमारे क्लस्टर पर सभी डेटा को काफी यादृच्छिक रूप से फैलाते हैं - और हमें एक और समस्या मिलती है।

यदि पिछली योजना में कम से कम कुछ प्रश्नों ने ठीक काम किया है, तो 100% प्रश्न यहां बेवकूफ हैं , क्योंकि अधिकांश डेटाबेस प्रश्न ग्राफ़ ट्रैंगल के साथ जुड़े हुए हैं। नोड से किसी भी चक्कर को कहीं जाना चाहिए, और सबसे अधिक बार, अनुरोध की गणना करने के लिए, आपको दूसरे नोड पर जाने की आवश्यकता है।

विचार लगभग तीव्र होता है, जैसा कि ऊपर चित्र में दिखाया गया है: गुच्छों को ढूंढें और उन्हें अपने नोड्स पर रखें: कसकर जुड़े उपसमुच्चय को एक साथ रखा गया है, कमजोर रूप से जुड़े उपसमुच्चय को रखा गया है।

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

इसलिए, Neo4j द्वारा और बड़े अब क्लासिक SQL डेटाबेस की तरह बढ़े हुए हैं। वे काफी समय से शार्डिंग पर काम कर रहे हैं, वर्णित समस्याओं को हल करने की कोशिश कर रहे हैं।

थीसिस जो मैंने सामने रखी है कि क्षैतिज स्केलिंग सभी पर दबाव डालती है , और सभी डेटा मॉडल इसे लागू करने के लिए जल्द या बाद में मजबूर होंगे। लेकिन कुछ मॉडल हमारे साथ रहेंगे, जबकि कुछ नहीं होंगे।

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

क्या ग्राफ़ डेटाबेस गायब हो जाएंगे? यह अधिक संभावना है कि सभी उत्पादों में दस्तावेजों की तरह कॉलम भी शामिल होंगे । इस प्रवृत्ति को मल्टी-मॉडल डेटाबेस कहा जाता है, और बाद में रिपोर्ट में मैं एक उदाहरण दूंगा कि यह कैसे काम कर सकता है। लेकिन अभी के लिए, मल्टी-मॉडल डेटाबेस के चलन के एक और उदाहरण के रूप में, आइए JSON को देखें।

JSON

नीचे एक उदाहरण दिया गया है कि कैसे एक प्रवृत्ति जो सभी के लिए काम कर रही है।

मैं यह सुनिश्चित करता हूं कि कोई भी डेटाबेस जो JSON को किसी भी तरह से समर्थन देने में सक्षम है, वह JSON का समर्थन करेगा।

शायद मैट्रिक्स कंप्यूटिंग के लिए कुछ डेटाबेस JSON का समर्थन नहीं करेंगे। लेकिन सबसे अधिक संभावना है कि यह काम आएगा। और बाकी सभी निश्चित रूप से होंगे।

	MySQL	PostgreSQL	Redis	काउचबेस	कैसेंड्रा	Neo4J
JSON भंडारण	हां	हां	हां	हां	हां	हाँ!
JSON क्षेत्र ops	हां	हां	हां	हां	नहीं	नहीं
Json क्वेरी	हां	हां	नहीं	हां	हां	नहीं
JSON माध्यमिक सूचकांक	हां	हां	नहीं	हां	नहीं	नहीं

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

इस प्रकार, मल्टी-मॉडल डेटाबेस और विशेष रूप से JSON में एक डेटा प्रकार के रूप में जो लगभग सभी उत्पादों में पाया जाता है, वही है जो NoSQL से गंभीरता से और लंबे समय तक बना रहेगा।

लेकिन अगर सभी डेटाबेस JSON का समर्थन करते हैं, तो आपको NoSQL डेटाबेस की आवश्यकता क्यों है?

केवल एक कहानी बाकी है - क्षैतिज स्केलिंग। हम क्षैतिज रूप से स्केल करना चाहते हैं, और इसीलिए हम MySQL या PostgreSQL के अलावा कुछ और का उपयोग करते हैं।

यह Oracle में थॉमस उलिन, वीपी MySQL इंजीनियरिंग के मुख्य वक्ता हैं, जो MySQL के भविष्य के बारे में बात करते हैं। पोस्टग्रेज समुदाय और अन्य संबंधित उत्पादों में भी यही बात होती है। हाइपर-कंवर्सेशन और क्लाउड कंप्यूटिंग में संक्रमण के कारण क्षैतिज स्केलिंग का दबाव 100% उत्पादों को प्रभावित करता है।

थॉमस कहते हैं कि उनकी दृष्टि उच्च उपलब्धता और बॉक्स के बाहर स्केलेबिलिटी के साथ एक उत्पाद है। हम मुख्य रूप से InnoDB क्लस्टर के लिए उच्च उपलब्धता के बारे में बात कर रहे हैं, यह समूह प्रतिकृति + InnoDB है। ऐसा डेटाबेस कभी नहीं मरता है, भले ही यह हथौड़ा से मारा जाए।

तब थॉमस लिखते हैं " स्केलिंग फीचर्स बेक्ड इन " - "हमने इन सभी फीचर्स को बेक किया।" मुद्दा यह है कि एक्स रिलीज के माध्यम से (मुझे लगता है कि एक्स = 2, 3) वे अपने शुद्ध रूप में MySQL क्लस्टर प्राप्त करेंगे, जो क्लस्टर पर SQL, क्लस्टर में JSON भंडारण का समर्थन करेंगे।

पहले से ही आज MySQL में एक X प्रोटोकॉल है जो MongoDB के समान है और JSON के साथ काम करने के लिए डिज़ाइन किया गया है।

NoSQL में एसक्यूएल

अब दूसरी तरफ से आंदोलन को देखते हैं। मौत को बताने के लिए, आपको न केवल यह देखना होगा कि SQL NoSQL के सिद्धांतों को कैसे अपनाता है, बल्कि इसके विपरीत भी।

	MongoDB	काउचबेस	कैसेंड्रा	Redis
डेटा स्कीमा	हां *	नहीं	हां	नहीं
NULLs / अनुपस्थित मान	हां *	हां	हां	नहीं
मिलती है	हां	हां	नहीं	नहीं
माध्यमिक कुंजी	हां *	हां	हां, लेकिन ...	नहीं
ग्रुप बाय	हां *	हां	नहीं	नहीं
JDBC / ODBC	नहीं	हां	नहीं	नहीं

यहां, वास्तव में, दिलचस्प अंतर्दृष्टि भी हैं। मैंने अपने हिसाब से, नेताओं को लिया। मैं मानता हूँ कि सब कुछ यहाँ नहीं है, उदाहरण के लिए, इलास्टिक भी एक NoSQL नेता है। लेकिन इलास्टिक अभी भी मुख्य रूप से पूर्ण-पाठ खोज का एक समाधान है, इसलिए मैंने इसे तालिका में शामिल नहीं किया।

टाइम्स सीरीज़ डेटाबेस एक ट्रेंड के रूप में जिसे मैं नहीं छूता। आंदोलनों की समय श्रृंखला के बीच एक थीसिस है कि यह ग्राफ डेटाबेस के समान एक अलग आला है, लेकिन यदि आप गहरी खुदाई करते हैं, तो पोस्टग्रैड हुड के नीचे बैठता है।

काउचबेस

मेरी राय में, Couchbase SQL दुनिया से संभावनाओं की सबसे विस्तृत श्रृंखला है। हर कोई जानता है कि काउचबेस मेमकेड है । डोरमांडो ( एलन कासिंडॉर्फ ), मेम्केड के डेवलपर्स में से एक के पास पूरी तरह से अलग उत्पाद दृष्टि थी, जिसमें क्षैतिज झुकाव नहीं था। इसलिए, क्षैतिज रूप से स्केल करने के लिए मेम्चे को फोर्क किया गया। यह अच्छी तरह से चला गया और इसके चारों ओर व्यापार करना शुरू कर दिया, फिर काउचडब और इतने पर और इसके साथ विलय हो गया।

काउचबेस शुरू में खुद से कहता है कि वे एक योजनाबद्ध डेटाबेस हैं । Memcache मूल रूप से एक बहुत ही सरल कुंजी-मूल्य है। अब देखते हैं कि समय के साथ यह स्व-पहचान कैसे बदलती है।

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

इसके अलावा, के रूप में Couchbase धीरे-धीरे आज प्रलेखन से अतीत Memcache के बारे में पूरी कहानी में कटौती, वे भी कल अंततः स्थिरता के बारे में कहानी में कटौती करेंगे, हालांकि आज भी पढ़ने की स्थिरता की कमी के बारे में बहुत सारी कहानियां हैं - माध्यमिक कुंजी अंततः संगत हैं।

लेकिन पकड़ यह है कि काउचबेस में जेडीबीसी / ओडीबीसी है। , Tableau ClickView — , CQL SQL. — SQL.

, .

, - , , , - — , SQL.

, IS MISSING — , IS NULL?

JDBC, ODBC SQL ? 30-40 , SQL- SQL , , : look-in, , ..

, . , , .

, Couchbase JDBC/ODBC — . , — .

Secondary keys

, NoSQL — , — , . OrientDB, , , .

SQL- , ( , ), NoSQL, .

NoSQL- secondary keys. secondary keys?

( — ):

, , . , range-, SQL . range- map/reduce .
. index notes, . range- .., .

, , , , , . , .

. , NoSQL- SQL, , , .

: CockroachDB? : , . , MySQL — legacy. , , ..

, NoSQL- legacy 10 . , , . SQL- , PostgreSQL, , MySQL Couchbase , True NewSQL.

, secondary keys. MongoDB SQL, . , JOINs, , .

Redis No, . Redis , — . , , , .

, Redis — , - . , Redis-, SQL. , Redis SQLite, — storage — Redis', in memory.

NoSQL , , ?

, NoSQL . , , , SQL . SQL .

schemaless , , , waterfall : agile, - . , , CREATE TABLE, .

, online alter table. Oracle , .

SQL , . MongoDB — , .

MongoDB , schemaless. . , , strict. validation level validation action. Validation level , .

, , - . , , . validation action reject, warn: warning, validation action.

. , MongoDB ( Tarantool), .
Cassandra JSON, . — , . , , NoSQL, .

-, NoSQL SQL .

eventually consistent , , , . , — . .

?

, , . BigQuery , , Vertica, .

NoSQL . , SELECT LTP, LTP - Key-value.

, NoSQL- .

SELECT JOIN , , , — ..

NoSQL:

, , , . domain-specific languages .

NoSQL DSL. — RethinkDB ReQL . , — domen specific language. Python, JavaScript .. — . SQL , .

ReQL, . ReQL , , — . RethinkDB, , , , , .

:

Elasticsearch Query Language:
- MIN/MAX/AVG;
- derivative/percentiles/histogram/cumulative sum/serial diff;
JSONIQ;
GraphQL;
SparQL;
Pregel.

, , SQL, . - SQL!

SQL — OLTP , GROUP BY, Window Functions, (recursive). SQL , . ! , , .

, , . , , , , .

, , Pregel — . : , / . - , . , , .

- SQL, , , .

, , , , . .

-

, , . .

ArangoDB, - : , , ( ), , .

, , . . : , .

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

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

UPSERT: ऐसा क्यों है

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

न तो SQL और न ही NoSQL के कथन हैं जो केवल प्रकृति द्वारा लिखे गए हैं। यहां तक कि दुर्व्यवहार करने वाले, जो मोंगोडीबी में हैं, कई मामलों में डेटा भी पढ़ता है। इंसर्ट एक रीड ऑपरेशन भी है, क्योंकि अगर कोई डॉक्यूमेंट में पहले से ही परिभाषित है, तो आपको यह जांचने की जरूरत है कि ऐसी कोई आईडी तो नहीं है।

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

मेरी राय में, एक भी डेटाबेस अब यह प्रदान नहीं करता है, लेकिन अनुकूलित एल्गोरिदम लिखने का आकर्षण इतना महान है कि मैं वास्तव में यह संभावना चाहता हूं। क्योंकि ऑप्टिमाइज़्ड स्टोरेज लिखने के लिए धन्यवाद, LSM ट्रीज़ (RocksDB, LevelDB और अन्य) पढ़ने के बिना प्रदर्शन लिखते हैं, पढ़ने के साथ लिखने के प्रदर्शन की तुलना में परिमाण के 2 ऑर्डर अधिक हैं । प्रति सेकंड 10 हजार अनुरोधों के बजाय, एक नोड पर एक लाख हो सकता है।
यही कारण है कि टाइम सीरीज़ डेटाबेस अब जीत रहा है क्योंकि उनके पास इस शब्दार्थ अंतर की कमी है। उनमें आने वाली डेटा स्ट्रीम स्पष्ट रूप से एक टाइम सीरीज़ के रूप में परिभाषित की जाती है और विशेष रूप से डेटाबेस में बहुत जल्दी और कॉम्पैक्ट रूप से लिखी जाती है। क्योंकि आपको विशिष्टता सत्यापित करने की आवश्यकता नहीं है। यह तीव्रता का एक क्रम है, क्योंकि पारंपरिक डेटाबेस में ऐसा कोई शब्दार्थ संचालन नहीं है जो केवल लिखा जाएगा।

मुझे लगता है कि यह दिखाई देगा।

यह सब आगे कहां जाता है? यदि आप बहुत दूर देखते हैं, तो नवीनता NoSQL और NewSQL पर नहीं रुकती है। सूचना के बारे में हमारी समझ लगातार विकसित हो रही है।

मेरी राय में, भविष्य के सबसे महत्वपूर्ण रुझानों में से एक यह है कि हम जानकारी को कम से कम हटा देंगे।

इसके लिए, उत्पादों की एक पूरी श्रृंखला का जन्म होता है, जिन्हें अस्थायी डेटाबेस कहा जाता है।

NewSQL के बाद: टेम्पोरल डेटाबेस

नीचे Microsoft SQL Server के स्क्रीनशॉट हैं। यह एक डेटाबेस है जो आपको एक समय में प्रश्न पूछने की अनुमति देता है: वर्तमान स्थिति के लिए चयन है, लेकिन अतीत में कुछ तारीख के लिए चयन करना अभी भी संभव है।

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

आंतरिक संरचना के दृष्टिकोण से, यह वास्तव में इतिहास के साथ मुख्य तालिका और तालिका है। प्रत्येक पंक्ति दो बार सिस्टम से ज्ञात होती है। ये आपके द्वारा जोड़े गए केवल दो कॉलम नहीं हैं, लेकिन डेटा जो सिस्टम स्वचालित रूप से समर्थन करता है:

जिस समय रिकॉर्ड को डेटाबेस में जोड़ा गया था,
घटना का समय।

ये अलग-अलग समय हैं, चाहे कितना भी मनोरंजक हो।

मान लीजिए कि इवान इवानोविच की 17 नवंबर को मृत्यु हो गई, और यह रिकॉर्ड 20 नवंबर को डेटाबेस में दर्ज किया गया - इन दोनों समय को ऐसे डेटाबेस में संग्रहीत किया जाता है।

मेरी राय में, यह भी मौलिक प्रवृत्तियों में से एक है। मुझे ऐसा क्यों लगता है? यदि हम द्वितीयक कुंजियों और अंतिम सुसंगतता पर लौटते हैं, तो पूरी तरह से सब कुछ संग्रहीत करने से आप इस समस्या को हल कर सकते हैं।

यदि हमें कभी भी डेटाबेस से कुछ भी हटाने की आवश्यकता नहीं है, तो हमारा डेटाबेस हमेशा सुसंगत है - ऐसी रोचक कहानी!

उपयोगी लिंक

प्रश्न और उत्तर

- क्या एक नया डेटाबेस बनाने पर कोई घटनाक्रम है जो MySQL, PostgreSQL, MongoDB, आदि पर लागू नहीं होगा?

एक अच्छे तरीके से, सवाल यह है: क्या नए डेटाबेस, स्टार्टअप होंगे? मुझे लगता है कि वे कम और कम दिखाई देंगे। तूफान थम गया है, और अब हम जल्द ही प्रस्थान की तुलना में आगमन को देखेंगे, कॉकरोचडीबी आने वाले अंतिम में से एक था।

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

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

यह एक अद्भुत कहानी है कि ग्राफ डेटाबेस के सभी प्रतिनिधि अपने ग्राहकों को बताने के लिए प्यार करते हैं - यह काम नहीं करता है! क्योंकि अनुक्रमणिका को अपडेट करने के कई तरीके हैं, और कई अनुक्रमण विकल्प हैं, लेकिन हर किसी का ग्राफ नहीं है! चलो शांत हो जाओ - जैसे कि सब कुछ संबंधपरक नहीं है, इसलिए हर कोई एक ग्राफ नहीं है।

- आपकी राय में, इलास्टिक और लाइक कहां जाएंगे? मैं इस तथ्य के बारे में बात कर रहा हूं कि वह बहुत ही अजीब समस्याओं को हल करना शुरू कर रहा है - वह लॉग के साथ काम करने के लिए समय श्रृंखला और एक विश्लेषणात्मक आधार का नाटक करने की कोशिश कर रहा है। ऐसा लगता है कि कोई भी इसका उपयोग पाठ खोज के लिए नहीं करता है।

इलास्टिक को कहीं भी ले जाने की ज़रूरत नहीं है क्योंकि इलास्टिक बहुत अच्छा लगता है। यह एक विशिष्ट व्यावसायिक समस्या को हल करता है - यह एक प्रभावी खोज है और इस पारिस्थितिकी तंत्र से जुड़ी हर चीज है।

मुझे लगता है कि सब कुछ मुख्य रूप से इस तथ्य से आता है कि इलास्टिक सब कुछ होने की कोशिश कर रहा है। लेकिन यहाँ प्रश्न टास्क से है, इलास्टिक टास्क बहुत समय श्रृंखला के कार्यों के समान है, इसलिए यह उचित है। लोचदार समान लॉग्स के विशाल सरणियों के माध्यम से खोज करने के लिए अच्छा है, आदि।

एक संकरा मामला है - यह सिर्फ एक पूर्ण-पाठ खोज है, लेकिन आपने इसमें से बहुत कुछ नहीं किया है। पहली जगह में प्रतियोगियों से अंतर करने के लिए और अधिक करने की आवश्यकता है। इसलिए, यह सब हो रहा है।

लेकिन मुझे नहीं लगता कि इलास्टिक कल बैंकिंग लेनदेन करेगा। सब कुछ इस बिंदु पर जाता है कि Couchbase, उदाहरण के लिए, होगा - यदि बैंकिंग लेनदेन नहीं, लेकिन कुछ इतनी तेजी से।

समाचार

बहुत जल्द, 21 जून को, टारेंटूल सम्मेलन मास्को में होगा - या संक्षेप में टी + कॉन्फिडेंस - न केवल टारेंटूल के बारे में, बल्कि सामान्य रूप से इन-मेमोरी कंप्यूटिंग के उपयोग के बारे में एक सम्मेलन ।

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

NewSQL: SQL कहीं भी नहीं जा रहा है