🌞 🤙🏽 👤 CQL3 में कैसेंड्रा 2.0 में डेटा मॉडलिंग 🏦 📰 ✋🏻

यह लेख कैसंड्रा डेटाबेस में अपना पहला "टेबल" बनाने की कोशिश कर रहे लोगों के लिए है।

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

त्याग

यह लेख उन लोगों के लिए अभिप्रेत नहीं है जो पहली बार कैसंड्रा शब्द को देखते हैं।
लेख किसी विशेष तकनीक की विज्ञापन सामग्री के रूप में काम नहीं करता है।
लेख किसी को कुछ भी साबित करने की कोशिश नहीं करता है।
यदि लिखने / पढ़ने की गति इतनी महत्वपूर्ण नहीं है, और यदि "100% अपटाइम" वास्तव में आवश्यक नहीं है, और यदि आपके पास केवल कुछ मिलियन रिकॉर्ड हैं, तो संभवतः यह लेख, और संपूर्ण कैसंड्रा एक संपूर्ण के रूप में है, जो आप नहीं हैं की जरूरत है।

शैक्षिक कार्यक्रम

कैसेंड्रा (इसके बाद C * ) एक वितरित NoSQL डेटाबेस है, इसलिए सभी निर्णय "ऐसा क्यों, और इस तरह नहीं" हमेशा क्लस्टरिंग के लिए एक आंख के साथ किए जाते हैं।
CQL एक SQL जैसी भाषा है। सी असेंद्रा क्यू uery एल पीड़ा के लिए संक्षिप्तिकरण।
ऑपरेटिंग सिस्टम के संदर्भ में नोड एक C * आवृत्ति या जावा प्रक्रिया है। आप एक ही मशीन पर कई नोड चला सकते हैं, उदाहरण के लिए।
बुनियादी भंडारण इकाई एक स्ट्रिंग है । पूरे स्ट्रिंग को नोड्स पर संग्रहीत किया जाता है, अर्थात। ऐसी कोई स्थिति नहीं है जब एक पंक्ति एक नोड पर हो, आधी रेखा दूसरे पर हो। एक पंक्ति गतिशील रूप से 2 बिलियन कॉलम तक विस्तारित हो सकती है। यह महत्वपूर्ण है।
cqlsh - CQL के लिए कमांड लाइन। नीचे दिए गए सभी उदाहरणों को इसमें निष्पादित किया गया है। यह सी * वितरण का हिस्सा है।

C * में बेसिक डेटा मॉडलिंग नियम

कासांद्रा अधिकतम वितरित लिखने और पढ़ने की गति पर जोर देने के साथ एक वितरित डेटाबेस के रूप में बनाया गया था। आपको अपने एप्लिकेशन के SELECT प्रश्नों के आधार पर "तालिकाओं" को मॉडल करने की आवश्यकता है ।
एसक्यूएल में, हम तालिकाओं को फेंकने, उनके बीच संबंधों और फिर SELECT ... JOIN ... करने के लिए उपयोग किया जाता है SELECT ... JOIN ... हम क्या चाहते हैं और हम कैसे चाहते हैं। RDBMS में प्रदर्शन के साथ जॉइन मुख्य समस्या है। वे CQL में नहीं हैं।

पहला उदाहरण।

हमारे पास किसी कंपनी के कर्मचारी हैं। आइए एक तालिका बनाते हैं (जिसे वास्तव में कॉलम परिवार कहा जाता है, लेकिन सीक्यूएल में एसक्यूएल से सीक्यूएल में संक्रमण की आसानी के लिए) सीक्यूएल में शब्द का उपयोग करें और इसे डेटा से भरें:

 CREATE TABLE employees ( name text, --   age int, -- -    role text, --  -  PRIMARY KEY (name)); --     INSERT INTO employees (name, age, role) VALUES ('john', 37, 'dev'); INSERT INTO employees (name, age, role) VALUES ('eric', 38, 'ceo');

