एक कैसंद्रा डेटा मॉडल डिजाइन करने में सबसे अच्छा अभ्यास क्या है?

Question

और इससे बचने के लिए क्या नुकसान हैं? क्या आपके लिए कोई सौदा टूट गया है? उदाहरण के लिए, मैंने सुना है कि कैसंद्रा डेटा का निर्यात/आयात करना बहुत मुश्किल है, जिससे मुझे आश्चर्य हो रहा है कि क्या विकास के विकास के लिए उत्पादन डेटा को सिंक करना बाधित हो रहा है।

बीटीडब्ल्यू, कैसंद्रा पर अच्छे ट्यूटोरियल ढूंढना बहुत मुश्किल है, केवल http://arin.me/code/wtf-is-a-supercolumn-cassandra-data-model है जो अभी भी बहुत ही बुनियादी है।

धन्यवाद।

Answer 1

मेरे लिए, मुख्य बात यह है कि ऑर्डर्ड पार्टिशनर या रैंडमपार्टिशनर का उपयोग करना है या नहीं।

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

तो अगर आपको बहुत मंथन मिल गया है, तो जब तक कि आप यादृच्छिक विभाजनकर्ता का उपयोग करके सामानों को सम्मिलित करने के लिए कुछ जादूगर तरीका नहीं रखते हैं, तो आप आसानी से "खो" सामान कर सकते हैं, जिससे डिस्क स्थान होता है रिसाव और आखिरकार सभी भंडारण का उपभोग करेगा।

दूसरी ओर, आप आदेशित विभाजनकर्ता से पूछ सकते हैं "ए और बी के बीच कॉलम परिवार एक्स में मेरे पास कौन सी कुंजी है"? - और यह आपको बताएगा। फिर आप उन्हें साफ कर सकते हैं।

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

मेरे पास इसके लिए कोई आसान जवाब नहीं है, सिवाय इसके कि आप कुछ मामलों में एक छोटे हैश मूल्य (कुछ अन्य डेटा स्रोतों से आसानी से गणना कर सकते हैं) डालकर "दोनों दुनिया के सर्वश्रेष्ठ" प्राप्त कर सकते हैं। आपकी चाबियाँ - उदाहरण के लिए उपयोगकर्ता आईडी का 16-बिट हेक्स हैश - जो आपको 4 हेक्स अंक देगा, जिसके बाद आप वास्तव में उपयोग करना चाहते हैं।

फिर यदि आपके पास हाल ही में हटाए गए उपयोगकर्ताओं की एक सूची है, तो आप उनके संबंधित कुछ भी साफ़ करने के लिए बस अपने आईडी और रेंज स्कैन कर सकते हैं।

अगला मुश्किल बिट द्वितीयक अनुक्रमणिका है - कैसंड्रा में कोई नहीं है - इसलिए यदि आपको वाई द्वारा एक्स को देखने की आवश्यकता है, तो आपको दोनों चाबियों के नीचे डेटा डालने की आवश्यकता है, या एक पॉइंटर है। इसी प्रकार, इन पॉइंटर्स को साफ करने की आवश्यकता हो सकती है जब वे जो चीज इंगित करते हैं वह मौजूद नहीं है, लेकिन इस आधार पर सामान पूछने का कोई आसान तरीका नहीं है, इसलिए आपके ऐप को बस याद रखना होगा।

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

इनमें से कोई भी असली उपयोग पर आधारित नहीं है, जो मैंने शोध के दौरान किया है। हम उत्पादन में कैसंद्रा का उपयोग नहीं करते हैं।

संपादित करें: कैसंड्रा में अब ट्रंक में द्वितीयक अनुक्रमणिका हैं।

Answer 2

एक और ट्यूटोरियल यहां है: http://blog.evanweaver.com/articles/2009/07/06/up-and-running-with-cassandra/।

Answer 3

क्या आपके लिए कोई सौदा ब्रेक है? ज़रूरी नहीं कि सौदा तोड़ने लेकिन कुछ

1. एक ग्राहक एक निकटतम नोड, जो संबोधित यह पहले से पता होना चाहिए को जोड़ता है के बारे में पता होना करने के लिए, अन्य सभी कैसेंड्रा के साथ सभी संचार के माध्यम से यह प्रॉक्सी नोड्स। ए। पढ़ने/लिखने यातायात को नोड्स के बीच समान रूप से वितरित नहीं किया जाता है - कुछ नोड्स स्वयं को होस्ट करने से अधिक डेटा प्रॉक्सी करते हैं बी। क्या नोड नीचे जाना चाहिए, ग्राहक असहाय है, पढ़ नहीं सकता है, क्लस्टर में कहीं भी नहीं लिख सकता है।

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

