NoSQL: असंरचित डेटा क्या है?


9

वर्तमान में हम अपने mssql सर्वर आधारित समाधान के साथ संसाधनों के किनारे पर चल रहे हैं।

लोड से निपटने के लिए अगले कदम के बारे में अब हमारे पास कई पारंपरिक विकल्प हैं:

  • तेजी से सीपीयू और आईओ खरीदें
  • सर्वर को अलग करने के लिए कुछ ग्राहकों को विभाजित करें
  • क्लस्टर के लिए db ले जाएँ

सभी या तो लाइसेंस और हार्डवेयर या समय के मामले में महंगे हैं। इसलिए, मैं पूरे सिस्टम को एक स्केलेबल समाधान में स्थानांतरित करके एक और विकल्प जोड़ना चाहता हूं जो nosql इंजन कैसेंड्रा वादा करता है।

फिर भी, मुझे यकीन नहीं है और noSQL डेटाबेस के साथ अनुभव नहीं किया गया है, इसलिए मुझे "असंरचित" डेटा की संरचना को समझने की आवश्यकता है।

हमारे आवेदन में, हम मूल रूप से "कुंजी-मूल्य" सूची के रूप में उपयोगकर्ताओं द्वारा दर्ज किए गए डेटा को संग्रहीत करते हैं। एक पेरेंट टेबल होती है, जिसमें हेड एलिमेंट होता है (ऑर्डर की तरह) और इसमें एक चाइल्ड टेबल होती है जिसमें की-वैल्यू पेयर होते हैं, जिसमें ऑर्डर के कंटेंट होते हैं (जैसे कि ऑर्डर_Lines)।

व्यापार-वार, ऑर्डर और ऑर्डरलाइन एक इकाई हैं। लेकिन RDBMS के कारण, उन्हें तालिकाओं में संग्रहीत किया जाता है और उन्हें हर समय शामिल होना चाहिए।

संचालन के दौरान, हम कभी-कभी केवल शीर्ष भाग को लोड करने के लिए चुनते हैं, लेकिन अधिकांश समय, हम कुछ उपयोगी जानकारी प्रदर्शित करने के लिए शीर्ष पंक्ति + कुछ KVP लोड करते हैं।

उदाहरण के लिए, एक अवलोकन सूची में, हम प्रत्येक पंक्ति के लिए कॉलम में हेड आइडेंटिफ़ायर + कुछ मान दिखाते हैं।

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

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

क्या इस तरह के "डिक्शनरी" जैसे डेटासेट को नो एसक्यूएल डेटाबेस में बेहतर संग्रहित किया जा सकता है? और क्या इससे हमें प्रदर्शन लाभ होगा? क्या कैसेंड्रा इन सिर + केवीपी को एक डेटासेट के रूप में मॉडल करेगा? कैसंड्रा वेबपेज और कुछ ट्यूटोरियल्स को देखते हुए, मुझे यह आभास होता है, कि डेटा संगठन के मामले में हमारे RDBMS और कैसेंड्रा के बीच इतना अंतर नहीं है - यदि आप अपने KVP को चुनना चाहते हैं, तो हमें उतनी ही बड़ी राशि के साथ छोड़ना होगा। प्रत्येक पंक्ति के लिए एक सूची के लिए।

प्रबोधन का स्वागत है, कागजों की ओर इशारा करते हुए यह भी बताया कि मुद्दे ठीक हैं।

जवाबों:


3

ऐसी कुछ अवधारणाएँ हैं जिन्हें प्रतिष्ठित करने की आवश्यकता है। एक संरचना के बारे में है और दूसरा स्कीमा के बारे में है।

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

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

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


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

ऐतिहासिक रूप से यह सभी ग्राहक पक्ष थे - आपको अपने दस्तावेज़ वापस मिल गए और आपने वही किया जो आपके पास था। CQL का क्लॉज़ है कि कोई भी SQL डेवलपर से परिचित होगा। मैप रिड्यूस बड़े डेटासेट के लिए गो-टू आर्किटेक्चर है। और ऐसा लग रहा है कि कैसंड्रा 3.0 में मैटेरियलाइज्ड व्यू होंगे
माइकल ग्रीन

