हाल ही में, मुझे हाइबरनेटिंग राइनोस के सीईओ और संस्थापक ओरेन ईनी का साक्षात्कार करने का अवसर मिला, जो विशेष रूप से .NET/Windows प्लेटफॉर्म के लिए डिज़ाइन किया गया एक खुला स्रोत दस्तावेज़-उन्मुख NoSQL, RavenDB प्रदान करता है।
ओरेन को विकास की दुनिया में 20 से अधिक वर्षों का अनुभव है और माइक्रोसॉफ्ट और .NET पारिस्थितिकी तंत्र पर एक मजबूत फोकस है। 2007 के बाद से माइक्रोसॉफ्ट के सबसे मूल्यवान पेशेवरों में से एक के रूप में मान्यता प्राप्त, ओरेन "DSLs in Boo:Domain Specific Languages in .NET" के लेखक भी हैं। वह अक्सर DevTeach, JAOO, QCon, Oredev, NDC, Yow! जैसे उद्योग सम्मेलनों में बोलते हैं! और प्रोग्रेसिव.नेट।
आप पूरा इंटरव्यू नीचे पढ़ सकते हैं:
<मजबूत>1. इस डिजिटल दुनिया में, डेटा सबसे मूल्यवान संपत्तियों में से एक बन गया है। और इसलिए, जिस तरह से डेटा संग्रहीत, व्यवस्थित और प्रक्रिया व्यवसाय की सफलता के लिए महत्वपूर्ण है। जैसे-जैसे कंपनियों पर अधिक से अधिक डेटा की बमबारी होती है, डेटा संग्रहण और विश्लेषण अधिक जटिल होते जा रहे हैं। क्या आप हमें कुछ सामान्य डेटाबेस प्रबंधन चुनौतियों के बारे में बता सकते हैं जिनका व्यवसायों को आज सामना करना पड़ रहा है?
मेरा मानना है कि प्राथमिक मुद्दा डेटा का विशाल आकार है। मैं जरूरी नहीं कि बिग डेटा और सैकड़ों टेराबाइट्स में मापे गए डेटा सेट के प्रबंधन की जटिलताओं के बारे में बात कर रहा हूं। मैं एक संगठन में आपके पास मौजूद डेटाबेस और डेटा साइलो की संख्या के बारे में बात कर रहा हूं। चूंकि सब कुछ डिजिटल है, इसलिए आपके पास व्यवसाय-महत्वपूर्ण कार्यक्षमता है जो एक साझा ड्राइव पर एक्सेल स्प्रेडशीट में रहती है और एक सर्वर में ग्राहक खरीद का ऐतिहासिक डेटा है जिसे कोई भी स्वामित्व स्वीकार करने के डर से पास नहीं जाना चाहता।
केवल यह पता लगाना कि संगठन क्या जानता है, एक जटिल कार्य हो सकता है। दरारों से डेटा का खिसकना दुख की बात है।
पूरी कंपनी के लिए एक केंद्रीकृत भंडार बनाने के प्रयास भी विफल होने के लिए अभिशप्त हैं। कंपनी के अलग-अलग हिस्सों के पास बहुत अलग विचार हैं कि स्पष्ट चीजें क्या हैं। उदाहरण के लिए, मार्केटिंग विभाग की तुलना में ग्राहक क्या है, इस बारे में बिलिंग विभाग की एक बहुत अलग धारणा है। डेटा को एक सामान्य साँचे में फ़िट करने की कोशिश करना हर किसी को नुकसान पहुँचाता है।
<मजबूत>2. हम इन चुनौतियों से कैसे पार पाते हैं? क्या आपको लगता है कि एक प्रभावी डेटाबेस प्रबंधन समाधान चुनना पहला कदम है? और क्यों?
पहला कदम, संगठनात्मक स्तर पर, डेटा स्वामित्व और जिम्मेदारी नियमों को परिभाषित करना है। सबसे बुनियादी स्तर पर, बिलिंग उस अवधारणा का मालिक है जो ग्राहक एक अतिदेय भुगतान स्थिति में है और मार्केटिंग ग्राहक के हितों का मालिक है। विचार संगठन में सूचनाओं के सिलोस बनाने का नहीं है, बल्कि विभिन्न आवश्यकताओं की स्पष्ट स्वीकृति प्राप्त करने का है। एक बार ऐसा करने के बाद, आप संगठन में उचित डेटा प्रवाह को परिभाषित कर सकते हैं।
बिलिंग विभाग एक ग्राहक के बारे में अपना दृष्टिकोण शेष संगठन को उपलब्ध कराएगा, जबकि विभाग के अंदर उसके आकार को बदलने की स्वतंत्रता बरकरार रखते हुए।
मैं इस उदाहरण के रूप में बिलिंग और मार्केटिंग विभागों और ग्राहक की धारणा का उपयोग करता हूं ताकि पहले व्यवसाय के बारे में बात कर सकूं, जो महत्वपूर्ण है। इसे थोड़ा और तकनीकी तरीके से स्थानांतरित करने के लिए, हम सेवाओं और डेटा प्रवाह अनुबंधों के बारे में बात कर रहे हैं। मैं आपको बेजोस के जनादेश के बारे में बताऊंगा और उसने अमेज़ॅन को कैसे बदल दिया। विचार सरल है:पूरे संगठन को एक पूरे के रूप में मानने के बजाय, जो एक निश्चित आकार से लगभग असंभव है, इसे सहयोगी संगठनों के एक समूह के रूप में मानें, जिनके बीच बहुत स्पष्ट सीमाएं हैं।
एक बार जब आपके पास वे सीमाएँ हों, और आपको संगठन में डेटा के प्रवाह का एक अच्छा विचार हो, तो आप अपने प्लंबर को अंदर आ सकते हैं और डेटा प्रवाह को विश्लेषण के लिए एक केंद्रीय स्थान पर पुनर्निर्देशित करने जैसे काम कर सकते हैं।
इस तरह के प्रकाशित इंटरफेस होने से कुछ चीजों के व्यवहार में बदलाव का समय आने पर बहुत मदद मिलती है। जब तक बाहरी व्यवहार समान है, हम इसे संसाधित करने के तरीके को बदलने के लिए स्वतंत्र हैं।
<मजबूत>3. हाल के वर्षों में, उद्यमों ने विभिन्न प्रकार के NoSQL डेटाबेस को अपनाया है। NoSQL डेटाबेस में तेजी से संवेदनशील डेटा संग्रहीत होने के साथ, सुरक्षा मुद्दे बढ़ते हुए चिंता का विषय बन गए हैं। इस पर आपकी क्या राय है?
कुल मिलाकर, NoSQL डेटाबेस में सुरक्षा की कमी का सबसे आम कारण ऑपरेटर की लापरवाही है। मैं यहां दो अलग-अलग मुद्दों को स्पष्ट रूप से अलग करना चाहता हूं। हमारे पास Redis जैसे NoSQL डेटाबेस हैं, जिनका सुरक्षा मॉडल स्पष्ट रूप से एक विश्वसनीय वातावरण में चलने के बारे में है। रेडिस के लिए कुछ प्राथमिक सुरक्षा विशेषताएं हैं, लेकिन सामान्य धारणा यह है कि वे केवल रक्षा की तीसरी या चौथी पंक्ति के रूप में काम करने के लिए हैं।
अन्य नोएसक्यूएल डेटाबेस, जैसे मोंगोडीबी, से शत्रुतापूर्ण नेटवर्क (यानी, इंटरनेट) पर चलने की उम्मीद है। हालांकि, मोंगोडीबी को बिना किसी सुरक्षा के सेटअप करना आसान है। दूसरी ओर, MongoDB एक सुरक्षित कॉन्फ़िगरेशन में आता है, जो इसे केवल स्थानीय मशीन को सुनने की अनुमति देता है।
MongoDB से दूरस्थ रूप से कनेक्ट करने का प्रयास करते समय आपको जो सबसे पहली चीज़ मिलेगी, वह एक गाइड है जो बताती है कि बिना किसी सुरक्षा के, MongoDB तक रिमोट एक्सेस कैसे सक्षम किया जाए।
कुछ हद तक, यह ऑपरेटर की लापरवाही है। लेकिन मोंगोडीबी डेटाबेस की भारी संख्या को देखते हुए जो खुले छोड़ दिए गए हैं, मेरा मानना है कि यह बालों को विभाजित कर रहा है। चीन में एक खुले MongoDB डेटाबेस में 200 मिलियन से अधिक CV थे, जो किसी की जासूसी करने की प्रतीक्षा कर रहे थे; एक लापरवाही से सेटअप डेटाबेस ने रूस के पिछले दरवाजे को 2,000 से अधिक कंपनियों में उजागर कर दिया है।
सुरक्षा के साथ, आपको दूसरा मौका नहीं मिलता है।
इसके विपरीत, रेवेनडीबी एक कमजोर विन्यास में चलने से मना कर देगा। आप स्थानीय मशीन पर बिना किसी सुरक्षा के रेवेनडीबी चला सकते हैं, लेकिन यदि आप उचित सुरक्षा उपायों के बिना डेटाबेस को इंटरनेट पर उजागर करने का प्रयास करते हैं, तो डेटाबेस यह बताते हुए एक त्रुटि लौटाएगा कि आपको इसे ठीक से कैसे सेट अप करना चाहिए।
हम यह मानकर अधिक से अधिक अंतराल को भरते हैं कि अधिकांश लोग आवश्यक न्यूनतम कार्य करेंगे और सुनिश्चित करेंगे कि जब ऐसा होता है, तो अंतिम स्थिति अच्छी होती है, इसलिए हमने आपको कवर कर लिया है।
<मजबूत>4. रेवेनडीबी के बारे में बात करते हुए, क्या आप कुछ सबसे महत्वपूर्ण विशेषताओं के नाम बता सकते हैं जो ग्राहकों के लिए अधिक मूल्य जोड़ते हैं? सुविधाओं और प्रदर्शन के मामले में रेवेनडीबी अन्य विक्रेताओं के बीच कैसे खड़ा है?
रेवेनडीबी एक दशक से अधिक समय से उत्पादन प्रणालियों में चल रहा है। कुछ सबसे शक्तिशाली विशेषताएं जिन्हें हमने अपने मूल संस्करण में वापस दिनांकित किया है। परिचालन वातावरण में गतिशील रूप से प्रतिक्रिया करने की क्षमता सबसे स्पष्ट है। रेवेनडीबी लगातार विश्लेषण करता है कि क्या हो रहा है (आने वाले प्रश्न, सर्वर लोड, आदि) और संसाधन आवंटन, आंतरिक संरचनाओं आदि को बदलकर उस पर प्रतिक्रिया करता है। विचार यह है कि पूर्णकालिक डीबीए आपके डेटाबेस को बेबीसिट करने के बजाय, आपका डेटाबेस प्रबंधित कर सकता है इसके अपने मामले।
जब हमने रेवेनडीबी पर काम करना शुरू किया, तो हम एक ऐसा डेटाबेस चाहते थे जिसमें एक रिलेशनल डेटाबेस (तेज़, एसीआईडी, विश्वसनीय) के सभी फायदे हों, लेकिन कोई नुकसान नहीं (कठोर स्कीमा, चल रहे रखरखाव, उच्च जटिलता)।
जब हमने शुरुआत की, तो मुझे नहीं पता था कि यह कितना बड़ा काम है। पिछले 10 वर्षों में, हमने एक ऐसा डेटाबेस बनाने का बहुत अनुभव प्राप्त किया है, जो बिना आपको अधिक ध्यान दिए बस काम कर सकता है। हमने प्रदर्शन पर ध्यान देने के साथ चीजों को लागू करना आसान बनाने के लिए रेवेनडीबी को डिज़ाइन किया है। रास्पबेरी पाई (25$, 1 गीगाहर्ट्ज, 1 जीबी रैम) मशीन पर एक हालिया बेंचमार्क ने हमें 5,000 से अधिक एक सेकंड में लिखा। कमोडिटी हार्डवेयर पर, हम प्रति सेकंड 100,000 से अधिक राइट्स प्राप्त कर सकते हैं और प्रति सेकंड 1,000,000 से अधिक रीड्स प्राप्त कर सकते हैं।
वह सब एक ही नोड पर है, लेकिन रेवेनडीबी गेट-गो से एक वितरित डेटाबेस रहा है। इसका मतलब है कि आप कुछ ही मिनटों में एक क्लस्टर सेट कर सकते हैं (और निश्चित रूप से सुरक्षित तरीके से ऐसा कर सकते हैं) और आपके पास एक अत्यधिक उपलब्ध और मजबूत प्रणाली है।
हम कुछ विशिष्ट सुविधाएँ प्रदान करते हैं जो अन्यत्र उपलब्ध नहीं हैं। ETL RavenDB के अंदर अंतर्निहित है और हमारे ग्राहकों द्वारा समृद्ध डेटा प्रवाह को सक्षम करने के लिए इसका अत्यधिक उपयोग किया जाता है। आपको अलग-अलग टुकड़ों से एक समाधान को एक साथ सिलाई करने की ज़रूरत नहीं है, यह बॉक्स में ठीक है और यह बस काम करता है।
सदस्यता सुविधा वह है जिस पर मुझे विशेष रूप से गर्व है। यह आपको एक सतत क्वेरी करने की अनुमति देता है। डेटाबेस शुरू में आपको वे सभी परिणाम देगा जो आपकी क्वेरी से मेल खाते हैं। चूंकि आपने अभी भी इस क्वेरी की सदस्यता ली है, इसलिए आपका डेटाबेस किसी भी नए दस्तावेज़ को भेजेगा जो आपकी क्वेरी से मेल खाते हैं जैसे ही वे उस क्वेरी में फिट होने के लिए दर्ज या अपडेट किए जाते हैं। यह आपको मजबूत व्यावसायिक प्रक्रियाओं और बैकएंड सिस्टम को आसानी से बनाने की अनुमति देता है।
हमने रेवेनडीबी को दस्तावेजों, की-वैल्यू, बाइनरी डेटा, वितरित काउंटरों और ग्राफ प्रश्नों को संभालने में सक्षम एक बहु-मॉडल डेटाबेस में बनाने के लिए बहुत सारे प्रयासों पर ध्यान केंद्रित किया है।
<मजबूत>5. और अंत में, डेटाबेस प्रबंधन प्रणालियों का भविष्य क्या है? अगले 3-4 वर्षों में यह कैसे बदलने वाला है?
आप बहु-मॉडल डेटाबेस पर बहुत अधिक ध्यान केंद्रित करने जा रहे हैं। प्रत्येक प्रकार के डेटा के लिए एक समर्पित समाधान तैनात करने और प्रत्येक टुकड़े के बीच जटिल एकीकरण से निपटने के बजाय, बाजार एक एकीकृत समाधान की ओर बढ़ रहा है जो एक ही बॉक्स में विकल्पों का एक पूरा सूट पेश कर सकता है।
क्लाउड अधिक महत्वपूर्ण बना रहेगा, लेकिन मैं ऑन-प्रिमाइसेस और वितरित सिस्टम को अलविदा कहने में जल्दबाजी नहीं करूंगा। हम देख रहे हैं कि हमारे बहुत से ग्राहक किनारे पर और कभी-कभी जुड़े सिस्टम पर प्रसंस्करण करते हैं। मुझे लगता है कि आप फोकस का एक बदलाव देखेंगे, जहां अतीत के डेटा केंद्र क्लाउड में चले जाएंगे, लेकिन वास्तविक प्रसंस्करण का एक बहुत किनारे पर और मोबाइल उपकरणों पर वितरित किया जाएगा। इसके लिए डेटा वितरण के बारे में सोचने के एक अलग तरीके की आवश्यकता है और डेटा को क्लाउड पर कैसे धकेला जाए और क्लाउड से डेटा कैसे निकाला जाए।
उस तरह के वितरित डेटा प्रोसेसिंग पर बहुत अधिक जोर दिया जा रहा है जो कभी हाई-एंड सिस्टम की अनन्य श्रेणी थी।
यह देखना निश्चित रूप से बहुत दिलचस्प होने वाला है कि परिदृश्य कैसे बदलता है और कैसे हम लगातार बढ़ती जटिलता और कार्यक्षमता को संभालने के लिए उपकरण और कार्यप्रणाली का निर्माण करते हैं।
