जब Cassandra का उपयोग करने के लिए नहीं?


200

हाल ही में कैसंड्रा से संबंधित बहुत सी बातें हुई हैं ।

Twitter, Digg, Facebook, आदि सभी इसका उपयोग करते हैं।

यह कब समझ में आता है:

  • Cassandra का उपयोग करें,
  • कैसेंड्रा का उपयोग न करें, और
  • Cassandra के बजाय RDMS का उपयोग करें।

7
शायद सीडब्ल्यू होना चाहिए? यह बहुत ज्यादा NoSQL बनाम रिलेशनल डेटाबेस है, जो बहुत व्यक्तिपरक IMO है।
एड जेम्स

3
मैं जानना चाहूंगा कि क्या मैसेजिंग सिस्टम के लिए उपयुक्त है। मुझे लगता है कि यदि ट्विटर इसका उपयोग करता है तो यह ठीक होगा, हालांकि वे शायद ट्विटर के सभी के लिए इसका उपयोग नहीं करते हैं?
ल्यूक

जवाबों:


165

चांदी की गोली जैसा कुछ भी नहीं है, सब कुछ विशिष्ट समस्याओं को हल करने के लिए बनाया गया है और इसके अपने पेशेवरों और विपक्ष हैं। यह आपके ऊपर है कि आपके पास क्या समस्या है और उस समस्या का सबसे अच्छा समाधान क्या है।

मैं आपके प्रश्नों के उत्तर एक-एक करके उसी क्रम में देने का प्रयास करूंगा, जैसा आपने उनसे पूछा था। चूंकि कैसंड्रा डेटाबेस के NoSQL परिवार पर आधारित है, इसलिए यह महत्वपूर्ण है कि आप समझें कि आपके सवालों का जवाब देने से पहले NoSQL डेटाबेस का उपयोग क्यों करें।

NoSQL का उपयोग क्यों करें

RDBMS के मामले में, एक विकल्प बनाना काफी आसान है क्योंकि इस श्रेणी में MySQL, Oracle, MS SQL, PostgreSQL जैसे सभी डेटाबेस ACID गुणों की ओर उन्मुख लगभग एक ही तरह के समाधान प्रदान करते हैं। जब यह NoSQL की बात आती है, तो निर्णय मुश्किल हो जाता है क्योंकि प्रत्येक NoSQL डेटाबेस अलग-अलग समाधान प्रदान करता है और आपको यह समझना होगा कि कौन सा आपके ऐप / सिस्टम की आवश्यकताओं के लिए सबसे उपयुक्त है। उदाहरण के लिए, MongoDB उन मामलों के उपयोग के लिए फिट है जहां आपका सिस्टम स्कीमा-कम दस्तावेज़ स्टोर की मांग करता है। HBase खोज इंजनों के लिए फिट हो सकता है, लॉग डेटा का विश्लेषण कर सकता है, या किसी भी स्थान पर जहां स्कैनिंग के लिए विशाल, दो-आयामी जुड़ाव-कम तालिकाओं की आवश्यकता होती है। रेडिस को पेड़ों, कतारों, लिंक्ड सूचियों, आदि जैसे डेटा संरचनाओं की किस्मों के लिए इन-मेमोरी खोज प्रदान करने के लिए बनाया गया है और यह वास्तविक समय लीडरबोर्ड, पब-उप-प्रकार की प्रणाली बनाने के लिए एक अच्छा फिट हो सकता है। इसी तरह इस श्रेणी में अन्य डेटाबेस हैं (कैसेंड्रा सहित) जो विभिन्न समस्या बयानों के लिए फिट हैं। अब मूल प्रश्नों पर चलते हैं, और एक-एक करके उनका उत्तर देते हैं।

कैसेंड्रा का उपयोग कब करें

