डब्ल्यूटीएफ एक सुपरकोल्यूम है? कैसेंड्रा डेटा मॉडल का परिचय

यह 1 सितंबर 2009 के एक लेख का अनुवाद है, जिसे इसे पढ़ते समय ध्यान में रखा जाना चाहिए। - लगभग। प्रति।



पिछले महीने या दो में, डिग इंजीनियरिंग टीम ने कैसंड्रा के उत्पादन पर शोध, परीक्षण और अंतिम रूप देने में काफी समय बिताया। यह एक बहुत ही मजेदार प्रोजेक्ट था, लेकिन मस्ती शुरू होने से पहले, हमें कुछ समय लगाना था जिसमें पता चलता है कि कैसंड्रा डेटा मॉडल क्या है ... वाक्यांश "डब्ल्यूटीएफ एक" सुपर कॉलम "है (" यह सुपर कॉलम क्या है ? ”) का उच्चारण एक से अधिक बार किया गया था।



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

चिप्स

पहले, चलिए बिल्डिंग ब्लॉक्स पर एक नज़र डालते हैं, इससे पहले कि हम देखते हैं कि वे सभी एक साथ कैसे काम कर सकते हैं।

स्तंभ

कॉलम एक न्यूनतम डेटा तत्व है। यह एक ट्रिपल नाम, मान और टाइमस्टैम्प है। JSON अंकन में प्रदान किया गया कॉलम:

{

name: "emailAddress" , //

value: "arin@example.com" , //

timestamp: 123456789 //

}

वह सब है। सादगी के लिए, आप टाइमस्टैम्प को छोड़ सकते हैं। और कॉलम को नाम / मान युग्म के रूप में देखता है। इसके अलावा, यह ध्यान देने योग्य है कि नाम और मूल्य दोनों द्विआधारी (तकनीकी रूप से बाइट []) हैं और किसी भी लम्बाई के हो सकते हैं।

SuperStolbets

सुपरकोल्यूम एक बाइनरी नाम और मूल्य का एक संयोजन है, जो मूल रूप से एक स्तंभ है जिसमें असीमित संख्या में कॉलम होते हैं, जिसमें कुंजी का कॉलम नाम होता है। फिर, इसे JSON के रूप में कल्पना करें:

{

name: "homeAddress" ,

// :

value: {

// -

street: {name: "street" , value: "1234 x street" , timestamp: 123456789},

city: {name: "city" , value: "san francisco" , timestamp: 123456789},

zip: {name: "zip" , value: "94107" , timestamp: 123456789},

}

}

कॉलम बनाम सुपरकोल्यूम

दोनों कॉलम और सुपर कॉलम नाम और मूल्य जोड़े हैं। मुख्य अंतर यह है कि एक नियमित स्तंभ का मूल्य एक पंक्ति है, और एक सुपर कॉलम का मूल्य स्तंभों की एक तालिका है। यह मुख्य अंतर है। उनके मूल्यों में विभिन्न प्रकार के डेटा होते हैं। एक और मामूली अंतर यह है कि सुपरक्यूलिम में टाइमस्टैम्प नहीं होता है।

इससे पहले कि हम गठबंधन करना शुरू करें

आगे बढ़ने से पहले, मैं दो चीजों के साथ हमारे अंकन को सरल बनाना चाहता हूं: 1) कॉलम में टाइमस्टैम्प को अलविदा कहें और 2) कॉलम और सुपरकॉल्यूमन्स के नामों को खींच लें, ताकि यह एक कुंजी / मूल्य जोड़ी की तरह दिखे। इस प्रकार, हम यहां से चले जाएंगे:

{

name: "homeAddress" ,

value: {

street: {name: "street" , value: "1234 x street" , timestamp: 123456789},

city: {name: "city" , value: "san francisco" , timestamp: 123456789},

zip: {name: "zip" , value: "94107" , timestamp: 123456789},

}

}

को

homeAddress: {

street: "1234 x street" ,

city: "san francisco" ,

zip: "94107" ,

}

उन्हें समूह

