Cassandra सरल डेटाबेस उदाहरण के साथ डेटा मॉडल

हालांकि Cassandra क्वेरी भाषा मिलती-जुलती है एसक्यूएल भाषा के संदर्भ में, उनकी डेटा मॉडलिंग पद्धतियां पूरी तरह से भिन्न हैं।

In Cassandraएक खराब डेटा मॉडल प्रदर्शन को ख़राब कर सकता है, खासकर जब उपयोगकर्ता RDBMS अवधारणाओं को लागू करने का प्रयास करते हैं Cassandraनीचे दिए गए कुछ नियमों को ध्यान में रखना सबसे अच्छा है।

Cassandra डेटा मॉडल नियम

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

लेखन की संख्या अधिकतम करें

In Cassandra, लेखन बहुत सस्ता है. Cassandra इसे उच्च लेखन प्रदर्शन के लिए अनुकूलित किया गया है। इसलिए बेहतर पठन प्रदर्शन और डेटा उपलब्धता के लिए अपने लेखन को अधिकतम करने का प्रयास करें। डेटा लेखन और डेटा पठन के बीच एक संतुलन होता है। इसलिए, डेटा लेखन की संख्या को अधिकतम करके अपने डेटा पठन प्रदर्शन को अनुकूलित करें।

डेटा डुप्लिकेशन को अधिकतम करें

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

Cassandra डेटा मॉडलिंग लक्ष्य

डेटा मॉडलिंग करते समय आपके पास निम्नलिखित लक्ष्य होने चाहिए Cassandra:

डेटा को समान रूप से चारों ओर फैलाएं Cluster

आप प्रत्येक नोड पर समान मात्रा में डेटा चाहते हैं Cassandra Clusterडेटा को विभाजन कुंजी (जो प्राथमिक कुंजी का पहला भाग है) के आधार पर विभिन्न नोड्स में वितरित किया जाता है। इसलिए, क्लस्टर में डेटा को समान रूप से वितरित करने के लिए उच्च कार्डिनैलिटी वाले कॉलम को विभाजन कुंजी के रूप में चुनने का प्रयास करें।

डेटा क्वेरी करते समय पढ़े जाने वाले विभाजनों की संख्या न्यूनतम करें

विभाजन एक ही विभाजन कुंजी वाले रिकॉर्ड का एक समूह है। जब रीड क्वेरी जारी की जाती है, तो यह अलग-अलग विभाजनों से अलग-अलग नोड्स से डेटा एकत्र करता है।

यदि कई विभाजन होंगे, तो क्वेरी डेटा एकत्र करने के लिए इन सभी विभाजनों पर जाना होगा।

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

इसलिए विभाजनों की संतुलित संख्या चुनने का प्रयास करें।

अच्छी प्राथमिक कुंजी Cassandra

ऊपर दिए गए दोनों लक्ष्य एक ही निर्णय पर आधारित हैं, इसलिए नीचे दिए गए दो आरेख एक ही तालिका को पहले एक खराब कुंजी और फिर एक सही कुंजी के साथ दिखाते हैं।

आइए एक उदाहरण लेते हैं और पता लगाते हैं कि कौन सी प्राथमिक कुंजी अच्छी है।

यहां संगीत प्लेलिस्ट तालिका है।

CREATE TABLE MusicPlaylist (
    SongId int,
    SongName text,
    Year int,
    Singer text,
    PRIMARY KEY (SongId, SongName)
);

उपरोक्त उदाहरण में, तालिका MusicPlaylist,

• SongId विभाजन कुंजी है, और
• SongName क्लस्टरिंग कॉलम है
• डेटा को SongName के आधार पर क्लस्टर किया जाएगा। प्रत्येक SongId के लिए केवल एक विभाजन बनाया जाएगा, और चूंकि प्रत्येक गीत का एक अलग पहचानकर्ता होता है, इसलिए प्रत्येक विभाजन में एक ही पंक्ति होगी।

खराब प्राथमिक कुंजी के कारण इस डेटा मॉडल द्वारा डेटा पुनर्प्राप्ति धीमी होगी।

यहाँ एक और तालिका है MusicPlaylist.

CREATE TABLE MusicPlaylist (
    SongId int,
    SongName text,
    Year int,
    Singer text,
    PRIMARY KEY ((SongId, Year), SongName)
);

उपरोक्त उदाहरण में, तालिका MusicPlaylist,

