2010-03-01 11 views
8

बड़े पैमाने पर डेटासेट (Google, facebook, linkedin) में उपयोग किए जाने पर गैर-रिलेशनल डेटाबेस (जैसे कुंजी-मूल्य जोड़ी संग्रहण) के लाभ स्पष्ट हैं। आपको कैसे लगता है कि छोटे से मध्यम आकार के अनुप्रयोग गैर-संबंधपरक डेटाबेस का उपयोग करने से लाभ उठा सकते हैं?छोटे से मध्यम आकार के अनुप्रयोगों के लिए गैर-संबंधपरक डेटाबेस (नोएसक्यूएल)

+2

समुदाय विकी .... – jldupont

+1

मैं इसके साथ कोई वास्तविक अनुभव नहीं मानता हूं, लेकिन मैं उस लिंक का समर्थन करने वाले कुछ लिंक देखना चाहता हूं या कम से कम यह बता रहा हूं कि विकल्प क्या हैं। मैं यह भी मानता हूं कि यह शायद समुदाय विकी होना चाहिए। –

+0

क्या आप "गैर-रिलेशनल" को "रिलेशनल नहीं" के अलावा कुछ और परिभाषित करेंगे? अन्यथा डेटा संग्रहित करने के लिए कोई भी विज्ञापन योजना योग्य है। –

उत्तर

6

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

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

Google स्केल करने के लिए स्केलेबल स्टोरेज और मैपराइडस प्रदान करता है। यह संबंध नहीं है।

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

गैर-संबंधपरक के लिए व्यावहारिक धक्का अधिकांश प्रदर्शन और पैमाने की ओर मुझे लगता है। मैं नहीं देखता कि यह कैसे "छोटे" अनुप्रयोगों में मदद करता है।

लोगों ने ज्ञान-आधारित योजनाओं का उपयोग करके बहुत व्यावहारिक डेटा प्रबंधन का प्रस्ताव दिया है, लेकिन नहीं किया है। डौग लेनैट का CYC यहां दिमाग में आता है। किसी एप्लिकेशन को गैर-स्पष्ट निष्कर्ष निकालने में सहायता के लिए डेटाबेस की क्षमता मुझे "छोटे" अनुप्रयोगों के लिए बहुत ही रोचक बनाता है जो "स्मार्ट" होने का प्रयास कर रहे हैं। लेकिन अभी तक इनमें से बहुत कुछ नहीं हैं।

+0

+1 - एक विचारशील योगदान – APC

+0

सभी को धन्यवाद, बहुत उपयोगी – Victor

2

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

स्पेक्ट्रम के छोटे छोर पर, प्रदर्शन एक गैर मुद्दा है क्योंकि बस सब कुछ तेज़ है। स्टोरेज इंजन एक गैर-मुद्दा हैं, यदि आपको परिष्कृत क्वेरी इंजन की आवश्यकता नहीं है, तो SQL समर्थन की कमी एक गैर समस्या है।

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

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

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

1

जब ग्राफ डेटाबेस (जैसे Neo4j - एक परियोजना जिसमें मैं शामिल हूं) की बात आती है तो वे scaling to complexity पर उत्कृष्टता प्राप्त करते हैं।इसका मतलब है, वे "better substrates for modeling business domains" प्रदान करते हैं (The State of NoSQL देखें, Ben Scofield भी)। जैसा कि मैंने इसे देखा, यह छोटे से मध्यम आकार के ऐप्स में बहुत महत्वपूर्ण है।

यह बेहतर हो सकता है उदाहरण के माध्यम से बताया गया है, इसलिए यहाँ उदाहरण क्षुधा के लिए कुछ लिंक है/डोमेन मॉडलिंग:

0

सवाल शायद थोड़ा की आवश्यकता है अधिक संदर्भ ... एक पायथन पर्यावरण मानते हुए, y_serial प्रोजेक्ट पर ट्यूटोरियल पर विचार करें: http://yserial.sourceforge.net/

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

0

अच्छी तरह से आरडीबीएमएस के साथ समस्याओं में से एक यह है कि आपको अपने आरडीबीएमएस की रिलेशनल स्कीमा में अपनी प्रोग्रामिंग भाषा डोमेन मॉडल मैप करने का प्रयास करना होगा। यह प्रयास आमतौर पर आपकी ओआरएम परत को कॉन्फ़िगर करने में व्यतीत होता है।

नोएसक्यूएल डेटाबेस के साथ आपको अपनी ऑब्जेक्ट्स को एक रिलेशनल मॉडल पर मैप करने के लिए मजबूर नहीं किया जाता है और ज्यादातर मामलों में आपकी ऑब्जेक्ट्स को क्रमबद्ध किया जाता है। मध्यस्थ स्कीमा की कमी के कारण, data migrations and versioning become easier

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

यदि आप यह देखने में रुचि रखते हैं कि आरडीबीएमएस से कोई नोएसक्यूएल अलग-अलग कैसे विकसित होता है, तो मेरे पास एक ट्यूटोरियल है जहां मैं दिखाता हूं कि designing a simple blog application using Redis कैसे जाना है।

0

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

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

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

यदि कोई आरडीबीएमएस की आवश्यकता नहीं है तो नोएसक्यूएल समाधान और संबंधित क्लाउड सेवाओं का उपयोग करके इसका एक टन समाप्त हो सकता है।

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

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

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

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

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

0

अमेज़ॅन सरल डीबी उन लोगों के लिए उपयोगी हो सकता है जिन्हें छोटे, गैर-संरचनात्मक डेटा के भंडारण के लिए गैर-संबंधपरक डेटाबेस की आवश्यकता होती है। अमेज़ॅन SimpleDB ने स्टोरेज आकार को प्रति डोमेन 10GB तक सीमित कर दिया है। अमेज़ॅन SimpleDB सादगी और लचीलापन प्रदान करता है। SimpleDB स्वचालित रूप से सभी डेटा अनुक्रमणित करता है। अमेज़ॅन SimpleDB मूल्य निर्धारण आपके वास्तविक बॉक्स उपयोग पर आधारित है। आप अमेज़ॅन SimpleDB में किसी भी यूटीएफ -8 स्ट्रिंग डेटा को स्टोर कर सकते हैं।

संबंधित मुद्दे