स्तंभ और सुपर कॉलम दोनों को समूहित करने के लिए उपयोग की जाने वाली एक संरचना है ... इस संरचना को कॉलमफैमिली परिवार कहा जाता है और यह क्रमशः, नियमित और सुपर दो रूपों में मौजूद है।

स्तम्भ परिवार

एक स्तंभ परिवार एक संरचना है जिसमें असीमित संख्या में पंक्तियां होती हैं। वाह, क्या आपने लाइनें बताईं? हाँ - पंक्तियाँ :) अपने सिर में फिट होना आसान बनाने के लिए, बस उन्हें आरडीबीएमएस में तालिका पंक्तियों के रूप में सोचें।



इसलिए, प्रत्येक पंक्ति में क्लाइंट (आप) द्वारा एक कुंजी सेट की जाती है और इसमें कॉलम का एक सेट होता है। फिर, सेट में कुंजियाँ स्तंभ नाम हैं और मान स्वयं स्तंभ हैं:

UserProfile = {

phatduckk: { //

//

username: "phatduckk" ,

email: "phatduckk@example.com" ,

phone: "(900) 976-6666"

}, //

ieure: { //

//

username: "ieure" ,

email: "ieure@example.com" ,

phone: "(888) 555-1212"

age: "66" ,

gender: "undecided"

},

}

याद रखें: सादगी के लिए हम केवल स्तंभ का मान दिखाते हैं, लेकिन वास्तव में सेट में दिए गए मान पूरे स्तंभ होते हैं।



आप इसे हैश टेबल / डिक्शनरी या एसोसिएटिव ऐरे के रूप में सोच सकते हैं। अगर आप ऐसा सोचने लगे हैं, तो आप सही रास्ते पर हैं।



मैं इस तथ्य पर आपका ध्यान आकर्षित करना चाहता हूं कि इस स्तर पर कोई अनिवार्य योजना नहीं है। पंक्तियों में उन स्तंभों की पूर्वनिर्धारित सूची नहीं होती है जिनमें वे होते हैं। ऊपर हमारे उदाहरण में, आप देखते हैं कि "ieure" कुंजी वाली पंक्ति में "आयु" और "लिंग" नाम के कॉलम हैं, जबकि "phatduckk" कुंजी द्वारा पहचानी गई पंक्ति नहीं है। यह एक सौ प्रतिशत लचीलापन है: एक पंक्ति में 1989 कॉलम हो सकते हैं, जबकि दूसरा केवल 2 होगा। एक पंक्ति में "फू" नाम का कॉलम हो सकता है, जबकि बाकी सभी नहीं होंगे। यहाँ यह है - कैसंड्रा में सर्किटरी की कमी की संभावना।

कॉलम परिवार भी सुपर हो सकता है

तो एक कॉलम परिवार मानक या सुपर प्रकार का हो सकता है।



हमने ऊपर जो जांच की वह मानक प्रकार का एक उदाहरण था। यह मानक है क्योंकि इसकी सभी पंक्तियों में साधारण (सुपर नहीं) स्तंभों की तालिका है ... कोई सुपर कॉलम नहीं हैं।



यदि स्तंभों का परिवार सुपर का है, तो इसके विपरीत: प्रत्येक पंक्ति में सुपर कॉलम का एक सेट होता है। एक सेट जहां कुंजियाँ सुपर कॉलम के नाम हैं और मान स्वयं सुपर कॉलम हैं। और, सिर्फ स्पष्टता के लिए: सुपरकूल परिवार में नियमित कॉलम नहीं होते हैं। यहाँ एक उदाहरण है:

AddressBook = {

phatduckk: { //

// -



//

// -

// -

friend1: {street: "8th street" , zip: "90210" , city: "Beverley Hills" , state: "CA" },



// John' phatduckk'

John: {street: "Howard street" , zip: "94404" , city: "FC" , state: "CA" },

Kim: {street: "X street" , zip: "87876" , city: "Balls" , state: "VA" },

Tod: {street: "Jerry street" , zip: "54556" , city: "Cartoon" , state: "CO" },

Bob: {street: "Q Blvd" , zip: "24252" , city: "Nowhere" , state: "MN" },

...

//

}, //

ieure: { //

joey: {street: "A ave" , zip: "55485" , city: "Hell" , state: "NV" },

William: {street: "Armpit Dr" , zip: "93301" , city: "Bakersfield" , state: "CA" },

},

}

