डेटा मॉडलिंग मूल बातें - PostgreSQL बनाम Cassandra बनाम MongoDB

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

इस पोस्ट का उद्देश्य एप्लिकेशन डेवलपर्स को एप्लिकेशन के डेटा मॉडलिंग की जरूरतों के संदर्भ में SQL बनाम NoSQL की पसंद को समझने में मदद करना है। हम एक SQL डेटाबेस, अर्थात् PostgreSQL और 2 NoSQL डेटाबेस, अर्थात् Cassandra और MongoDB का उपयोग करते हैं, उदाहरण के लिए डेटा मॉडलिंग मूल बातें समझाने के लिए उदाहरण जैसे टेबल बनाना, डेटा सम्मिलित करना, स्कैन करना और डेटा हटाना। एक अनुवर्ती पोस्ट में, हम उन्नत विषयों जैसे कि अनुक्रमणिका, लेनदेन, जॉइन, टाइम-टू-लाइव (टीटीएल) निर्देशों और JSON- आधारित दस्तावेज़ डेटा मॉडलिंग को कवर करेंगे।

डेटा मॉडलिंग में SQL से NoSQL मुश्किलें कैसे?

SQL डेटाबेस ACID ट्रांजेक्शनल गारंटी के साथ-साथ मौजूदा सामान्यीकृत रिलेशनल डेटा मॉडल के शीर्ष पर अप्रत्याशित तरीकों से JOIN का उपयोग करके डेटा क्वेरी करने की क्षमता के साथ अनुप्रयोग चपलता बढ़ाते हैं।

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

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

वितरित क्लस्टर पर उच्च प्रदर्शन प्राप्त करने पर NoSQL का ध्यान कई डेटा मॉडलिंग समझौते के प्राथमिक परिमाण के रूप में कहा जाता है जिसमें ACID लेनदेन, JOINs और सुसंगत वैश्विक द्वितीयक सूचकांक शामिल हैं।

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

निम्न तालिका का विवरण है कि NoSQL डेटा मॉडलिंग एसक्यूएल से अलग है।

SQL बनाम NoSQL - प्रमुख डेटा मॉडलिंग अंतर

SQL और NoSQL: आपको दोनों की आवश्यकता क्यों है?

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

कैसे YugaByte DB एक सामान्य डेटाबेस कोर पर SQL और NoSQL एक साथ लाता है?

लॉग-स्ट्रक्चर्ड मर्ज स्टोरेज इंजन, ऑटो-शार्किंग, प्रति-शर्ड वितरित आम सहमति प्रतिकृति और वितरित ACID लेनदेन (Google Spanner द्वारा प्रेरित) के एक अद्वितीय संयोजन पर निर्मित, YugaByte DB दुनिया का 1 खुला स्रोत डेटाबेस है जो NoSQL (Cassandra और Redis) दोनों है संगत) और SQL (PostgreSQL संगत) एक ही समय में। जैसा कि नीचे दी गई तालिका में दिखाया गया है, YCQL, YugaByte DB के कैसंड्रा संगत एपीआई, इस तरह से Transactional NoSQL के युग की शुरुआत के रूप में NoSQL API के लिए एकल-कुंजी और बहु-कुंजी ACID लेनदेन और वैश्विक माध्यमिक सूचकांक की धारणा जोड़ता है। इसके अतिरिक्त, YSQL, YugaByte DB के PostgreSQL संगत API, SQL लिखने के लिए रैखिक लेखन स्केलिंग और स्वचालित गलती-सहिष्णुता की धारणा को जोड़ता है, इस प्रकार वितरित SQL की दुनिया को सामने लाता है। चूंकि YugaByte DB मूल में लेन-देन है, यहां तक ​​कि NoSQL API का उपयोग अब मिशन-महत्वपूर्ण डेटा के संदर्भ में किया जा सकता है।

YugaByte DB - SQL और NoSQL एक एकल डेटाबेस कोर पर