NoSQL परिवार का एक हिस्सा होने के नाते, कैसेंड्रा उन समस्याओं के लिए एक समाधान प्रदान करता है जहां आपकी आवश्यकताओं में से एक बहुत भारी लेखन प्रणाली है और आप उस संग्रहीत डेटा के शीर्ष पर एक काफी संवेदनशील रिपोर्टिंग प्रणाली चाहते हैं। वेब एनालिटिक्स के उपयोग के मामले पर विचार करें जहां लॉग डेटा प्रत्येक अनुरोध के लिए संग्रहीत किया जाता है और आप वास्तविक समय के तरीके से आईपी, आदि द्वारा प्रति घंटे हिट, गिनती के लिए एक विश्लेषणात्मक प्लेटफॉर्म का निर्माण करना चाहते हैं। आप इस ब्लॉग पोस्ट का उपयोग उन मामलों को समझने के लिए कर सकते हैं, जिनमें कैसंड्रा फिट बैठता है।

जब Cassandra के बजाय RDMS का उपयोग करें

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

जब कैसेंड्रा का उपयोग नहीं करना है

मुझे नहीं लगता कि इसका उत्तर देने की आवश्यकता है यदि उपरोक्त स्पष्टीकरण समझ में आता है।


1
उत्तर के साथ समस्या यह है कि यह सभी NoSQL समाधानों को एक साथ जोड़ देता है। अधिक जानकारी के लिए dataconomy.com/sql-vs-nosql-need-know देखें । NoSQL परिदृश्य में मूल विभाजन दस्तावेज़, कुंजी-मूल्य, ग्राफ़ और बड़ी-तालिका हैं। अलग-अलग समस्याओं के लिए उनके पास अलग-अलग विशेषताएं हैं। एक समाधान जो मोंगो के लिए एक अच्छा मैच है, कैसेंड्रा के लिए एक अच्छा मैच नहीं हो सकता है।
येहोसफ

17
एकमात्र तरीका यह प्रतिक्रिया "सभी NoSQL समाधानों को एक साथ समेटता है" श्रेणी NoSQL द्वारा है; इसके अलावा यह पोस्ट यह इंगित करने का एक बड़ा काम करता है कि प्रत्येक NoSQL डेटाबेस विभिन्न समस्याओं के लिए "एक अलग समाधान प्रदान करता है"। मुझे यह महसूस नहीं हुआ कि लेखक ने उस मोंगो, कैसेंड्रा, या किसी अन्य NoSQL डेटाबेस को थोड़ा-सा संकेत भी दिया है।
निक सुवाइन

NoSQL databaseबात नहीं है। NoSQLकेवल आधुनिक गैर-संबंधपरक डेटाबेस के लिए उपयोग किया जाने वाला शब्द है ( विकी देखें )।
eddyP23

2
इसके अलावा, ध्यान दें कि सभी NoSQL डेटाबेस ACID नहीं हैं। ग्राफ DBs आमतौर पर ACID होते हैं।
eddyP23

कैसेंड्रा लाइट वेट ट्रांजैक्शंस का उपयोग करके पंक्ति स्तर के परमाणु संचालन और परमाणु और अलगाव के विभाजन का समर्थन करता है। अगर मेरी आवश्यकता पंक्ति स्तर पर ACID की है तो क्या मैं Cassandra का उपयोग नहीं कर सकता हूं? महत्वपूर्ण डेटा के लिए भी?
टेक एंथीरिस

52

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

कैसेंड्रा एक उपलब्ध, विभाजन-सहिष्णु प्रणाली है जो अंतिम स्थिरता का समर्थन करती है। अधिक जानकारी के लिए इस ब्लॉग पोस्ट को देखें: मैंने लिखा है: NoSQL Systems के लिए विजुअल गाइड


आपने पिछली बार ऐसा विभाजन कब देखा था जहाँ दोनों विभाजन बड़े थे? मेरे सवाल देखें stackoverflow.com/questions/7969874/...
हारून Watters

5
कैसंड्रा स्पष्ट रूप से आपको क्वेरी समय पर अपनी निरंतरता की आवश्यकता को निर्दिष्ट करने की अनुमति देता है, जो कुछ उपयोग मामलों के लिए एक उपयोगी समझौता हो सकता है
रिचर्ड मार

30

कैसंड्रा एक विशेष समस्या का उत्तर है: जब आपके पास इतना डेटा होता है कि आप एक सर्वर पर फिट नहीं होते हैं तो आप क्या करते हैं? आप अपने सभी डेटा को कई सर्वरों पर कैसे संग्रहीत करते हैं और अपने बैंक खाते को नहीं तोड़ते हैं और अपने डेवलपर्स को पागल नहीं बनाते हैं? फेसबुक को नए कंप्रेस्ड डेटा EVERY DAY के 4 टेराबाइट मिलते हैं। और यह संख्या सबसे अधिक संभावना एक वर्ष के भीतर दो बार से अधिक बढ़ जाएगी।