मुख्य स्थान

एक कीस्पेस आपके सभी डेटा को जोड़ती है। आपके सभी कॉलम परिवार मुख्य स्थान पर हैं। आपका कीस्पेस संभवतः आपके आवेदन से मेल खाएगा।



तो, प्रमुख स्थान में कॉलम के कई परिवार हो सकते हैं, लेकिन इसका मतलब यह नहीं है कि वे किसी तरह एक-दूसरे पर निर्भर होंगे। उदाहरण के लिए, वे MySQL में तालिकाओं की तरह शामिल नहीं हो सकते हैं। इसके अलावा, सिर्फ इसलिए कि ColumnFamily_1 में "phatduckk" कुंजी के साथ एक स्ट्रिंग है, इसका मतलब यह नहीं है कि ColumnFamily_2 में भी यह शामिल है।

छंटाई

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



पंक्तियों के अंदर कॉलम हमेशा कॉलम नाम से क्रमबद्ध होते हैं। यह महत्वपूर्ण है, इसलिए मैं दोहराता हूं: कॉलम हमेशा नाम से क्रमबद्ध होते हैं! कैसे नामों की तुलना की जाती है यह कॉलम परिवार के तुलना पैरामीटर पर निर्भर करता है। डिफ़ॉल्ट रूप से, आपके पास निम्न विकल्प हैं: बाइट्स टाइप, UTF8Type, LexicalUUIDType, TimeUUIDType, AsciiType और LongType। इनमें से प्रत्येक विकल्प कॉलम नामों को विभिन्न डेटा प्रकारों के रूप में मानता है, कुछ लचीलापन प्रदान करता है। उदाहरण के लिए: LongType का उपयोग कॉलम नामों को 64-बिट पूर्णांक के रूप में करेगा। आइए छाँटने से पहले और बाद के आंकड़ों को देखकर इसे स्पष्ट करें:

// ,

// Cassandra "" .

// , -

{name: 123, value: "hello there" },

{name: 832416, value: "kjjkbcjkcbbd" },

{name: 3, value: "101010101010" },

{name: 976, value: "kjjkbcjkcbbd" }

इसलिए, यह देखते हुए कि हम LongType संस्करण का उपयोग कर रहे हैं, ये कॉलम छँटने के बाद इस तरह दिखेंगे:

<!-- storage-conf.xml -->

< ColumnFamily CompareWith ="LongType" Name ="CF_NAME_HERE" />

// ,

// ,

{name: 3, value: "101010101010" },

{name: 123, value: "hello there" },

{name: 976, value: "kjjkbcjkcbbd" },

{name: 832416, value: "kjjkbcjkcbbd" }

जैसा कि आप देख सकते हैं, स्तंभ नामों की तुलना की गई जैसे कि वे 64-बिट पूर्णांक थे। यदि हम अभी एक अन्य तुलना विकल्प का उपयोग करते हैं, तो हमें एक अलग परिणाम मिलेगा। अगर हम तुलना को UTF8Type के रूप में सेट करते हैं, तो स्तंभ नामों को UTF8 एन्कोडेड स्ट्रिंग्स के रूप में माना जाएगा और इस क्रम को बनाएं:

<!-- storage-conf.xml -->

< ColumnFamily CompareWith ="UTF8Type" Name ="CF_NAME_HERE" />

// UTF8

{name: 123, value: "hello there" },

{name: 3, value: "101010101010" },

{name: 832416, value: "kjjkbcjkcbbd" },

{name: 976, value: "kjjkbcjkcbbd" }

एक पूरी तरह से अलग परिणाम!



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

//

//



{ //

name: "workAddress" ,

//

value: {

street: {name: "street" , value: "1234 x street" },

city: {name: "city" , value: "san francisco" },

zip: {name: "zip" , value: "94107" }

}

},

{ //

name: "homeAddress" ,

//

value: {

street: {name: "street" , value: "1234 x street" },

city: {name: "city" , value: "san francisco" },

zip: {name: "zip" , value: "94107" }

}

}