जैसा कि पहले YSQL परिचय में वर्णित है: YugByte DB के लिए एक PostgreSQL संगत डिस्ट्रीब्यूटेड SQL API, YugaByte DB में SQL बनाम NoSQL की पसंद पूरी तरह से बहुमत के वर्कलोड की विशेषताओं पर निर्भर करती है।

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

अगले भाग में डेटा मॉडलिंग लैब मूल डेटाबेस के विपरीत YugaByte DB के PostgreSQL और Cassandra संगत APIs पर आधारित है। यह दृष्टिकोण एक ही डेटाबेस क्लस्टर के दो अलग-अलग एपीआई (दो अलग-अलग बंदरगाहों पर) के साथ बातचीत करने की सरलता को उजागर करता है, क्योंकि दो अलग-अलग डेटाबेसों के पूरी तरह से स्वतंत्र क्लस्टर का उपयोग करने का विरोध किया गया है।

अगले भाग में हम विभिन्न डेटाबेसों के बीच कई अंतरों और कुछ सामान्यताओं का वर्णन करने के लिए लैब पर डेटा मॉडलिंग हाथों से चलते हैं।

डेटा मॉडलिंग लैब

डेटाबेस स्थापित करें

डेटा मॉडलिंग पर ध्यान केंद्रित करते हुए (और जटिल तैनाती आर्किटेक्चर पर नहीं), हम अपने स्थानीय मशीनों पर डॉकर कंटेनरों में डेटाबेस स्थापित करेंगे और फिर उनके संबंधित कमांड-लाइन के गोले का उपयोग करके उनके साथ बातचीत करेंगे।

YugaByte DB, एक PostgreSQL और Cassandra संगत डेटाबेस

mkdir ~ / yugabyte && cd ~ / yugabyte
wget https://downloads.yugabyte.com/yb-docker-ctl && chmod + x yb-docker-ctl
docker खींचना yugabytedb / yugabyte
./yb-docker-ctl create --enable_postgres

MongoDB

docker run --name my-mongo -d mongo: नवीनतम

कमांड लाइन शेल का उपयोग करना

संबंधित API के लिए कमांड लाइन के गोले का उपयोग करके डेटाबेस से कनेक्ट करें।

PostgreSQL

psql PostgreSQL के साथ बातचीत करने के लिए एक कमांड लाइन शेल है। उपयोग में आसानी के लिए, YugaByte DB जहाज इसके बिन निर्देशिका में psql के एक संस्करण के साथ।

docker exec -it yb-postgres-n1 / home / yugabyte / postgres / bin / psql -p 5433 -U पोस्टग्रेज

कैसेंड्रा

cqlsh, कैसेंड्रा और इसके संगत डेटाबेस CQL (कैसेंड्रा क्वेरी लैंग्वेज) के माध्यम से बातचीत करने के लिए एक कमांड लाइन शेल है। उपयोग में आसानी के लिए, YugaByte DB अपने बिन निर्देशिका में cqlsh के एक संस्करण के साथ जहाज।

ध्यान दें कि CQL तालिका, पंक्तियों, स्तंभों और अनुक्रमित की समान धारणा के साथ SQL से काफी प्रेरित है। हालांकि, एक NoSQL भाषा के रूप में, यह प्रतिबंधों का एक विशिष्ट सेट जोड़ता है जिसमें से अधिकांश हम अपने ब्लॉग श्रृंखला के दौरान समीक्षा करेंगे।

docker exec -it yb-tserver-n1 / home / yugabyte / bin / cqlsh

MongoDB

मोंगो MongoDB के साथ बातचीत करने के लिए एक कमांड लाइन शेल है। यह एक MongoDB स्थापना के बिन निर्देशिका में पाया जा सकता है।

docker exec -it my-mongo बैश
सीडी बिन
मोंगो

एक तालिका बनाएँ

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

PostgreSQL