यदि आपके पास इतना डेटा नहीं है या आपके पास एंटरप्राइज ओरेकल / डीबी 2 क्लस्टर इंस्टॉलेशन के लिए भुगतान करने के लिए लाखों हैं और इसे स्थापित करने और इसे बनाए रखने के लिए आवश्यक विशेषज्ञ हैं, तो आप SQL डेटाबेस के साथ ठीक हैं।

हालाँकि फेसबुक अब कैसेंड्रा का उपयोग नहीं करता है और अब तेजी से प्रदर्शन और बेहतर नियंत्रण के लिए आवेदन स्टैक में विभाजन को स्थानांतरित करने के लिए लगभग MySQL का उपयोग करता है।


27

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

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


3
स्कीमा को बदलने की संभावना नहीं है, यह एक टेबल संरचना में अच्छी तरह से फिट बैठता है, और खोए हुए / असंगत डेटा वास्तविक समस्याएं पैदा कर सकता है।
टॉम क्लार्कसन

4
मुझे समझ नहीं आ रहा है कि असंगत डेटा बैंकों के साथ वास्तविक समस्या क्यों पैदा कर सकता है। परिदृश्य: आपके पास एक बैंक खाता है, उस पर सीमा से ऊपर $ 100 और दो बैंक कार्ड हैं। जब आप दो अलग-अलग एटीएम में एक ही समय में दो कार्ड के साथ पैसे निकालने की कोशिश करते हैं, तो आपको 2 गुना $ 100 मिलेगा, और आपके मेल बॉक्स में अतिरिक्त शुल्क के साथ एक पत्र। असंगत डेटा का उपयोग करके बैंक पैसे कमाता है (सीमा से कम होने का अतिरिक्त शुल्क)। दुनिया के सभी एटीएम को एक बड़े रिलेशनल डेटाबेस के माध्यम से एक-दूसरे से जोड़ना मुश्किल है। क्या आप एक उदाहरण दे सकते हैं जहां असंगत वित्तीय डेटा एक समस्या हो सकती है?
पचो

5
वह सामान सभी COBOL और बैच प्रसंस्करण है, और लगभग नहीं जैसा कि डिजाइन / स्थिर है जैसा कि आप सोच सकते हैं। एटीएम किसी भी प्रकार के एकीकृत डेटा स्टोर से कनेक्ट नहीं होते हैं, इसलिए शायद ही एक उपयुक्त उदाहरण है। यह कहना है कि SQL वेब ऐप्स के लिए उपयुक्त नहीं है क्योंकि आप इंटरनेट पर हर किसी को अपने डेटाबेस तक सीधी पहुँच नहीं दे सकते। इसके अलावा, मैंने बैंकों के बारे में कभी कुछ नहीं कहा - एक ईकॉमर्स साइट पर ऑर्डर जैसी चीजों के बारे में सोचें, जहां आपको किसी संगठन के साथ रूढ़िवादी व्यवहार नहीं करना है, जिसे एसक्यूएल नया और अविश्वसनीय माना जाता है।
टॉम क्लार्कसन

6
@Paco: पहला एटीएम आपका बैलेंस ($ 100) पढ़ता है, और दूसरा एटीएम भी ऐसा ही करता है। दोनों एटीएम $ 100 से $ 100 घटाते हैं और $ 0 का अंतिम शेष राशि आपके खाते में लिखते हैं। परिणाम: बैंक $ 100 खो देता है।
सीन ओसेवा

9
@ डाक: बिंदु, उचित लेन-देन अलगाव के बिना, सामान्य बैंक को यह भी पता नहीं होगा कि खाता ओवरड्राॅन हो गया है। उन्हें पता भी नहीं चलेगा।
सीन ओसेवा

14

