हमारे संबंधपरक DBMS में डेटा बड़ा हो रहा है, क्या यह NoSQL पर जाने का समय है?

Question

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

Comments

कुछ भी सामाजिक नेटवर्किंग के लिए, मैं Neo4j या OrientDB जैसे एक ग्राफ़ डेटाबेस की अत्यधिक अनुशंसा करूंगा

— अपोलो

Answer 1

कुछ गीगाबाइट बहुत " बड़े " नहीं हैं। यह एक उद्यम डीबी के सामान्य आकार की तरह अधिक है। जब तक आप टेबल से जुड़ते समय पीके के ऊपर जाते हैं, तब तक उसे वास्तव में अच्छी तरह से काम करना चाहिए, यहां तक ​​कि भविष्य में भी (जब तक कि आपको टीबी का एक दिन का डेटा नहीं मिलता)।

एक बड़े डेटा वातावरण में काम करने वाले अधिकांश पेशेवर बड़े डेटा की शुरुआत के रूप में > 5TB मानते हैं । लेकिन फिर भी यह हमेशा सबसे अच्छा तरीका नहीं है बस अगले सबसे अच्छे nosql डेटाबेस को स्थापित करें। आपको हमेशा उस कार्य के बारे में सोचना चाहिए जिसे आप डेटा के साथ संग्रह करना चाहते हैं (कुल मिलाकर, पढ़ें, खोज, मेरा, ..) आपको समस्या के लिए सबसे अच्छा उपकरण खोजने के लिए।

यदि आप अपने डेटाबेस में खोजों का एक बहुत कुछ करते हैं, तो बेहतर होगा कि किसी सोल उदाहरण / क्लस्टर को चलाएं और अपने डेटा को किसी DBMS जैसे Postgres या अपने SQL Server से समय-समय पर अलग-अलग करें और इसे डेटा को स्थानांतरित करने के बजाय केवल solr में डालें। दृढ़ता और प्रदर्शन की अवधि में sql से nosql तक।

Answer 2

इस सवाल का जवाब देने के लिए आपको जवाब देना होगा कि आप किस तरह का समझौता कर सकते हैं। RDBMs ACID को लागू करता है । संसाधनों के लिहाज से यह महंगा है। कोई NoSQL समाधान नहीं हैं जो ACID हैं। इन विचारों में गहराई से गोता लगाने के लिए CAP प्रमेय देखें ।

इसलिए आपको प्रत्येक समाधान के द्वारा दिए गए प्रत्येक समझौते को समझना होगा और उसे चुनना चाहिए जो आपकी समस्या के लिए सबसे उपयुक्त है।

Answer 3

बिग डेटा वास्तव में "कितना बड़ा है" के बारे में ऐसा नहीं है।

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

फिर आपको यह सोचना होगा कि आप अपने डेटा का उपयोग कैसे करते हैं।

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

यदि आपके एप्लिकेशन द्वारा आपके "फ़ंक्शननल" डेटा का भंडारण किया जाता है, तो मैं आपको SQL पर बने रहने का सुझाव दूंगा। यदि बाद में उन पर खोज करने या रिपोर्टिंग करने के लिए आपका डेटा संग्रहीत किया जाता है, और यदि डेटा की यह मात्रा तेज़ी से बढ़ सकती है, तो मैं बड़ा डेटा सुझाऊंगा। मेरी राय में, बड़ा डेटा तब उपयोगी होता है जब आप वास्तविक डेटा के साथ काम कर रहे होते हैं जिसे लगातार इकट्ठा और विश्लेषण करना पड़ता है।

Answer 4

जब मैंने रिलेशनल बनाम डॉक्यूमेंट (या NoSQL) डेटाबेस का उपयोग करना उचित है, तो मैंने स्टैकओवरफ़्लो पर एक बहुत विस्तृत उत्तर पोस्ट किया है:

संबंधपरक डेटाबेस / ओआरएम या दस्तावेज़ डेटाबेस / ODM का उपयोग करने के लिए प्रेरणा

सारांश:

• छोटे सामान के लिए, जो भी उपकरण आप परिचित हैं, उनके साथ जाएं

• कुछ गीगाबाइट निश्चित रूप से छोटा सामान है: यह तब तक बड़ा नहीं होता है जब तक कि यह एक एकल MySQL क्लस्टर में उचित संख्या में नोड्स (16-32) के साथ फिट होने के लिए बहुत बड़ा न हो , जिसका मतलब है कि शायद 8-16TB डेटा और कुछ मिलियन लेनदेन प्रति सेकंड (या 100 से अधिक टीबी डेटा और प्रति सेकंड कुछ हजार लेनदेन के साथ एक अधिक पारंपरिक हार्ड-ड्राइव-आधारित डेटाबेस)।

• यदि आप किसी अन्य डेटाबेस (MySQL क्लस्टर नहीं) के साथ फंस गए हैं, तो फ्यूजनियो हार्डवेयर में फेंकने से अधिक लाभ प्राप्त करें।

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

• कैसंड्रा :)

Answer 5

क्या NoSQL में जाने का समय 2 चीजों पर निर्भर करेगा:

1. आपके डेटा की प्रकृति / संरचना
2. आपका वर्तमान प्रदर्शन

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

डेटा-की-वैल्यू पेयर से परे अन-स्ट्रक्चर्ड होने पर NoSQL डेटाबेस एक्सेल हो जाता है।

प्रदर्शन के अनुसार, आप अपने आप से एक सवाल पूछेंगे: क्या आपका वर्तमान एसक्यूएल समाधान धीमा है ?

यदि नहीं, तो " IIABDFI " सिद्धांत के साथ जाएं।