अब, अगर हम तुलना करने का निर्णय लेते हैं, तो तुलना करें और यूएफएफ टाइप से तुलना करें, हमें निम्नलिखित प्रश्न मिलते हैं:

//



{

name: "homeAddress" ,

value: {

city: {name: "city" , value: "san francisco" },

street: {name: "street" , value: "1234 x street" },

zip: {name: "zip" , value: "94107" }

}

},

{

name: "workAddress" ,

value: {

city: {name: "city" , value: "san francisco" },

street: {name: "street" , value: "1234 x street" },

zip: {name: "zip" , value: "94107" }

}

}

पिछले उदाहरण में, ComparSubcolumnsWith और तुलना के साथ दोनों UTF8Type पर सेट हैं, लेकिन यह आवश्यक नहीं है। आप जैसा चाहें वैसा ही UseSubcolumnsWith और Comparison के मूल्यों को जोड़ सकते हैं।



और आखिरी चीज जो मैं छँटाई के सिलसिले में बताना चाहता हूँ, वह यह है कि आप छँटाई करने के लिए अपनी कक्षा लिख ​​सकते हैं। छँटाई तंत्र स्वतंत्र रूप से जुड़ा हुआ है ... आप इस श्रेणी के रूप में जैसे ही org.apache.cassandra.db.marshal.IType इंटरफ़ेस को लागू करता है (आप छँटाई के लिए अपनी तुलना योजना बना सकते हैं) किसी भी उपयुक्त वर्ग के नाम के साथ ComparSubcolumnsWith और / या तुलना कर सकते हैं। ।

सर्किट उदाहरण

ठीक है, अब हमारे पास पहेली के सभी टुकड़े हैं, तो चलो उन्हें एक साथ रखें और एक साधारण ब्लॉग एप्लिकेशन को मॉडल करें। हम निम्नलिखित विनिर्देशों के साथ एक आवेदन का अनुकरण करेंगे:

• एकल ब्लॉग समर्थन
• कई लेखक हो सकते हैं
• रिकॉर्ड में एक शीर्षक, निकाय, अद्वितीय लेबल और प्रकाशन तिथि होती है
• प्रविष्टियाँ किसी भी संख्या के टैग से जुड़ी हो सकती हैं
• लोग टिप्पणियां छोड़ सकते हैं, लेकिन वे पंजीकरण नहीं कर सकते: वे हर बार फिर से अपने बारे में जानकारी दर्ज करते हैं (बस सरलीकृत करें)
• टिप्पणियों में पाठ होता है, समय जब उन्हें छोड़ दिया गया था, और टिप्पणीकार का नाम
• रिवर्स कालानुक्रमिक क्रम में सभी पोस्ट दिखाने में सक्षम होना चाहिए (शीर्ष पर सबसे नया)
• रिवर्स कालानुक्रमिक क्रम में टैग द्वारा सभी पोस्ट दिखाने में सक्षम होना चाहिए

निम्न में से प्रत्येक अनुभाग कॉलम परिवार का वर्णन करेगा जिसे हम अपने आवेदन के प्रमुख स्थान में परिभाषित करेंगे, एक्सएमएल में परिभाषा दिखाते हैं, कहते हैं कि हमने एक या दूसरे छँटाई विकल्प को क्यों चुना, और कॉलम परिवार के डेटा को भी JSON के रूप में दिखाएं।

लेखक कॉलम परिवार

लेखकों का एक कॉलम परिवार बनाना काफी बुनियादी है; हमने यहां कुछ भी अच्छा नहीं किया। हम प्रत्येक लेखक को एक पंक्ति और एक कुंजी सौंपेंगे और यह लेखक का पूरा नाम होगा। पंक्ति में प्रत्येक स्तंभ एक विशिष्ट लेखक प्रोफ़ाइल पैरामीटर का प्रतिनिधित्व करेगा।



यह वस्तुओं के रूप में तार का उपयोग करने का एक उदाहरण है ... इस मामले में, लेखक ऑब्जेक्ट। इस दृष्टिकोण के साथ, प्रत्येक कॉलम ऑब्जेक्ट की संपत्ति के रूप में काम करेगा। बहुत सरल है। मैं यह नोट करना चाहता हूं कि चूंकि स्तंभों को एक पंक्ति में कैसे दर्शाया जाना चाहिए, इसकी कोई परिभाषा नहीं है, हम इस परिभाषा को स्वयं परिभाषित कर सकते हैं।