3. वहाँ बहु मिलता है, लेकिन कोई बहु हटा सकते हैं और एक काट-छांट नहीं कर सकते हैं ColumnFamily है या तो

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

Answer 4

यह भी एक टिप्पणी के रूप में जोड़ने के लिए लंबे समय से था, इसलिए कुछ गलतफहमी स्पष्ट करने के लिए सूची के- समस्याओं उत्तर:

1. किसी भी ग्राहक किसी भी नोड से कनेक्ट कर सकते हैं; यदि आपके द्वारा उठाए गए पहले नोड (या आप लोड बैलेंसर के माध्यम से कनेक्ट होते हैं) नीचे जाते हैं, तो बस दूसरे से कनेक्ट करें। इसके अतिरिक्त, एक "वसा ग्राहक" एपीआई उपलब्ध है जहां ग्राहक स्वयं लिखने को निर्देशित कर सकता है; एक उदाहरण http://wiki.apache.org/cassandra/ClientExamples

2. अनिश्चित काल तक लटकाए जाने के बजाए कोई सर्वर उत्तरदायी नहीं होने पर समय-समय पर एक सुविधा है जो अधिकतर लोगों ने अधिभारित rdbms सिस्टम के साथ काम किया है। कैसंद्रा आरपीसी टाइमआउट कॉन्फ़िगर करने योग्य है; यदि आप चाहें, तो आप इसे कई दिनों तक सेट करने के लिए स्वतंत्र हैं और इसके बजाय अनिश्चित काल तक लटकने के साथ सौदा कर सकते हैं। :)

3. यह सच है कि अभी तक कोई बहुआयामी या छंटनी समर्थन नहीं है, लेकिन इन दोनों के लिए समीक्षा में पैच हैं।

4. स्पष्ट रूप से क्लस्टर नोड्स में संतुलित भार रखने में एक व्यापारिक रूप है: जितना अधिक संतुलित आप चीजों को रखने की कोशिश करते हैं, उतना अधिक डेटा आंदोलन जो आप करेंगे, जो मुफ़्त नहीं है। डिफ़ॉल्ट रूप से, एक कैसंड्रा क्लस्टर में नए नोड्स असमान-नस्ल को कम करने के लिए टोकन रिंग में इष्टतम स्थिति में स्थानांतरित हो जाएंगे। व्यावहारिक रूप से, यह अच्छी तरह से काम करने के लिए दिखाया गया है, और आपका समूह बड़ा है, कम सच यह है कि दोगुना इष्टतम है। यह मैं इस एक अद्यतन हकदार के बाद से कैसेंड्रा 1.2 हाल ही में बाहर आया लगता है http://wiki.apache.org/cassandra/Operations

Answer 5

में अधिक कवर किया जाता है।

मैं सामाजिक खेलों के लिए पिछले 18 महीनों के लिए उत्पादन में कैसंद्रा का उपयोग कर रहा हूं।

मेरा हालांकि यह है कि आपको अपनी शक्तियों के लिए कैसंद्रा का उपयोग करना होगा।तो यह समझना आवश्यक है कि कौन सा डेटा मॉडल उपयोग करना है या यह भी पहचानना आवश्यक है कि कोई अन्य डीबी समाधान आपके लिए अधिक उपयोगी है या नहीं। स्वत: sharding और लोड संतुलन:

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

RandomPartioner (md5 हैशिंग) और MurmurPartitioner (बड़बड़ाहट हैशिंग, बेहतर और तेज) रास्ता तय करना होगा कि आप बड़ा डेटा और एक उच्च पहुँच फ्रीक्वेंसियों को सपोर्ट करना चाहते हैं कर रहे हैं। एकमात्र चीज जिसे आप छोड़ देते हैं वह मुख्य श्रेणी प्रश्न है। सब कुछ जो एक ही पंक्ति में है, अभी भी क्लस्टर में एक ही नोड पर है और आप उन पर तुलनित्र और कॉलम नाम श्रेणी क्वेरी का उपयोग कर सकते हैं। टीएल; डीआर: प्रोपर बैलेंसिंग के लिए इसका उपयोग करें, आप कुछ भी प्रमुख नहीं छोड़ देंगे।

---

चीजें आप कैसेंड्रा के बारे में पता होना चाहिए:

कैसेंड्रा अंततः लगातार है। कैसंद्रा ने उच्च उपलब्धता और उत्कृष्ट विभाजन (http://en.wikipedia.org/wiki/CAP_theorem) के लिए संगठनात्मक व्यापार का चयन किया है। लेकिन आप कैसंद्रा से स्थिरता प्राप्त कर सकते हैं, जब आप इसे पढ़ते और लिखते हैं तो यह आपके बारे में संगठनात्मक नीति है। कैसंद्रा का उपयोग करने के बारे में बात करते समय यह एक महत्वपूर्ण और जटिल विषय है लेकिन आप इसके बारे में विस्तार से यहां http://www.datastax.com/docs/1.2/dml/data_consistency पढ़ सकते हैं।

अंगूठे के नियम के रूप में (और इसे सरल रखने के लिए) मैं QUORUM ConsistencyLevel पर पढ़ता हूं और लिखता हूं (क्योंकि मेरे ऐप्स में पढ़ने के रूप में आवृत्ति के समान क्रम के होते हैं)। यदि आपका ऐप भारी रूप से भारी लिखता है और पढ़ता है तो बहुत कम होता है तो एक पर लिखें और सभी को पढ़ें। या यदि आपका उपयोग केस विपरीत है (लिखने से बहुत कम बार लिखते हैं) तो आप एक पर पढ़ने की कोशिश कर सकते हैं और सभी पर लिख सकते हैं। लिखने के लिए एक स्थिरता स्तर के रूप में किसी का उपयोग करना एक अच्छा विचार नहीं है यदि आप स्थिरता को हल करने की कोशिश कर रहे हैं, क्योंकि यह गारंटी देता है कि उत्परिवर्तन क्लस्टर तक पहुंच गया है लेकिन यह नहीं कि यह कहीं भी लिखा गया है। यह एकमात्र मामला है जिसमें मैंने कैसंद्रा पर चुपचाप असफल होने के लिए लिखा है।

कैसंद्रा विकास के साथ शुरू करना आसान बनाने के लिए ये सरल नियम हैं। उत्पादन क्लस्टर से यथासंभव अधिक स्थिरता और प्रदर्शन प्राप्त करने के लिए आपको इस विषय का अध्ययन करना चाहिए और वास्तव में इसे स्वयं समझना चाहिए।

यदि आपको संस्थाओं (तालिकाओं) के बीच जटिल संबंधों के साथ मानव पठनीय डेटामैडल की आवश्यकता है तो मुझे नहीं लगता कि कैसंद्रा आपके लिए है। MySQL और शायद NewSQL आपके उपयोग के मामले के लिए और अधिक उपयोगी हो सकता है।

यह जानने के लिए एक अच्छी बात यह है कि, लगभग, कैसंड्रा डेटा बचाता है और पढ़ता है। जब भी आप लिखते हैं (हटाते हैं वास्तव में कैसंड्रा में "टॉम्बस्टोन" मान के लिखते हैं) सिस्टम नए मूल्य और उसके समय के नए भौतिक स्थान में टिकट लगाएगा।

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

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

---

यह मुझे अंतिम बिंदु पर लाता है जो मैं बनाना चाहता हूं: सुनिश्चित करें कि आपके लिखने और पढ़ने को आपके समूह में संतुलित किया जाएगा!

मान लीजिए कि आपके सभी उपयोगकर्ताओं को अक्सर एक ही स्थान को अपडेट करने की आवश्यकता है।
सैद्धांतिक एकल स्थान केवल एक पंक्ति कुंजी के लिए मानचित्र न करें! यह आपके सभी लेखन आपके क्लस्टर में केवल एक नोड पर गिर जाएगा। यदि यह सबकुछ नीचे नहीं लाता है (क्योंकि आपके पास रॉकस्टार सिसोप्स हैं) तो यह कम से कम क्लस्टर के प्रदर्शन को अपंग करेगा।
मेरी सलाह है कि आप अपने लेखन को पर्याप्त अलग-अलग पंक्ति कुंजी में बाल्टी करें ताकि आप क्लस्टर में सभी नोड्स में अपने लेखन वितरित कर सकें। उस एकल सैद्धांतिक स्थान के लिए सभी डेटा पुनर्प्राप्त करने के लिए सभी "उप पंक्ति कुंजी" पर एक बहु_get का उपयोग करें।

उदाहरण:
मैं सभी सक्रिय http सत्र (जो उन्हें सौंपे गए UUID) की एक सूची है करना चाहते हैं। सभी को "सत्र" पंक्ति कुंजी में सेव न करें। 6 नोड्स के मेरे कैसंड्रा क्लस्टर के लिए मैं पंक्ति कुंजी के रूप में उपयोग करता हूं: _ सत्र। फिर मेरे पास सभी सक्रिय सत्रों को पुनर्प्राप्त करने के लिए एक छोटी 16 कुंजी mult_get है, या मैं अभी भी बता सकता हूं कि एक साधारण प्राप्त करने के जरिए कोई सत्र सक्रिय है (यदि मैं निश्चित रूप से इसके बारे में जानता हूं)। यदि आपका क्लस्टर बहुत बड़ा है तो आप पीढ़ी की बाल्टी कुंजी के लिए हैश फ़ंक्शन का उपयोग करना चाहेंगे।