C * में टेबल्स में एक PRIMARY KEY होनी चाहिए। इसका उपयोग नोड के लिए खोज करने के लिए किया जाता है जिसमें वांछित स्ट्रिंग संग्रहीत होता है।

डेटा पढ़ें:

 SELECT * FROM employees;

यह चित्र एक हाथ से सजाया cqlsh आउटपुट है।

यह एक संबंधपरक डेटाबेस से एक नियमित तालिका की तरह दिखता है। C * दो लाइनें बनाएगा।

चेतावनी! ये दो आंतरिक पंक्ति संरचनाएं हैं , न कि टेबल। यदि थोड़ा चालाक है, तो हम कह सकते हैं कि प्रत्येक पंक्ति एक छोटी मेज की तरह है। आगे स्पष्ट है।

दूसरा उदाहरण।

जटिल। कंपनी का नाम जोड़ें।

 CREATE TABLE employees ( company text, name text, age int, role text, PRIMARY KEY (company,name) --    :   company    name ); INSERT INTO employees (company, name, age, role) VALUES ('OSC', 'eric', 38, 'ceo'); INSERT INTO employees (company, name, age, role) VALUES ('OSC', 'john', 37, 'dev'); INSERT INTO employees (company, name, age, role) VALUES ('RKG', 'anya', 29, 'lead'); INSERT INTO employees (company, name, age, role) VALUES ('RKG', 'ben', 27, 'dev'); INSERT INTO employees (company, name, age, role) VALUES ('RKG', 'chan', 35, 'ops');

डेटा पढ़ें:

 SELECT * FROM employees;

प्राथमिक कुंजी पर ध्यान दें। मापदंडों में से पहला - company - एक वितरण कुंजी है, इसका उपयोग तब से नोड के लिए खोज करने के लिए किया जाएगा। दूसरी name कुंजी क्लस्टरिंग कुंजी है। वह एक कॉलम में बदल जाता है। यानी हम डेटा को कॉलम नाम में बदलते हैं। यह सामान्य चार बाइट्स के साथ 'एरिक' था, और कॉलम नाम का हिस्सा बन गया।

इस प्रकार अब आंतरिक संरचना दिखती है।

जैसा कि आप हमारे साथ देख सकते हैं:

दो कंपनियां - OSC और RKG । यहां केवल दो लाइनें बनाई गईं।
ग्रीन eric अपनी उम्र और भूमिका दो कोशिकाओं में संग्रहीत करता है। इसी तरह, बाकी सभी।
यह पता चला है कि इस तरह की संरचना के साथ, हम प्रत्येक कंपनी (लाइन) में 1 बिलियन कर्मचारियों को स्टोर कर सकते हैं। याद रखें कि कॉलम की संख्या पर सीमा 2 बिलियन है?
ऐसा लग सकता है कि हम एक बार फिर उसी डेटा को स्टोर कर रहे हैं। यह सच है, लेकिन सी * में इस तरह का डिज़ाइन सही मॉडलिंग पैटर्न है।
C * में मॉडलिंग करते समय स्ट्रिंग्स का विस्तार मुख्य विशेषता है।

तीसरा उदाहरण।

और भी कठिन। कैपिटल अक्षर कॉलम का नाम है। लोअरकेस - डेटा।

 CREATE TABLE example ( A text, B text, C text, D text, E text, F text, PRIMARY KEY ((A,B), C, D)); --    (A,B)    (C,D) INSERT INTO example (A, B, C, D, E, F) VALUES ('a', 'b', 'c', 'd', 'e', 'f'); INSERT INTO example (A, B, C, D, E, F) VALUES ('a', 'b', 'c', 'g', 'h', 'i'); INSERT INTO example (A, B, C, D, E, F) VALUES ('a', 'b', 'j', 'k', 'l', 'm'); INSERT INTO example (A, B, C, D, E, F) VALUES ('a', 'n', 'o', 'p', 'q', 'r'); INSERT INTO example (A, B, C, D, E, F) VALUES ('s', 't', 'u', 'v', 'w', 'x');