हम कुंजी का उपयोग करके अपने कॉलम परिवार से पंक्तियों को प्राप्त करेंगे और प्रत्येक पंक्ति के लिए सभी कॉलम चुनें (यानी, उदाहरण के लिए, हम कुंजी "फू" के साथ पंक्ति से केवल पहले 3 कॉलम का चयन नहीं करेंगे)। इसका मतलब यह है कि यह हमारे लिए मायने नहीं रखता है कि कॉलम कैसे छाँटे जाते हैं, इसलिए हम बाइट्स टाइप छँटाई का उपयोग करेंगे क्योंकि इसमें कॉलम नामों के लिए किसी सत्यापन की आवश्यकता नहीं होती है।

<!--

ColumnFamily: Authors

.



=> (, )

: (email, bio ..)

:



: ( )



Authors : { //

Arin Sarkissian : { //

// ,

numPosts: 11,

twitter: phatduckk,

email: arin@example.com,

bio: "bla bla bla"

},

//

Author 2 {

...

}

}

-->

< ColumnFamily CompareWith ="BytesType" Name ="Authors" />

BlogEntries कॉलम परिवार

फिर से, कॉलम परिवार एक साधारण कुंजी / मान स्टोर की तरह व्यवहार करेगा। हम एक लाइन पर एक रिकॉर्ड संचित करेंगे। पंक्तियों में कॉलम रिकॉर्डिंग मापदंडों के रूप में काम करेगा: हेडर, बॉडी, आदि। (पिछले उदाहरण के समान)। थोड़े अनुकूलन के साथ, हम एक कॉलम में अल्पविराम द्वारा अलग किए गए स्ट्रिंग के रूप में टैग को असामान्य करते हैं। आउटपुट में, हम टैग की एक सूची प्राप्त करने के लिए कॉलम मान को विभाजित करेंगे।



प्रत्येक पंक्ति की कुंजी एक अद्वितीय लेबल (स्लग) होगी। इसलिए, एकल रिकॉर्ड का चयन करने के लिए, हम इस लेबल के द्वारा खोज करेंगे।

<!--

ColumnFamily: BlogEntries

.



=> ( )

: (, , ..)

:



: ( )



: tags ... .

JSON, , ,

, ,



BlogEntries : { //

i-got-a-new-guitar : { // - (slug)

title: This is a blog entry about my new, awesome guitar,

body: this is a cool entry. etc etc yada yada

author: Arin Sarkissian // Authors

tags: life,guitar,music

pubDate: 1250558004 // unixtime

slug: i-got-a-new-guitar

},

//

another-cool-guitar : {

...

tags: guitar,

slug: another-cool-guitar

},

scream-is-the-best-movie-ever : {

...

tags: movie,horror,

slug: scream-is-the-best-movie-ever

}

}

-->

< ColumnFamily CompareWith ="BytesType" Name ="BlogEntries" />

TaggedPosts कॉलम परिवार

तो अंत में कुछ दिलचस्प होगा। स्तंभों का यह परिवार हमें एक नया स्तर दिखाएगा। यह टैग और पोस्ट के बीच लिंक संग्रहीत करने के लिए जिम्मेदार होगा। यह न केवल लिंक को संग्रहीत करेगा, बल्कि हमें एक विशिष्ट टैग द्वारा सभी ब्लॉग प्रविष्टियों का चयन करने की भी अनुमति देता है, क्रमबद्ध क्रम में (सब कुछ हम छँटाई के बारे में जानते हैं? याद रखें?)।



समाधान की ख़ासियत जो मैं नोट करना चाहता हूं, वह यह है कि हमारे आवेदन का तर्क प्रत्येक ब्लॉगईट्री पोस्ट को टैग "__notag__" संलग्न करना चाहिए (मैंने अभी इसका आविष्कार किया था)। ऐसा टैग हमें स्तंभों के इस परिवार का उपयोग सभी ब्लॉग प्रविष्टियों की सूची को क्रमबद्ध रूप में संग्रहीत करने के लिए करने की अनुमति देगा। यह एक छोटी सी चाल है जो दो नमूनों के लिए कॉलम के केवल एक परिवार का उपयोग करना संभव बनाएगी: "सभी अंतिम पोस्ट दिखाएं" और "सभी अंतिम पोस्ट को 'foo` टैग के साथ दिखाएं।"