5

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

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

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

आमतौर पर की-वैल्यू लिस्ट एक ट्रेड-ऑफ के रूप में ठीक होती है, जब आप मॉडल को उसकी अंतिम स्थिति में लागू नहीं कर सकते क्योंकि आपको पता नहीं होता है कि आपको किन-किन चाबियों का सामना करना पड़ेगा, या जब आपको किसी एक के मूल्यों की आवश्यकता होगी एक निश्चित तत्व के लिए कुंजी। लेकिन जब लागू किया जाता है, तो मैं आमतौर पर इस तरह के फैसलों को थोड़ी देर के बाद फिर से सोचना पसंद करता हूं जब आपने उपयोग के सामान्य मामले की पहचान करने के लिए पर्याप्त मात्रा में जानकारी एकत्र की है और यह तय किया है कि क्या डेटा मॉडल का निर्णय सबसे अच्छा है। यदि आप जानते हैं कि आपके पास कुछ निश्चित कुंजियाँ होंगी, तो पारंपरिक तरीके से एक नियमित टेबल के डिज़ाइन के साथ कुछ बेंचमार्क करने की कोशिश करें

CREATE TABLE benchmarkTable (
  element INTEGER,
  key1 VARCHAR(xx),
  key2 INTEGER,
  key3 DECIMAL(5,2),
...
);

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

आशा है कि यह मदद करता है, या कम से कम संभावनाओं को व्यापक करता है और जांच के लिए एक नई रेखा खोलता है।


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

समझ लिया। मुझे नहीं पता कि यह कितना चुनौतीपूर्ण है, लेकिन कोशिश करने के लिए एक विचार के रूप में, क्या यह एक प्रदर्शन FK, शायद एक INTEGER द्वारा उपयोगकर्ता से भरी तालिका में संदर्भित सामान्य कुंजियों के पूल वाली तालिका बनाने के लिए काम करेगा? हो सकता है कि यह एक varchar कॉलम को इंडेक्स करने की तुलना में थोड़ा बेहतर है, अगर यह बहुत गतिशील रूप से बदल रहा है तो मुझे लगता है कि यह छोटा नहीं होगा। और यह सूचकांक के आकार को कम करेगा।
LironCareto

1
यह सवाल से दूर जाता है, लेकिन हमने उपयोगकर्ता संभावनाओं पर कुछ सीमाओं पर चर्चा की है। उदाहरण के लिए अधिकतम ऐप-टेबल फ़ील्ड को 10 वेनिला varchar db-फ़ील्ड के लिए कम करें। यह मूल रूप से मुख्य डेटासेट और 10 ऐप-कॉलम मानों को एक बार में चुनने या अधिकतम एक अतिरिक्त db-table पर जुड़ने के लिए स्कीमा का एक अपभ्रंश है। प्रासंगिक मूल्यों को बदलने पर, हमें इस एक db-row को कोड में भी संशोधित करना होगा। यह संभव लगता है और ऐप-टेबल प्रदर्शित करने के लिए एक चयन के लिए जुड़ने की मात्रा को 10 तक कम कर देता है। फिर भी, उपयोगकर्ता की ऐप-कॉलम परिभाषा बदलना बहुत महंगा है।
thst

1
यह ठीक है, चिंता न करें। मुझे लगता है कि मैं आपकी बात देख रहा हूं, और आपका दृष्टिकोण मेरे लिए प्रदर्शन सुधार और व्यवहार्यता के बीच एक अच्छा व्यापार के रूप में दिखता है। उन क्षेत्रों को निर्धारित करने के लिए, स्पष्ट रूप से उपयोग के आंकड़े होना महत्वपूर्ण है। क्या आपने इसे बेंचमार्क किया है? कम से कम यह आपको कुछ समय खरीद सकता है जब तक कि आप एक (बेहतर? निश्चित) समाधान नहीं पाते हैं या शायद यह पता चलता है कि आप लंबे समय तक इसके साथ चल सकते हैं।
LironCareto
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.