डेटा पढ़ें:

 SELECT * FROM example;

अब हमारी वितरण कुंजी समग्र है - (A,B) । क्लस्टर कुंजी भी समग्र है - C, D।

आंतरिक संरचना अधिक जटिल हो गई है। डेटा जैसे c, d, g, k, o, p, u, v कॉलम नामों में ई और एफ के साथ भाग लेते हैं:

जैसा कि आप देख सकते हैं, अब ए और बी के प्रत्येक अद्वितीय संयोजन स्ट्रिंग की एक कुंजी है।
हमारे पास केवल तीन विशिष्ट वितरण कुंजी हैं a:b , a:n और s:t ।
कॉलम कुंजियों के लिए धन्यवाद गुणक। a:b हमारे पास तीन अद्वितीय संयोजन हैं - c:d , c:g , j:k - जो कॉलम ई और एफ में वास्तविक डेटा को स्टोर करते हैं - e और f , h और i , l और m ।
इसी तरह दो अन्य लाइनें।

यह इतना जटिल क्यों है?

यह वितरित डेटाबेस में डेटा की अनंत मात्रा को रिकॉर्ड करने और संग्रहीत करने का सबसे तेज़ तरीका है। सी * को केवल लिखने / पढ़ने की गति पर जोर देने के साथ डिजाइन किया गया था। यहाँ, उदाहरण के लिए, MongoDB, HBase और C * गति की तुलना करता है ।

वास्तविक जीवन उदाहरण

हमारे पास कुछ घटनाएं हैं जो प्रति सेकंड 1000 गुना होती हैं। उदाहरण के लिए, संकेतक शोर स्तर के सेंसर से लिए जाते हैं। 10 सेंसर। उनमें से प्रत्येक प्रति सेकंड 100 बार डेटा भेजता है। हमारे 3 कार्य हैं:

डेटाबेस सर्वर (नोड) अपना काम बंद कर देता है तो लिखना जारी रखें।
1000 सेकंड में रिकॉर्ड करने का समय कोई मायने नहीं रखता है।
किसी भी मिलिसेकंड में किसी भी दिन किसी भी सेंसर का ग्राफ प्रदान करें।
जितनी जल्दी हो सके किसी भी समय के लिए किसी भी सेंसर का ग्राफ प्रदान करें।

पहला और दूसरा अंक आसान हैं।

हमें कई नोड्स स्थापित करने की आवश्यकता है, प्रत्येक स्वायत्त बनाएं। यह उनमें से एक को बादल में भी ले जा सकता है।

तीसरा बिंदु मुख्य चाल है।

हम एक दिन के डेटा को एक पंक्ति में संग्रहीत करेंगे।

 CREATE TABLE temperature_events_by_day ( day text, -- Text of the following format: 'YYYY-MM-DD' sensor_id uuid, event_time timestamp, temperature double, PRIMARY KEY ((day,sensor_id), event_time) --  .  (day,sensor_id)    (event_time) ) WITH CLUSTERING ORDER BY event_time DESC; --

चूंकि वितरण कुंजी दिन + सेंसर का एक अनूठा संयोजन है, इसलिए एक दिन के लिए डेटा प्रत्येक सेंसर के लिए एक अलग लाइन में संग्रहीत किया जाएगा। स्ट्रिंग के अंदर रिवर्स सॉर्टिंग के लिए धन्यवाद, हम "उंगलियों पर" हमारे लिए सबसे महत्वपूर्ण (अंतिम) डेटा प्राप्त करते हैं।
चूंकि वितरण कुंजी (दिन) की खोज C * में एक बहुत तेज संचालन है, इसलिए तीसरे बिंदु को पूरा माना जा सकता है।

चौथा बिंदु