रचना संगीत (
    कलाकार वर्षा (20) नहीं,
    SongTitle VARCHAR (30) पूर्ण नहीं,
    एल्बम विचर (25),
    वर्ष INT,
    मूल्य FLOAT,
    शैली वकार (10),
    आलोचना फ़्लोट,
    टैग पाठ,
    प्राथमिक कुंजी (कलाकार, गीत)
);

कैसेंड्रा

कैसंड्रा में टेबल बनाएँ, PostgreSQL के समान है। एक बड़ा अंतर अखंडता की कमी है (जैसे कि NULL नहीं) जो कि अनुप्रयोग की जिम्मेदारी है और NoSQL दुनिया में डेटाबेस की नहीं। प्राथमिक कुंजी में विभाजन कुंजी (नीचे उदाहरण में कलाकार स्तंभ) और क्लस्टरिंग कॉलम का एक सेट (नीचे उदाहरण में सोंगटिटाइल कॉलम) शामिल है। विभाजन कुंजी यह निर्धारित करती है कि किस विभाजन / पंक्ति को पंक्ति में रखना है और क्लस्टरिंग कॉलम यह निर्दिष्ट करते हैं कि किसी दिए गए शार्क के अंदर के डेटा को कैसे व्यवस्थित किया जाना चाहिए।

बनाएं मुख्य myapp;
उपयोग करें myapp;
रचना संगीत (
    कलाकार पाठ,
    सॉन्ग टाइटल टेक्स्ट,
    एल्बम का पाठ,
    वर्ष INT,
    मूल्य FLOAT,
    शैली पाठ,
    आलोचना फ़्लोट,
    टैग पाठ,
    प्राथमिक कुंजी (कलाकार, गीत)
);

MongoDB

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

myNewDatabase का उपयोग करें;

एक तालिका के बारे में जानकारी प्राप्त करें

PostgreSQL

\ _ संगीत
टेबल "public.music"
    कॉलम | प्रकार | कोलाज | अशक्त | चूक
-------------- + ----------------------- + ----------- + ---------- + --------
 कलाकार | चरित्र भिन्न (20) | | अशक्त नहीं |
 गीत | चरित्र भिन्न (30) | | अशक्त नहीं |
 एल्बम एल्बम | चरित्र भिन्न (25) | | |
 वर्ष | पूर्णांक | | |
 कीमत | दोहरी सटीकता | | |
 शैली | चरित्र भिन्न (10) | | |
 आलोचना करना | दोहरी सटीकता | | |
 टैग | पाठ | | |
इंडेक्स:
    "music_pkey" PRIMARY KEY, btree (कलाकार, गीतकार)

कैसेंड्रा

DESCRIBE टेबल संगीत;
बनाएँ तालिका myapp.music (
    कलाकार पाठ,
    गीत पाठ,
    एल्बम पाठ,
    वर्ष इंट,
    मूल्य फ्लोट,
    शैली पाठ,
    टैग पाठ,
    प्राथमिक कुंजी (कलाकार, गीत)
) के साथ आदेश द्वारा (गीत ASC)
    और default_time_to_live = 0
    और लेनदेन = {'सक्षम': 'गलत'};

MongoDB

myNewDatabase का उपयोग करें;
संग्रह दिखाएं;

तालिका में डेटा सम्मिलित करें

PostgreSQL

संगीत में संगीत
    (आर्टिस्ट, सॉन्गटिटल, एल्बमटाइटल,
    वर्ष, मूल्य, शैली, आलोचना,
    टैग)
मूल्यों (
    'नो वन यू नो', 'कॉल मी टुडे', 'थोड़ा फेमस',
    2015, 2.14, 'देश', 7.8,
    '{"कम्पोज़र्स": ["स्मिथ", "जोन्स", "डेविस"], "लेंथ इनसेकंड्स": 21%}'
);
संगीत में संगीत
    (आर्टिस्ट, सॉन्गटिटल, एल्बमटाइटल,
    मूल्य, शैली, आलोचना)
मूल्यों (
    'नो वन यू नो', 'माई डॉग स्पॉट', 'हे नाऊ'
    1.98, 'देश', 8.4
);
संगीत में संगीत
    (आर्टिस्ट, सॉन्गटिटल, एल्बमटाइटल,
    मूल्य, शैली)