• SongId और Year विभाजन कुंजी हैं, और
• SongName क्लस्टरिंग कॉलम है.
• SongName के आधार पर डेटा को क्लस्टर किया जाएगा। इस टेबल में हर साल एक नया पार्टीशन बनाया जाएगा। साल के सभी गाने एक ही नोड पर होंगे। यह प्राइमरी की डेटा के लिए बहुत उपयोगी होगी।

इस डेटा मॉडल से हमारी डेटा पुनर्प्राप्ति तेज़ हो जाएगी।

अपने डेटा को मॉडल करें Cassandra

अपने प्रश्नों को तैयार करते समय निम्नलिखित बातों को ध्यान में रखना चाहिए:

निर्धारित करें कि आप किन प्रश्नों का समर्थन करना चाहते हैं

सबसे पहले, यह निर्धारित करें कि आप क्या प्रश्न चाहते हैं।

उदाहरण के लिए, क्या आपको ज़रूरत है?

• जुड़ती
• समूह द्वारा
• किस कॉलम पर फ़िल्टर करना है आदि।

अपनी क्वेरी के अनुसार तालिका बनाएं

अपनी क्वेरीज़ के अनुसार टेबल बनाएँ। ऐसी टेबल बनाएँ जो आपकी क्वेरीज़ को संतुष्ट करे। टेबल को इस तरह बनाने की कोशिश करें कि कम से कम संख्या में पार्टिशन को पढ़ने की ज़रूरत पड़े।

आगे आने वाले तीन खंड उस सिद्धांत को लगभग हर स्कीमा में पाए जाने वाले तीन प्रकार के संबंधों पर लागू करते हैं।

एक से एक रिश्ते को संभालना Cassandra

एक से एक संबंध का मतलब है कि दो तालिकाओं में एक से एक पत्राचार है। उदाहरण के लिए, छात्र केवल एक ही कोर्स रजिस्टर कर सकता है, और मैं एक छात्र पर यह खोजना चाहता हूं कि कोई विशेष छात्र किस कोर्स में रजिस्टर है।

इस मामले में, आपकी तालिका स्कीमा में उस विशेष पाठ्यक्रम से संबंधित छात्र के सभी विवरण शामिल होने चाहिए जैसे पाठ्यक्रम का नाम, छात्र का रोल नंबर, छात्र का नाम आदि।

ऊपर दिया गया आरेख क्वेरी को हल करने वाली एक ही तालिका को दर्शाता है, क्योंकि एक छात्र ठीक एक ही पाठ्यक्रम से संबंधित होता है।

CREATE TABLE Student_Course (
    Student_rollno int PRIMARY KEY,
    Student_name text,
    Course_name text
);

क्योंकि Student_rollno विभाजन कुंजी है, इसलिए रोल नंबर द्वारा खोज करने पर ठीक एक ही विभाजन पढ़ा जाता है।

एक से अनेक संबंधों को संभालना Cassandra

एक से अनेक संबंधों का अर्थ है दो तालिकाओं के बीच एक से अनेक पत्राचार होना।

उदाहरण के लिए, एक कोर्स का अध्ययन कई छात्र कर सकते हैं। मैं उन सभी छात्रों को खोजना चाहता हूँ जो एक विशेष कोर्स का अध्ययन कर रहे हैं।

इसलिए पाठ्यक्रम के नाम पर पूछताछ करने पर, मुझे कई छात्रों के नाम मिलेंगे जो एक विशेष पाठ्यक्रम का अध्ययन कर रहे होंगे।

यहां पाठ्यक्रम का नाम विभाजन कुंजी बन जाता है ताकि एक ही पाठ्यक्रम में नामांकित प्रत्येक छात्र एक ही विभाजन में आ जाए, और रोल नंबर क्लस्टरिंग कॉलम बन जाता है ताकि प्रत्येक छात्र एक अलग पंक्ति में बना रहे।

CREATE TABLE Student_Course (
    Course_name text,
    Student_rollno int,
    Student_name text,
    PRIMARY KEY (Course_name, Student_rollno)
);

मैं निम्नलिखित क्वेरी द्वारा किसी विशेष पाठ्यक्रम के सभी छात्रों को पुनः प्राप्त कर सकता हूं।

SELECT * FROM Student_Course WHERE Course_name = 'Course Name';

अनेक से अनेक संबंधों को संभालना Cassandra

अनेक से अनेक संबंधों का अर्थ है दो तालिकाओं के बीच अनेक से अनेक पत्राचार होना।