इस डेटा मॉडल के अनुसार, तीन टैग के साथ रिकॉर्ड 4 पंक्तियों में 1 कॉलम के अनुरूप होगा। प्रत्येक टैग के लिए एक और सेवा टैग "__notag__" के लिए एक।



चूँकि हमने तय किया कि हम कालानुक्रमिक क्रम में अभिलेखों की सूचियाँ प्रदर्शित करेंगे, इसलिए हमें TimeUUID प्रकार के स्तंभ नाम बनाने और TimeWUIDType से तुलना पैरामीटर सेट करने की आवश्यकता है। यह समय के अनुसार स्तंभों को क्रमबद्ध करेगा। इसलिए "foo` टैग के साथ" पिछले 10 रिकॉर्ड प्राप्त करें जैसे प्रश्नों का उपयोग करना एक बहुत ही कुशल संचालन होगा।



अब, जब हम अंतिम 10 प्रविष्टियाँ प्रदर्शित करना चाहते हैं (उदाहरण के लिए, उदाहरण के लिए), तो हमें इसकी आवश्यकता होगी:

1. कुंजी "__notag__" के साथ अंतिम 10 कॉलम लें (टैग "सभी पोस्ट")
2. स्तंभों के इस सेट के माध्यम से लूप
3. एक लूप में, हम जानते हैं कि प्रत्येक स्तंभ का मान BlogEntries स्तंभ परिवार में पंक्ति कुंजी है
4. इसलिए हम BlogEntries कॉलम परिवार से इस प्रविष्टि के लिए पंक्ति प्राप्त करने के लिए इस कुंजी का उपयोग करते हैं। इसलिए हम रिकॉर्ड के बारे में सभी डेटा प्राप्त करते हैं
5. BlogEntries रो में मौजूद कॉलमों में से एक को लेखक का नाम दिया गया है और इसका मान लेखक कॉलम परिवार की कुंजी है, और हम लेखक की प्रोफ़ाइल जानकारी प्राप्त करने के लिए इसका उपयोग करते हैं
6. इसलिए हमारे पास पोस्ट डेटा और लेखक डेटा है
7. फिर हम टैग की सूची प्राप्त करने के लिए टैग के साथ कॉलम को तोड़ते हैं
8. अब हमारे पास इस पोस्ट को प्रदर्शित करने के लिए सब कुछ है (अब तक टिप्पणी के बिना यह पोस्ट की सूची का एक पृष्ठ है, विशिष्ट पोस्ट नहीं)

हम किसी भी टैग का उपयोग करके इस प्रक्रिया को कर सकते हैं ... यह "सभी रिकॉर्ड्स" और "अभिलेखों के साथ` foo` टैग "के लिए काम करता है। यह बुरा नहीं लगता।

<!--

ColumnFamily: TaggedPosts

, BlogEntries



=>

: TimeUUIDType

: BlogEntries



: "foo"



,

__notag__, " ".

...

, "- + 1" .



TaggedPosts : { //

// "guitar"

guitar : {

timeuuid_1 : i-got-a-new-guitar,

timeuuid_2 : another-cool-guitar,

},

//

__notag__ : {

timeuuid_1b : i-got-a-new-guitar,



// , "guitar"

timeuuid_2b : another-cool-guitar,



// - "movie"

timeuuid_2b : scream-is-the-best-movie-ever,

},

// "movie"

movie: {

timeuuid_1c: scream-is-the-best-movie-ever

}

}

-->

< ColumnFamily CompareWith ="TimeUUIDType" Name ="TaggedPosts" />

कॉलम परिवार टिप्पणियाँ

आखिरी बात हमें यह पता लगाने की आवश्यकता है कि टिप्पणियों को कैसे मॉडल किया जाए। और फिर, अंत में, हमें सुपर कॉलम की आवश्यकता है।