बेशक, हम एक दिन / दिन खोज कर सकते हैं, जबकि दिन के अंदर हम पहले से ही टाइमस्टैम्प की तुलना कर सकते हैं। लेकिन कई दिन हो सकते हैं।
आखिरकार, हमारे पास केवल 10 सेंसर हैं। क्या इसका उपयोग किया जा सकता है? यह संभव है, यदि आप कल्पना करते हैं कि एक सेंसर एक पंक्ति है। इस स्थिति में, C * डिस्क पर सभी दस लाइनों के स्थान को याद रखता है।

चलो दूसरी तालिका बनाते हैं, जहां हम समान डेटा संग्रहीत करेंगे, लेकिन दिनों को छोड़कर।

 CREATE TABLE temperature_events ( sensor_id uuid, event_time timestamp, temperature double, PRIMARY KEY (sensor_id, event_time) --   (sensor_id)    (event_time) ) WITH CLUSTERING ORDER BY event_time DESC; --

और जब हम डेटा डालते हैं, तो हम प्रत्येक सेल के जीवनकाल को सीमित कर देंगे ताकि 2 बिलियन कॉलम की आदत न पड़े। हमारे साथ, प्रत्येक सेंसर प्रति सेकंड 100 से अधिक रीडिंग नहीं देता है। यहाँ से:
2**31 / (24 * 60 * 60 * 100 /) = 2147483648 / (24 * 60 * 60 * 100) = 248.55
248 दिनों के बाद, सबसे पुराना डेटा चुपचाप और चुपचाप हटा दिया जाना चाहिए।

 INSERT INTO temperature_events (sensor_id, event_time, temperature) VALUES ('12341234-1234-1234-123412', 2535726623061, 36.6) TTL 21427200; -- 248 days in seconds

एप्लिकेशन कोड में, यह शर्त सेट करना आवश्यक होगा कि यदि अनुरोधित डेटा पिछले 248 दिनों से आगे जाता है, तो हम तापमान_केवत्___ तालिका का उपयोग करते हैं, यदि नहीं, तो temperature_events । बाद के लिए खोज करना कई मिलीसेकंड तेज़ी से होगा।

“क्या बकवास है! एक दूसरी मेज क्यों? ”आप सोचेंगे मैं दोहराता हूं: सी * डेटाबेस में एक ही मूल्य को कई बार संग्रहीत करना आदर्श, सही मॉडल है। जीत इस प्रकार हैं:

दूसरी तालिका में डेटा लिखना पहले की तुलना में तेज़ है। कैसेंड्रा को नोड (एस) के लिए नहीं देखना होगा जिसमें एक नया मूल्य जोड़ना है। वह पहले से जान जाएगी।
डेटा पढ़ना भी बहुत तेज है। उदाहरण के लिए, यह नियमित अनुक्रमित, सामान्यीकृत SQL डेटाबेस से कई गुना बेहतर है।

सूत्रों का कहना है

मैं इसे इस क्रम में देखने की सलाह देता हूं।

वेबिनार - कैसेंड्रा के आंतरिक डेटा संरचना के लिए CQL3 मैप्स को समझना ।
वेबिनार - द डेटा मॉडल डेड, लॉन्ग लाइव द डेटा मॉडल है
वेबिनार - एक सुपर मॉडलर बनें
वेबिनार - दुनिया का अगला शीर्ष डेटा मॉडल
पूर्ण CQL3 प्रलेखन - कैसेंड्रा क्वेरी भाषा (CQL) v3

श्रृंखला में अगला लेख ।

UPD: शब्दावली का सुधार। "वितरण कुंजी" के साथ "मास्टर कुंजी" शब्दों को सही स्थानों पर प्रतिस्थापित किया। कुछ स्थानों में "क्लस्टर कुंजी" की अवधारणा को जोड़ा गया।

CQL3 में कैसेंड्रा 2.0 में डेटा मॉडलिंग