कैसंड्रा का उपयोग कब करें और कब न करें, इसके बारे में ऊपर दिए गए उत्तरों के अलावा, यदि आप कैसंड्रा का उपयोग करने का निर्णय लेते हैं, तो आप कैसंड्रा का उपयोग न करने पर विचार करना चाह सकते हैं, लेकिन इसके कई चचेरे भाई में से एक।

ऊपर दिए गए कुछ उत्तर पहले से ही विभिन्न "NoSQL" प्रणालियों की ओर इशारा करते हैं जो कैसेंड्रा के साथ कई गुणों को साझा करते हैं, कुछ छोटे या बड़े अंतर के साथ, और आपकी विशिष्ट जरूरतों के लिए कैसेंड्रा से बेहतर हो सकता है।

इसके अतिरिक्त, हाल ही में (इस सवाल के मूल रूप से पूछे जाने के कई साल बाद), एक कैसंड्रा क्लोन जिसे स्लैला कहा जाता है (देखें https://en.wikipedia.org/wiki/Scylla_(database) ) को जारी किया गया था। स्काइला, C ++ में कैसेंड्रा का एक ओपन-सोर्स री-इम्प्लीमेंटेशन है, जो मूल जावा कैसेंड्रा की तुलना में काफी अधिक थ्रूपुट और लोअर लेटेंसी का दावा करता है, जबकि इसके साथ ज्यादातर संगत है (फीचर्स, एपीआई और फाइल फॉर्मेट में)। इसलिए यदि आप पहले से ही कैसंड्रा पर विचार कर रहे हैं, तो आप स्काइला पर भी विचार कर सकते हैं।


9

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


4

आपको अपने स्वयं से निम्नलिखित प्रश्न पूछने चाहिए:

  1. (आयतन, वेग) क्या आप सूचनाओं के TONS लिख रहे हैं और पढ़ रहे हैं, इतनी जानकारी कि कोई भी कंप्यूटर लिख नहीं सकता।
  2. (ग्लोबल) क्या आपको दुनिया भर में इस लेखन और पढ़ने की क्षमता की आवश्यकता होगी ताकि दुनिया के एक हिस्से में लेखन दुनिया के दूसरे हिस्से में सुलभ हो?
  3. (विश्वसनीयता) क्या आपको इस डेटाबेस की आवश्यकता है कि आप हर समय उठते रहें और कभी भी इस बात की परवाह न करें कि यह कौन सा क्लाउड है, किस देश का है, चाहे वह वीएम, कंटेनर हो, या न तो धातु है?
  4. (स्केल-क्षमता) क्या आपको इस डेटाबेस की आवश्यकता है जो आसानी से बढ़ने और रेखीय रूप से बढ़ने में सक्षम हो
  5. (संगति) क्या आपको TUNABLE संगति की आवश्यकता है जहाँ कुछ लिखते हैं अतुल्यकालिक रूप से जहाँ अन्य को प्रमाणित करने की आवश्यकता होती है?
  6. (कौशल) क्या आप वह करने के लिए तैयार हैं जो इस तकनीक को सीखने में लगता है और डेटा मॉडलिंग जो एक विश्व स्तर पर वितरित डेटाबेस बनाने के साथ जाता है जो हर किसी के लिए, हर जगह तेजी से हो सकता है?

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

RDBMS का उपयोग करें जब आप एक बॉक्स पर सब कुछ कर सकते हैं। यह शायद सबसे आसान है और कोई भी इसके साथ काम कर सकता है।


3

यहाँ अन्य उत्तरों के अलावा भारी सिंगल क्वेरी बनाम गज़िलियन लाइट क्वेरी लोड पर विचार करने के लिए एक और बिंदु है। NoSql-स्टाइल DB में किसी एकल क्वेरी को स्वचालित रूप से अनुकूलित करना स्वाभाविक रूप से कठिन है। मैंने MongoDB का उपयोग किया है और एक जटिल क्वेरी की गणना करने की कोशिश करते समय प्रदर्शन के मुद्दों में भाग गया है। मैंने कैसेंड्रा का उपयोग नहीं किया है, लेकिन मुझे उम्मीद है कि यह एक ही मुद्दा होगा।

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

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

MongoDB के साथ मेरे अनुभव में, क्वेरी की जटिलता के कारण अंत में बहुत अधिक Mongo इसे अनुकूलित करने और कई डेटा पर इसके कुछ हिस्सों को चलाने के लिए नहीं कर सका। मोंगो कई प्रश्नों को समानांतर करता है लेकिन किसी एक को अनुकूलित करने में इतना अच्छा नहीं है।


3

आइए पढ़ते हैं कुछ वास्तविक दुनिया के मामले:

http://planetcassandra.org/apache-cassandra-use-cases/

इस लेख में: http://planetcassandra.org/blog/post/agentis-energy-stores-over-15-billion-records-of-time-series-usage-data-in-apache-cassandra

उन्होंने इस कारण का विस्तार किया कि उन्होंने MySql को क्यों नहीं चुना क्योंकि db सिंक्रोनाइज़ेशन बहुत धीमा है।

(2-वाक्यांश प्रतिबद्ध, एफके, पीके के कारण)


कैसांद्रा अमेज़ॅन डायनामो पेपर पर आधारित है

विशेषताएं:

स्थिरता

उच्च उपलब्धता

बैकअप अच्छा प्रदर्शन करता है

पढ़ें और लिखें HBase से बेहतर है, (जावा में BigTable क्लोन)।

wiki http://en.wikipedia.org/wiki/Apache_Cassandra

उनका निष्कर्ष है:

We looked at HBase, Dynamo, Mongo and Cassandra. 

Cassandra was simply the best storage solution for the majority of our data.

2018 के अनुसार,

यदि आपको बैक सपोर्ट की जरूरत है, तो मैं क्लासिक कैसेंड्रा को बदलने के लिए स्काइबीडीबी का उपयोग करने की सलाह दूंगा।

Postgres kv plugin भी cassandra की तुलना में जल्दी है। कभी भी बहु-आवृत्ति मापनीयता नहीं होगी।


आपको केवल एक डेटाबेस तकनीक के साथ समझौता नहीं करना है। आपके पास वास्तव में कॉम्बो हो सकता है और विशिष्ट मुद्दे के लिए जो भी उपयुक्त हो, का उपयोग करें।
फर्नांडीज

3

मैं यहां कुछ महत्वपूर्ण पहलुओं पर ध्यान केंद्रित करूंगा जो आपको यह तय करने में मदद कर सकते हैं कि क्या आपको वास्तव में कैसंड्रा की जरूरत है। सूची संपूर्ण नहीं है, बस कुछ बिंदु जो मेरे दिमाग में सबसे ऊपर हैं-

  • जब आप रिश्ते (अपने डाटासेट के पार) पर एक सख्त आवश्यकता होने पर कैसंड्रा को पहली पसंद नहीं मानते हैं।

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

  • यदि आपका पैमाना अधिक नहीं है या यदि आप एक गैर-वितरित डीबी के साथ सौदा कर सकते हैं तो कैसंड्रा का उपयोग न करें।

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

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

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

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


2

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


CouchdB, एक के लिए, कुल कार्यों को आसानी से गणना करने की अनुमति देता है: wiki.apache.org/couchdb/… । तकनीकी रूप से, यह "कोड में" है, लेकिन इसे पूरा करने के लिए "जटिल" के रूप में लगभग नहीं है क्योंकि यह कैसंड्रा के साथ होगा।
user359996

2
वास्तव में मैं सहमत हूं कि कोड में कुल लिखने के लिए आपको एक दिन लग सकता है, लेकिन आप इसे बैकएंड सर्वर पर चलाने के लिए लिख सकते हैं जो डेटाबेस के 0 चक्र के करीब का उपयोग करेगा। SQL डेटाबेस के साथ, आपको एक पंक्ति लिखने का परिणाम मिलेगा, जिसमें आपको 5 मिनट लग सकते हैं। लेकिन जब भी आप इसे चलाएंगे यह पूरे डेटाबेस को धीमा कर देगा। तो वहाँ दोनों तरीकों से पेशेवरों और विपक्ष हैं। मेरा बैंक, उदाहरण के लिए, लगभग 10 से 15 मिनट के लिए रात के बीच में सभी वेबसाइट एक्सेस को बंद कर देता है। वे सबसे निश्चित रूप से COBOL का उपयोग कर रहे हैं, लेकिन यह एक बहुत ही समान समस्या है।
एलेक्सिस विलके

1

यदि आपको SQL शब्दार्थ के साथ पूरी तरह से सुसंगत डेटाबेस की आवश्यकता है, तो Cassandra आपके लिए समाधान नहीं है। कैसेंड्रा कुंजी-मूल्य लुकअप का समर्थन करता है। यह SQL प्रश्नों का समर्थन नहीं करता है। कैसेंड्रा में डेटा "अंततः सुसंगत" है। डेटा के समवर्ती लुकअप असंगत हो सकते हैं, लेकिन अंततः लुकअप संगत हैं।

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


1
कैसेंड्रा क्वेरी लैंग्वेज (CQL) है बहुत समान एसक्यूएल, हालांकि। वास्तव में, मैं कहूंगा कि CQL कैसेंड्रा का एक फायदा है, जो एसक्यूएल जैसे इंटरफ़ेस की तलाश में अन्य NoSQL विकल्पों पर है।
अरूसेल ar४

1
कैसंड्रा तकनीकी रूप से अंततः सुसंगत नहीं है। कैसंड्रा आपको उपलब्धता के लिए स्थिरता से व्यापार करने देता है। कैसंड्रा मूल रूप से कैप प्रमेय को संतुलित कर रहा है। आप अंततः लगातार लिख सकते हैं, और फिर लगातार पढ़ सकते हैं, इसके विपरीत, या दोनों पर लगातार, और यह सब आपके प्रतिकृति कारक पर निर्भर करता है जो आपके पढ़ने / लिखने के स्तर के साथ संयुक्त है। मुझे लगता है कि इस कारण के लिए संभावित रूप से उद्धरण में "अंततः सुसंगत" जवाब मिला, लेकिन मुझे लगता है कि कुछ स्पष्टता क्रम में है।
tsturzl

1

कैसांद्रा एक अच्छा विकल्प है अगर:

  1. आपको अपने DB से ACID गुणों की आवश्यकता नहीं है।

  2. डीबी पर बड़े पैमाने पर और भारी संख्या में लेखन होगा।

  3. बिग डेटा, हडोप, हाइव और स्पार्क के साथ एकीकृत करने की आवश्यकता है।

  4. रियल टाइम डेटा एनालिटिक्स और रिपोर्ट जनरेशन की जरूरत है।

  5. प्रभावशाली दोष सहिष्णु तंत्र की आवश्यकता है।

  6. समरूप प्रणाली की आवश्यकता है।

  7. ट्यूनिंग के लिए बहुत सारे अनुकूलन की आवश्यकता है।


0

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

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


0

डेटास्टैक्स के अनुसार, जब ज़रूरत होती है तो कैसंड्रा सबसे अच्छा उपयोग मामला नहीं है

1- हाई एंड हार्डवेयर डिवाइस। 2- बिना रोल बैक (बैंक ट्रांजैक्शन) के साथ ACID अनुपालन


0
  • यह तालिकाओं में संपूर्ण लेनदेन प्रबंधन का समर्थन नहीं करता है।
  • द्वितीयक सूचकांक समर्थित नहीं है।
  • माध्यमिक सूचकांक के लिए लोचदार खोज / Solr पर भरोसा करना होगा और कस्टम सिंक घटक को लिखना होगा।
  • एसीआईडी ​​कंप्लेंट सिस्टम नहीं।
  • क्वेरी समर्थन सीमित है।

0

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

पुरालेख विशुद्ध रूप से कैप प्रमेय पर आधारित है, जो कि उपलब्धता, और विभाजन सहिष्णुता और लगातार दिलचस्प है।

इसका उपयोग न करें, यदि आपके डेटा के वॉल्यूम को क्लस्टर के रैक पर संग्रहीत नहीं किया जाता है, तो यदि आप समय श्रृंखला डेटा को संग्रहीत नहीं कर रहे हैं, तो उपयोग न करें यदि आप अपने सर्वर को पेटेंट नहीं करा रहे हैं, तो यदि आपको मजबूत संगतता की आवश्यकता नहीं है, तो इसका उपयोग न करें।


मजबूत संगतता गैन्टिस, एक सर्वर हमेशा एक लेखन लेता है और हर रीड सबसे हाल ही में प्रदान करता है।
रेमरियो
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.