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

PlanetScale एक MySQL सर्वर रहित प्लेटफ़ॉर्म है जो MySQL के क्षैतिज स्केलिंग के लिए डेटाबेस क्लस्टरिंग सिस्टम, Vites को बेचता है। उन्होंने अपना डेटाबेस नहीं लिखा - संभवतः इसमें योगदान दिया, लेकिन उन्होंने इसे नहीं लिखा। विटेस दस्तावेज़ीकरण से:

Vitess 2010 . में बनाया गया था MySQL की मापनीयता चुनौतियों का समाधान करने के लिए जिनका YouTube पर टीम ने सामना किया।

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

पृष्ठभूमि

मेरा प्रारंभिक प्रश्न यह था कि यह क्यों कहता है कि प्लैनेटस्केल डेटाबेस को संदर्भित अखंडता के साथ स्केल करना असंभव है जैसा कि उनके दस्तावेज़ीकरण में कहा गया है कि:

जिस तरह से FOREIGN KEY बाधाओं को MySQL में लागू किया जाता है (या, बल्कि, InnoDB स्टोरेज इंजन में) ऑनलाइन DDL संचालन में हस्तक्षेप करता है। इस विटेस ब्लॉग पोस्ट में और जानें।

एकल MySQL सर्वर क्षेत्र तक सीमित, FOREIGN KEY एक बार जब आपका डेटा बढ़ता है और कई डेटाबेस सर्वर पर विभाजित हो जाता है, तो बाधाओं को बनाए रखना असंभव है। यह आमतौर पर तब होता है जब आप कार्यात्मक विभाजन/शार्डिंग और/या क्षैतिज शार्डिंग पेश करते हैं।

इसने मुझे सोचने के लिए प्रेरित किया:FOREIGN KEY करें बाधाएं सामान्य रूप से मापनीयता को प्रभावित करती हैं? और यदि हां, तो कैसे?

मुझे लगता है कि यह महसूस करना महत्वपूर्ण है कि SQL तालिका में शामिल होना बहुत महंगा है, लेकिन मेरे ज्ञान के लिए यह संदर्भात्मक अखंडता से ज्यादा प्रभावित नहीं था? अब, यदि हम डेटा विश्लेषण जैसा कुछ कर रहे हैं, तो स्पष्ट रूप से हमें संदर्भात्मक अखंडता की आवश्यकता नहीं है क्योंकि हम केवल अपने डेटा को एक ही तालिका में डंप करना चाहते हैं, लेकिन PlanetScale और Vitess बड़े वेब अनुप्रयोगों द्वारा उपयोग किए जाने का दावा करते हैं। जैसे यूट्यूब।

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

संदर्भात्मक अखंडता क्या है, और यह क्यों महत्वपूर्ण है?

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

यह महत्वपूर्ण क्यों है?

अब जबकि हमें इस बात का थोड़ा अंदाजा हो गया है कि वे क्या हैं, तो चलिए दूसरे भाग पर चलते हैं:वे महत्वपूर्ण क्यों हैं?

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

विटेस के पास यह क्यों नहीं है?

इसलिए, यह समझने के लिए कि विटेस रेफरेंशियल अखंडता का समर्थन करने में असमर्थ क्यों है, हमें डेटाबेस के आर्किटेक्चर में गोता लगाना होगा। विटेस एक शार्प्ड गैर-एसीआईडी ​​​​एसक्यूएल डेटाबेस है, न कि एक सच्चा वितरित एसीआईडी ​​​​एसक्यूएल डेटाबेस।

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

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

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

इसे क्यों छोड़ें?

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

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

हमें निश्चित रूप से अभी भी SQL तालिका की जटिलता में वृद्धि की समस्या है, इसलिए आप तालिकाओं के बीच जुड़ने से बचने के लिए denormalizing शुरू करते हैं।

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

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

फिर भी, इस सब के बावजूद, हमारा डेटाबेस अभी भी धीमा है, इसलिए हम डेटाबेस गणनाओं को क्लाइंट पर ले जाते हैं, उदाहरण के लिए एक UUID बनाना या एक तिथि निर्दिष्ट करना।

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

तो इस समय, हमारे डेटाबेस में

• कैशिंग के कारण कोई एसिड गुण नहीं
• कोई सामान्यीकृत स्कीमा नहीं
• कोई ट्रिगर नहीं
• कोई डेटाबेस गणना नहीं
• कोई द्वितीयक अनुक्रमणिका नहीं

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

हम बिना किसी FOREIGN KEY के NoSQL डेटाबेस की संरचना में गहराई से जा सकते हैं बाधाओं और मुद्दों का सामना करना पड़ेगा कि हम उस मॉडल को अपनाने का सामना करेंगे, लेकिन यह एक और पोस्ट का विषय है।

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

एसीआईडी ​​​​आइसोलेशन की गारंटी बहुत विवादास्पद है और इसकी उच्च लागत है। इसे डिफ़ॉल्ट रूप से प्रदान करना सबसे आम उपयोग के मामलों के लिए विटेस को अव्यावहारिक बना देता।

आइए संक्षेप में बात करते हैं कि ACID Isolation क्या है। इसके चार स्तर हैं (एसक्यूएल-92 मानकों के अनुसार), जिसमें क्रमबद्धता, प्रतिबद्ध पढ़ना, बिना पढ़े, और दोहराने योग्य पढ़ना शामिल है। कहा जा रहा है कि, अलगाव के अधिक स्तर हैं, जैसे स्नैपशॉट अलगाव जो SQL मानक नहीं है, हालांकि कई डेटाबेस जैसे कि फायरबेस या मोंगोडीबी द्वारा उपयोग किया जाता है। यदि आप इसमें और रुचि रखते हैं, तो मैं इस पोस्ट को पढ़ने की सलाह देता हूं। इसे संक्षिप्त रखने के लिए, मैं यह नहीं बताऊंगा कि अलगाव के हर स्तर का क्या मतलब है, लेकिन यदि आप इसके बारे में अधिक पढ़ना चाहते हैं तो इस पृष्ठ को MySQL दस्तावेज़ीकरण से देखें।

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

निष्कर्ष

इस सब के साथ, आप सोच रहे होंगे:कोई भी PlanetScale या Vitess का उपयोग क्यों करना चाहेगा? खैर, मुझे भी यही आश्चर्य है। कई कंपनियों और वेबसाइटों के साथ, इसका कारण यह था कि जब कोई बेहतर विकल्प नहीं थे, तो उन्होंने विटेस को वापस ले लिया। यदि आप लेख की शुरुआत में जाते हैं, तो ध्यान दें कि इसे 2010 में कैसे बनाया गया था। अब जब हम संदर्भात्मक अखंडता के साथ एक एसीआईडी-संगत स्केलेबल डेटाबेस का आनंद ले सकते हैं, तो इन नए डेटाबेस की ओर स्थानांतरित करना हमारे हित में होगा, और मैं 'पहले से ही ऐसा करना शुरू कर दिया है! प्रौद्योगिकी तेजी से बदलती है, और अपने डेटाबेस को गति में रखना किसी भी एप्लिकेशन का एक महत्वपूर्ण घटक है।