उदाहरण के लिए, एक पाठ्यक्रम का अध्ययन कई छात्र कर सकते हैं, और एक छात्र भी कई पाठ्यक्रमों का अध्ययन कर सकता है।

मैं उन सभी छात्रों को खोजना चाहता हूं जो एक विशेष पाठ्यक्रम का अध्ययन कर रहे हैं। साथ ही, मैं उन सभी पाठ्यक्रमों को खोजना चाहता हूं जो एक विशेष छात्र पढ़ रहा है।

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

सबसे पहले, मैं एक तालिका बनाऊंगा जिसके द्वारा आप किसी विशेष छात्र द्वारा चुने गए पाठ्यक्रम ढूंढ सकेंगे।

CREATE TABLE Student_Course (
    Student_rollno int,
    Course_name text,
    Student_name text,
    PRIMARY KEY (Student_rollno, Course_name)
);

मैं निम्नलिखित क्वेरी द्वारा किसी विशेष छात्र के सभी पाठ्यक्रम पा सकता हूँ।

SELECT * FROM Student_Course WHERE Student_rollno = 101;

दूसरा, मैं एक तालिका बनाऊंगा जिससे आप यह जान सकेंगे कि कितने छात्र किसी विशेष पाठ्यक्रम का अध्ययन कर रहे हैं।

CREATE TABLE Course_Student (
    Course_name text,
    Student_rollno int,
    Student_name text,
    PRIMARY KEY (Course_name, Student_rollno)
);

मैं निम्नलिखित क्वेरी द्वारा किसी विशेष पाठ्यक्रम में छात्र ढूंढ सकता हूं।

SELECT * FROM Course_Student WHERE Course_name = 'Cassandra';

जब भी कोई छात्र किसी कोर्स में शामिल होता है, तो दोनों तालिकाओं में डेटा लिखा जाना चाहिए, आमतौर पर एक ही लॉग किए गए बैच के भीतर ताकि दोनों प्रतियां एक साथ काम करती रहें।

सामान्य Cassandra डेटा मॉडलिंग की गलतियाँ

अधिकांश खराब योजनाएँ कुछ चुनिंदा त्रुटियों को दोहराती हैं, और प्रत्येक tracयह रिलेशनल डिजाइन से चली आ रही एक आदत पर आधारित है।

• असीमित विभाजन: किसी देश के नाम जैसी विभाजन कुंजी चुनने से लाखों पंक्तियाँ एक ही विभाजन में आ जाती हैं। विभाजनों का आकार उचित सीमा में रखने के लिए, समय अंतराल (जैसे देश, महीना) जोड़ें।
• बहुत कम संख्या वाली कुंजियाँ: एक विभाजन कुंजी जिसमें केवल कुछ ही संभावित मान होते हैं, जैसे कि एक स्थिति ध्वज, सभी ट्रैफ़िक को कुछ नोड्स पर केंद्रित करता है और बाकी को निष्क्रिय छोड़ देता है।
• ALLOW FILTERING का उपयोग करके क्वेरी को क्रियाशील बनाना: यह प्रत्येक विभाजन को स्कैन करता है और मॉडलिंग संबंधी समस्या को छुपाता है। यदि किसी क्वेरी को इसकी आवश्यकता होती है, तो स्कीमा में एक और तालिका की आवश्यकता होती है।
• क्वेरी के बजाय एंटिटीज़ का मॉडलिंग करना: छात्रों की तालिका और पाठ्यक्रमों की तालिका बनाना, और फिर उन्हें एप्लिकेशन में जोड़ने का प्रयास करना, डिजाइन के उद्देश्य को ही विफल कर देता है।
• बार-बार डिलीट और ओवरराइट करना: प्रत्येक डिलीट एक टॉम्बस्टोन लिखता है जिसे कॉम्पैक्शन द्वारा हटाए जाने तक पढ़ा जाना चाहिए और छोड़ दिया जाना चाहिए, जिससे हॉट पार्टीशन पर रीड स्पीड धीमी हो जाती है।

इनसे बचने से योजना इस पृष्ठ के शीर्ष पर बताए गए नियमों और नीचे संक्षेप में दिए गए संबंधपरक विरोधाभासों के अनुरूप बनी रहती है।

आरडीबीएमएस और के बीच अंतर Cassandra डेटा मॉडलिंग

इन योजना संबंधी निर्णयों को व्यवहार में लागू किया जाता है Cassandra तालिका और keyspace ट्यूटोरियल।

अक्सर पूछे जाने वाले प्रश्न