मैंने केवल गैर-संबंधपरक डीबी के साथ शुरुआत की है, और मैं अभी भी इसके चारों ओर अपना सिर लपेटने की कोशिश कर रहा हूं और यह पता लगाऊंगा कि सबसे अच्छा मॉडल क्या होगा। और मैं केवल CouchDB के लिए बोल सकता हूं।
फिर भी, मेरे कुछ प्रारंभिक निष्कर्ष हैं:
क्या आप वैकल्पिक डिजाइनों के साथ आए हैं जो गैर-संबंधपरक दुनिया में बेहतर काम करते हैं?
डिज़ाइन फ़ोकस शिफ़्ट: दस्तावेज़ मॉडल (डीबी टेबल के अनुरूप) का डिज़ाइन लगभग अप्रासंगिक हो जाता है, जबकि सब कुछ विचारों को डिजाइन करने (प्रश्नों के अनुरूप) पर टिका होता है।
दस्तावेज़ DB प्रकार की अदला-बदली करता है: SQL में अनम्य डेटा और लचीली क्वेरीज़ होती हैं, दस्तावेज़ DBs दूसरे तरीके से होते हैं।
CouchDB मॉडल "JSON दस्तावेज़" (मूल रूप से नेस्टेड हैश तालिकाओं) का एक संग्रह है। प्रत्येक दस्तावेज़ में एक अद्वितीय आईडी होती है, और आईडी द्वारा तुच्छ रूप से पुनर्प्राप्त किया जा सकता है। किसी अन्य प्रश्न के लिए, आप "दृश्य" लिखते हैं, जिसे मानचित्र / कम किए गए कार्यों के सेट नाम दिए गए हैं। परिणाम कुंजी / मूल्य जोड़े की सूची के रूप में सेट किए गए परिणाम लौटाते हैं।
चाल यह है कि आप डेटाबेस को उस अर्थ में क्वेरी नहीं करते हैं जिसमें आप SQL डेटाबेस को क्वेरी करते हैं: व्यू फ़ंक्शंस को चलाने के परिणाम एक इंडेक्स में संग्रहीत होते हैं, और केवल इंडेक्स को क्वेर किया जा सकता है। (जैसा कि मुझे सब कुछ मिलता है "," कुंजी प्राप्त करें "या" कुंजी सीमा प्राप्त करें ")।"
SQL दुनिया में निकटतम सादृश्य होगा यदि आप केवल संग्रहीत कार्यविधियों का उपयोग करके DB को क्वेरी कर सकते हैं - प्रत्येक क्वेरी जिसे आप समर्थन करना चाहते हैं वह पूर्वनिर्धारित होना चाहिए।
दस्तावेजों का डिज़ाइन काफी लचीला है। मुझे केवल दो अवरोध मिले हैं:
- संबंधित डेटा को एक ही दस्तावेज़ में एक साथ रखें, क्योंकि इसमें शामिल होने के लिए कुछ भी नहीं है।
- दस्तावेज़ों को इतना बड़ा न करें कि वे बहुत बार अपडेट हो जाएं (जैसे उसी दस्तावेज़ में वर्ष के लिए सभी कंपनी की बिक्री डाल देना), क्योंकि प्रत्येक दस्तावेज़ अपडेट एक पुन: अनुक्रमण को ट्रिगर करता है।
लेकिन सब कुछ विचारों को डिजाइन करने पर टिका है।
वैकल्पिक डिजाइन मैंने पाया है कि किसी भी SQL डेटाबेस की तुलना में CouchDB के साथ परिमाण के वर्क ऑर्डर स्टोरेज स्तर के बजाय सिस्टम स्तर पर हैं। यदि आपके पास कुछ डेटा हैं और उन्हें वेब पेज पर देना चाहते हैं, तो कुल सिस्टम की जटिलता कम से कम 50% कम हो जाती है:
- कोई डिज़ाइनिंग डीबी टेबल (मामूली समस्या)
- नहीं ODBC / JDBC मध्यवर्ती परत, http पर सभी प्रश्न और लेनदेन (मध्यम अंक)
- JSON से साधारण डीबी-टू-ऑब्जेक्ट मैपिंग, जो एसक्यूएल (महत्वपूर्ण!) में समान की तुलना में लगभग तुच्छ है ।
- आप संभावित रूप से संपूर्ण एप्लिकेशन सर्वर को छोड़ सकते हैं, क्योंकि आप AJAX का उपयोग करके अपने दस्तावेज़ों को सीधे ब्राउज़र द्वारा पुनः प्राप्त करने के लिए डिज़ाइन कर सकते हैं और HTML प्रदर्शित होने से पहले जावास्क्रिप्ट को थोड़ा सा जोड़ सकते हैं। (विशाल !!)
सामान्य वेबएप्स के लिए, दस्तावेज़ / JSON- आधारित DBs एक विशाल जीत है, और कम लचीले प्रश्नों की कमियां और डेटा सत्यापन के लिए कुछ अतिरिक्त कोड का भुगतान करने के लिए एक छोटी सी कीमत लगती है।
क्या आपने किसी ऐसी चीज़ के खिलाफ अपना सिर मारा है जो असंभव लगता है?
अभी नहीं। डेटाबेस को क्वेरी करने के साधन के रूप में मैप / कम करना अपरिचित है, और SQL लिखने की तुलना में बहुत अधिक सोच की आवश्यकता है। प्राथमिकताओं की एक छोटी संख्या है, इसलिए आपके लिए आवश्यक परिणाम प्राप्त करना मुख्य रूप से रचनात्मक होने का एक सवाल है कि आप चाबियों को कैसे निर्दिष्ट करते हैं।
इस बात की एक सीमा है कि प्रश्न एक ही समय में दो या अधिक दस्तावेजों को नहीं देख सकते हैं - कोई भी जुड़ाव या अन्य प्रकार के बहु-दस्तावेज़ संबंध नहीं हैं, लेकिन अभी तक कुछ भी अचूक नहीं है।
एक उदाहरण सीमा के रूप में, मायने रखता है और रकम आसान है लेकिन औसत काउचडी व्यू / क्वेरी द्वारा गणना नहीं की जा सकती है। फिक्स: वापसी राशि और अलग से गणना करें और क्लाइंट पर औसत गणना करें।
क्या आपने किसी भी डिजाइन पैटर्न के साथ अंतर को पाटा है, उदाहरण के लिए एक से दूसरे में अनुवाद करने के लिए?
मुझे यकीन नहीं है कि यह संभव है। यह एक पूरी तरह से नया स्वरूप है, जैसे एक कार्यात्मक शैली कार्यक्रम को ऑब्जेक्ट-ओरिएंटेड शैली में अनुवाद करना। सामान्य तौर पर, SQL दस्तावेज़ और प्रत्येक दस्तावेज़ में अधिक डेटा की तुलना में बहुत कम दस्तावेज़ प्रकार होते हैं।
यह सोचने का एक तरीका आवेषणों और सामान्य प्रश्नों के लिए अपनी एसक्यूएल को देखना है: उदाहरण के लिए, ग्राहक द्वारा ऑर्डर दिए जाने पर कौन सी टेबल और कॉलम अपडेट किए जाते हैं? और मासिक बिक्री रिपोर्ट के लिए कौन सा? यह जानकारी संभवतः उसी दस्तावेज़ में जानी चाहिए।
यह है: प्रश्नों को आसान बनाने के लिए आवश्यक फ़ील्ड के साथ ग्राहक आईडी और उत्पाद आईडी वाले ऑर्डर के लिए एक दस्तावेज़। एक दस्तावेज़ के भीतर कुछ भी आसानी से उद्धृत किया जा सकता है, कुछ भी जिसे ऑर्डर और ग्राहक के बीच क्रॉस-रेफ़रिंग की आवश्यकता होती है, क्लाइंट द्वारा किया जाना है। इसलिए यदि आप क्षेत्र द्वारा बिक्री पर एक रिपोर्ट चाहते हैं, तो आपको संभवतः क्षेत्र कोड को क्रम में रखना चाहिए।
क्या आप भी अब स्पष्ट डेटा मॉडल (जैसे यूएमएल में) करते हैं?
क्षमा करें, दस्तावेज़ DBs से पहले कभी ज्यादा UML नहीं किया गया :)
लेकिन आपको किसी प्रकार के मॉडल की आवश्यकता है, जिसमें कहा गया हो कि कौन से क्षेत्र किस दस्तावेज़ के हैं और किस प्रकार के मूल्य हैं। बाद में आपके स्वयं के संदर्भ के लिए और यह सुनिश्चित करने के लिए कि DB का उपयोग करने वाला प्रत्येक व्यक्ति सम्मेलनों को जानता है। चूँकि यदि आप किसी पाठ क्षेत्र में दिनांक संग्रहीत करते हैं, तो आपको कोई त्रुटि नहीं मिलती है, उदाहरण के लिए, और कोई भी किसी भी फ़ील्ड को जोड़ सकता है या हटा सकता है जिसे वे महसूस करते हैं, आपको स्लैक लेने के लिए सत्यापन कोड और सम्मेलनों दोनों की आवश्यकता होती है। खासकर यदि आप बाहरी संसाधनों के साथ काम करते हैं।
क्या आपको आरडीबीएमएस द्वारा प्रदान की जाने वाली कोई भी अतिरिक्त अतिरिक्त सेवा याद आती है?
नहीं। लेकिन मेरी पृष्ठभूमि वेब एप्लिकेशन डेवलपर है, हम डेटाबेस से उसी सीमा तक निपटते हैं, जो हमें होना चाहिए :)
एक कंपनी जो मैं एक उत्पाद (एक वेबएप) बनाने के लिए काम करता था, जिसे कई विक्रेताओं से SQL डेटाबेस में चलाने के लिए डिज़ाइन किया गया था, और "अतिरिक्त सेवाएं" DB से DB तक इतनी भिन्न हैं कि उन्हें प्रत्येक DB के लिए अलग से लागू किया जाना था। इसलिए हमारे लिए RDBMS की कार्यक्षमता को स्थानांतरित करना कम काम था। यह भी पूर्ण खोज के लिए बढ़ा दिया गया।
इसलिए मैं जो कुछ भी दे रहा हूं वह वास्तव में पहली जगह पर है। जाहिर है, आपका अनुभव अलग हो सकता है।
एक चेतावनी: मैं अभी जो काम कर रहा हूं वह वित्तीय डेटा, स्टॉक कोट्स और इस तरह के लिए एक वेबएप है। यह एक दस्तावेज़ DB के लिए एक बहुत अच्छा मैच है, मेरे दृष्टिकोण से मुझे बिना किसी परेशानी के DB (दृढ़ता और प्रश्नों) के सभी लाभ मिलते हैं।
लेकिन ये डेटा एक दूसरे से काफी स्वतंत्र हैं, कोई जटिल संबंधपरक प्रश्न नहीं हैं। टिकर द्वारा नवीनतम उद्धरण प्राप्त करें, टिकर और तिथि सीमा के अनुसार उद्धरण प्राप्त करें, कंपनी मेटा-जानकारी प्राप्त करें, यह बहुत अधिक है। एक और उदाहरण मैंने देखा कि एक ब्लॉग अनुप्रयोग था, और ब्लॉगों को बड़े पैमाने पर जटिल डेटाबेस स्कीमा द्वारा विशेषता नहीं है।
मैं जो कहने की कोशिश कर रहा हूं, वह यह है कि दस्तावेज़ DBs के सभी सफल अनुप्रयोग मैं उस डेटा के साथ जानता हूं जिसके पहले स्थान पर बहुत अधिक संबंध नहीं हैं: दस्तावेज़ (Google खोज में), ब्लॉग पोस्ट, समाचार लेख, वित्तीय डेटा ।
मुझे उम्मीद है कि ऐसे डेटासेट हैं जो दस्तावेज़ मॉडल की तुलना में SQL के लिए बेहतर मैप करते हैं, इसलिए मुझे लगता है कि SQL जीवित रहेगा।
लेकिन हममें से जो डेटा को स्टोर करने और पुनः प्राप्त करने का एक सरल तरीका चाहते हैं - और मुझे संदेह है कि हम में से कई हैं - दस्तावेज़ डेटाबेस (जैसा कि काउचडीबी में) एक देवता हैं।