मूल्यों (
    'द एक्मे बैंड', 'लुक आउट, वर्ल्ड', 'द बक स्टार्ट्स हियर',
    0.99, 'रॉक'
);
संगीत में संगीत
    (आर्टिस्ट, सॉन्गटिटल, एल्बमटाइटल,
    मूल्य, शैली,
    टैग)
मूल्यों (
    'द एक्मे बैंड', 'स्टिल इन लव', 'द बक स्टार्ट्स हियर',
    2.47, 'रॉक',
    '{"RadioStationsPlaying": ["केएचसीआर", "केबीएक्सएक्स", "डब्ल्यूटीएनआर", "डब्ल्यूजेजेएच"], "टूरडेट्स": {"सिएटल": "20150625", "क्लीवलैंड": "20150630"}, "रोटेशन": भारी} '
);

कैसेंड्रा

कैसंड्रा INSERT के बयान सामान्य रूप से PostgreSQL के समान दिखते हैं। हालाँकि, शब्दार्थ में एक बड़ा अंतर है। INSERT वास्तव में कैसंड्रा में एक मुखर ऑपरेशन है जहां पंक्ति पहले से मौजूद होने के कारण नवीनतम मानों के साथ पंक्ति को अद्यतन किया जाता है।

ऊपर PostgreSQL INSERT कथनों के समान।

MongoDB

हालांकि MongoDB भी Cassandra के समान एक NoSQL डेटाबेस है, लेकिन इसके सम्मिलित संचालन में Cassandra के समान शब्दार्थ व्यवहार नहीं है। MongoDB इन्सर्ट () में कोई अपग्रेस्ड संभावना नहीं है जो इसे PostgreSQL के समान बनाता है। कोई _idspecified के साथ डिफ़ॉल्ट सम्मिलित व्यवहार संग्रह में जोड़े गए नए दस्तावेज़ को ले जाएगा।