हमारे पास प्रति पोस्ट 1 पंक्ति होगी। कुंजियों के रूप में, हम उन्हीं कुंजियों का उपयोग करेंगे जिनका उपयोग पदों के लिए किया गया था। लाइनों में हमारे पास सुपर कॉलम होंगे, प्रत्येक टिप्पणी के लिए यह स्वयं होगा। Supercolumn के नाम TimeUUIDType जैसे विशिष्ट पहचानकर्ता होंगे। इसलिए हम गारंटी देते हैं कि पोस्ट पर सभी टिप्पणियां कालानुक्रमिक क्रम में क्रमबद्ध हैं। प्रत्येक सुपर-कॉलम में कॉलम टिप्पणी पैरामीटर (टिप्पणीकर्ता का नाम, टिप्पणी समय आदि) होगा।



तो, यह बहुत सरल है अब तक ... कुछ भी अलौकिक नहीं है।

<!--

ColumnFamily: Comments





=> BlogEntries

: TimeUUIDType



:



Comments : {

// scream-is-the-best-movie-ever

scream-is-the-best-movie-ever : {

//

timeuuid_1 : { //

// -

commenter: Joe Blow,

email: joeb@example.com,

comment: you're a dumb douche, the godfather is the best movie ever

commentTime: 1250438004

},



... scream-is-the-best-movie-ever



// -

timeuuid_2 : {

commenter: Some Dude,

email: sd@example.com,

comment: be nice Joe Blow this isnt youtube

commentTime: 1250557004

},

},



// i-got-a-new-guitar

i-got-a-new-guitar : {

timeuuid_1 : {

commenter: Johnny Guitar,

email: guitardude@example.com,

comment: nice axe dawg...

commentTime: 1250438004

},

}



..

//

}

-->

< ColumnFamily CompareWith ="TimeUUIDType" ColumnType ="Super"

CompareSubcolumnsWith ="BytesType" Name ="Comments" />

यहाँ प्रारंभ करें

वह सब है। हमारा छोटा ब्लॉग एप्लिकेशन नकली है और उपयोग के लिए तैयार है। सबसे थोड़ा खोदें, और आप अपने स्टोरेज- conf.xml में XML के एक बहुत छोटे टुकड़े के साथ समाप्त होते हैं:

< Keyspace Name ="BloggyAppy" >

<!-- ... -->

<!-- CF definitions -->

< ColumnFamily CompareWith ="BytesType" Name ="Authors" />

< ColumnFamily CompareWith ="BytesType" Name ="BlogEntries" />

< ColumnFamily CompareWith ="TimeUUIDType" Name ="TaggedPosts" />

< ColumnFamily CompareWith ="TimeUUIDType" Name ="Comments"

CompareSubcolumnsWith ="BytesType" ColumnType ="Super" />

</ Keyspace >

अब आपको बस इतना पता लगाना है कि कैसेसंद्रा से डेटा लिखना और पढ़ना है। यह थ्रिफ्ट इंटरफेस का उपयोग करके किया जा सकता है। कैसंड्रा एपीआई विकी ने एक अच्छा काम किया है, जिसमें बताया गया है कि इसके साथ कैसे काम करना है, इसलिए मैं इन सभी विवरणों में नहीं जाता। लेकिन, सामान्य तौर पर, आप बस cassandra.thrift फ़ाइल संकलित कर सकते हैं और एपीआई तक पहुंचने के लिए उत्पन्न कोड का उपयोग कर सकते हैं। आप रूबी क्लाइंट या पायथन क्लाइंट का भी लाभ उठा सकते हैं।



ठीक है ... मुझे उम्मीद है कि यह सब आपको महसूस कराएगा कि यह सुपर कॉलम क्या है और आप कूल एप्लिकेशन बनाना शुरू करेंगे।



अनुवादक से: जितना संभव हो मूल के करीब अनुवाद करने की कोशिश की। मुझे रचनात्मक आलोचना की उम्मीद है।



अपडेट : फिक्स और लिंक के लिए धन्यवाद हनीमैन



08/24/2010: NoSQL ब्लॉग पर ले जाया गया