SQL लचीला है या मैं NoSQL से क्यों डरता हूँ?

अनुवादक से: हाल ही में Habré एक परियोजना पर प्रस्तुत किया गया जिसमें MySQL का उपयोग किया गया था। कई उपयोगकर्ताओं ने सोचा कि मैंने अपने कार्यों के लिए NoSQL का उपयोग क्यों नहीं किया, और गैर-संबंधपरक डेटाबेस पर स्विच करने की दृढ़ता से सिफारिश की। आज मैं इस लेख के बारे में आया, जो पूरी तरह से बताता है कि मैं NoSQL से "डर" क्यों रहा हूं।

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

हालांकि, पिछले दो हफ्तों ने मुझे महसूस किया है कि मैं प्राथमिक डेटा वेयरहाउस के रूप में MongoDB या किसी अन्य गैर-संबंधपरक डेटाबेस (NRBD) पर आधारित परियोजना शुरू नहीं करूंगा। ध्यान दें - मैंने कहा "शुरू"। मैं यह नहीं कह रहा हूँ कि मैं इस तरह के फिर से MongoDB का उपयोग नहीं करूंगा।

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

योजनाएं महान हैं

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

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

किसी भी मामले में, योजना आपके सिर में रहती है। समस्या यह है कि इसे ठीक से लागू नहीं किया गया है और गलतियाँ करने का एक मौका है। यदि आप एक स्ट्रिंग को स्टोर करते हैं जहां आपने किसी अन्य संग्रह में पूर्णांक को सहेजा है, तो उसी दस्तावेज़ में सोचते समय कोई समस्या नहीं होगी। अन्यथा, आपके संग्रह अचानक असंगत हो जाते हैं।

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

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

क्या आप जानते हैं कि आप क्या चाहते हैं?

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

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

यहां समझाने के लिए बहुत जटिल कारणों से, मुझे उस जानकारी को निकालना पड़ा जो मुझे उस प्रारूप में प्रस्तुत नहीं की गई थी जिसकी मुझे आवश्यकता थी। सब कुछ आश्चर्यजनक रूप से अच्छी तरह से असामान्य था कि डेटा को प्राप्त करने की कोशिश करने से खूनी गड़बड़ हो गई। SQL- उन्मुख डेटाबेस के साथ, यह कुछ JOINs और GROUP BY के साथ किया जा सकता है। और सभी क्योंकि यह एक कूबड़ के बिना लिखा गया था कि मुझे पूरी तरह से अलग प्रारूप में डेटा की आवश्यकता होगी।

"बहुत जटिल" मार डाला

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

मुझे यह विश्वास करना पसंद है कि हमारी टीम काफी सक्षम है, और हम बड़ी सावधानी से प्रौद्योगिकी का चयन करते हैं, लेकिन हमेशा ऐसी चीजें होती हैं जो आपको याद आती हैं।

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

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

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

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

तो, कम से कम खुद के लिए, मुझे एहसास हुआ कि मैं सब कुछ पहले से अनुमान नहीं लगा सकता, इसलिए जब मेरे पास अवसर है, मैं अधिक लचीले डेटा वेयरहाउस का उपयोग करूंगा, और फिलहाल इसका मतलब है कि मैं SQL डेटाबेस का उपयोग करूंगा।

और मैं अभी भी तुम्हें MongoDB प्यार करता हूँ।