db.music.insert ({
कलाकार: "नो वन यू नो",
   गीत शीर्षक: "मुझे आज बुलाओ",
    एल्बम शीर्षक: "कुछ हद तक प्रसिद्ध",
    वर्ष: २०१५,
    कीमत: 2.14,
    शैली: "देश",
    टैग: {
संगीतकार: ["स्मिथ", "जोन्स", "डेविस"],
लंबाई: सेकंड: 214
}
   }
);
db.music.insert ({
    कलाकार: "नो वन यू नो",
    गीतटैल: "माई डॉग स्पॉट",
    एल्बम शीर्षक: "अरे अब",
    कीमत: 1.98,
    शैली: "देश",
    आलोचना: 8.4
   }
);
db.music.insert ({
    कलाकार: "द एक्मे बैंड",
    गीत शीर्षक: "लुक आउट, वर्ल्ड",
    एल्बमटैल: "द बक स्टार्ट्स हियर",
    कीमत: 0.99,
    शैली: "रॉक"
   }
);
db.music.insert ({
    कलाकार: "द एक्मे बैंड",
    गीत शीर्षक: "स्टिल इन लव",
    एल्बम शीर्षक: "द बक स्टार्ट हियर",
    कीमत: 2.47,
    शैली: "रॉक",
    टैग: {
        RadioStationsPlaying: ["केएचसीआर", "केबीएक्सएक्स", "डब्ल्यूटीएनआर", "डब्ल्यूजेसीआर",
        यात्रा की तिथियां: {
            सिएटल: "20150625",
            क्लीवलैंड: "20150630"
        },
        रोटेशन: "भारी"
}
    }
);

एक तालिका क्वेरी

मॉडलिंग प्रश्नों के संदर्भ में SQL और NoSQL के बीच सबसे महत्वपूर्ण अंतर FROM और WHERE क्लॉज़ के उपयोग पर है। SQL FROM क्लॉज़ को कई तालिकाओं को शामिल करने की अनुमति देता है और जहाँ क्लॉज़ मनमाना जटिलता (तालिकाओं में JOINs सहित) का होना चाहिए। हालाँकि, NoSQL ने FROM क्लॉज पर एक कठोर प्रतिबंध लगाने की ठानी है, जिसमें केवल एक टेबल निर्दिष्ट है और WHERE क्लॉज में हमेशा प्राथमिक कुंजी निर्दिष्ट है। क्योंकि हमने पहले चर्चा की थी कि NoSQL के उच्च प्रदर्शन पर ध्यान केंद्रित करना किसी भी क्रॉस-टेबल और क्रॉस-कुंजी इंटरैक्शन को कम करना है। इस तरह की बातचीत क्वेरी प्रतिक्रिया समय में उच्च विलंबता क्रॉस-नोड संचार पेश कर सकती है और इसलिए पूरी तरह से बचा जाता है। जैसे कैसंड्रा के लिए यह आवश्यक है कि विभाजन इंडिकेटर पर क्वेरी ऑपरेटर (केवल =, <,>, =>, <= की अनुमति दी जाती है) को प्रतिबंधित करें सिवाय द्वितीयक इंडेक्स को क्वेरी करते हुए (जहां केवल = ऑपरेटर की अनुमति है)।

PostgreSQL

निम्नलिखित 3 प्रकार के प्रश्न हैं जो SQL डेटाबेस द्वारा आसानी से परोसे जा सकते हैं।

  • एक कलाकार द्वारा सभी गीतों की वापसी
  • शीर्षक के पहले भाग का मिलान करते हुए, एक कलाकार द्वारा सभी गाने लौटाएं
  • एक कलाकार द्वारा सभी गीतों को लौटाएं, शीर्षक में एक विशेष शब्द के साथ लेकिन तभी जब कीमत 1.00 से कम हो
संगीत से * का चयन करें
जहां कलाकार = 'नो वन यू नो';
संगीत से * का चयन करें
जहां कलाकार = 'कोई भी आपको नहीं जानता' और गीत 'कॉल%' को पसंद करता है;
संगीत से * का चयन करें
जहां कलाकार = 'कोई भी तुम्हें नहीं जानता' और गीत का शीर्षक '% आज%'
और मूल्य> 1.00;

कैसेंड्रा

ऊपर सूचीबद्ध PostgreSQL प्रश्नों में से, केवल पहला कैसेंड्रा के साथ काम करेगा, क्योंकि LIKE ऑपरेटर को SongTitle जैसे क्लस्टरिंग कॉलम पर अनुमति नहीं है। इस मामले में केवल = और IN ऑपरेटरों को अनुमति है।

संगीत से * का चयन करें
जहां कलाकार = 'नो वन यू नो';
संगीत से * का चयन करें
WHERE कलाकार = 'नो वन यू नो' और सॉन्गटिट इन ('कॉल मी टुडे', 'माई डॉग स्पॉट')
और मूल्य> 1.00;

MongoDB

जैसा कि पिछले उदाहरणों में दिखाया गया है, MongoDB को क्वेरी करने के लिए प्राथमिक विधि db.collection.find () विधि है। यह विधि संग्रह नाम (नीचे उदाहरण में संगीत) द्वारा बहुत ही स्पष्ट रूप से क्लेयर करने के लिए योग्य है ताकि संग्रह भर में क्वेरी स्पष्ट रूप से अस्वीकृत हो।

db.music.find ({
  कलाकार: "नो वन यू नो"
 }
);
db.music.find ({
  कलाकार: "नो वन यू नो",
  गीत शीर्षक: / कॉल /
 }
);

एक मेज से सभी पंक्तियों को पढ़ें

सभी पंक्तियों को पढ़ना जेनेरिक क्वेरी पैटर्न का एक विशेष मामला है जिसे हमने पहले देखा था।

PostgreSQL

चुनते हैं *
संगीत से;

कैसेंड्रा

ऊपर PostgreSQL SELECT स्टेटमेंट के समान है।

MongoDB

db.music.find ({});

तालिका में डेटा संशोधित करें

PostgreSQL

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

अद्यतन संगीत
सेट शैली = 'डिस्को'
जहां कलाकार = 'द एक्मे बैंड' और सॉन्गटेल = 'स्टिल इन लव';

कैसेंड्रा

कैसंड्रा में भी PostgreSQL के समान एक अद्यतन विवरण है। अद्यतन भी INSERT बयान के रूप में एक ही शब्दार्थ।

ऊपर PostgreSQL अद्यतन के रूप में ही।

MongoDB

MongoDB का अपडेट () ऑपरेशन किसी मौजूदा दस्तावेज़ को पूरी तरह से अपडेट कर सकता है या केवल विशिष्ट फ़ील्ड्स ही अपडेट कर सकता है। डिफ़ॉल्ट रूप से, यह केवल एक दस्तावेज़ को अद्यतन करता है, जो शब्दार्थ को बंद कर देता है। ऑपरेशन पर अतिरिक्त झंडे स्थापित करके बहु-दस्तावेज़ अद्यतन और मुखर व्यवहार को चालू किया जा सकता है। जैसे नीचे दिए गए उदाहरण से कलाकार के गीतों में एक विशिष्ट कलाकार की शैली का अद्यतन होता है।

db.music.update (
  {"कलाकार": "द एक्मे बैंड"},
  {
    $ सेट: {
      "शैली": "डिस्को"
    }
  },
  {"मल्टी": सच, "अपरेंट": सच "
);

तालिका से डेटा हटाएं

PostgreSQL

संगीत से DELETE
जहां कलाकार = 'द एक्मे बैंड' और सॉन्गटिटल = 'लुक आउट, वर्ल्ड';

कैसेंड्रा

ऊपर PostgreSQL DELETE कथन के समान।

MongoDB

दस्तावेज़ हटाने को हटाने के लिए MongoDB के दो प्रकार के ऑपरेशन हैं - deleteOne () / deleteMany () और निकालें ()। दोनों दस्तावेज़ हटाते हैं, लेकिन उनके अलग-अलग परिणाम होते हैं।

db.music.deleteMany ({
        कलाकार: "द एक्मे बैंड"
    }
);

एक तालिका निकालें

PostgreSQL

ड्रॉप टेबल म्यूजिक;

कैसेंड्रा

ऊपर PostgreSQL DROP टेबल विवरण के रूप में ही;

MongoDB

db.music.drop ();

सारांश

SQL बनाम NoSQL बहस अब एक दशक से अधिक उग्र है। इस बहस के 2 पहलू हैं: डेटाबेस कोर आर्किटेक्चर (अखंड, लेन-देन SQL बनाम वितरित, गैर-लेन-देन NoSQL) और डेटा मॉडलिंग दृष्टिकोण (SQL में अपना डेटा बनाम मॉडल NoSQL में अपने प्रश्नों का मॉडल)।

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

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

इस पोस्ट ने हमें यह समझने में मदद की कि डेटा मॉडलिंग की मूल बातें PostgreSQL, Cassandra और MongoDB के बीच कैसे भिन्न होती हैं। श्रृंखला की अगली पोस्टों में, हम उन्नत डेटा मॉडलिंग अवधारणाओं जैसे कि अनुक्रमित, लेनदेन, JOIN, TTL निर्देश और JSON दस्तावेज़ों में गोता लगाएँगे।

आगे क्या होगा?

  • YugaByte DB की तुलना Amazon DynamoDB, Cassandra, MongoDB और Azure Cosmos DB जैसे डेटाबेस से करें।
  • MacOS, Linux, Docker और Kubernetes पर YugaByte DB के साथ आरंभ करें।
  • लाइसेंसिंग, मूल्य निर्धारण के बारे में अधिक जानने के लिए या तकनीकी अवलोकन शेड्यूल करने के लिए हमसे संपर्क करें।

मूलतः YugaByte Database Blog पर प्रकाशित।