संबंधपरक डेटाबेस का उपयोग न करने के अच्छे कारण?


139

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

जवाबों:


148

एक फाइलसिस्टम में सादा पाठ फ़ाइलें

  • बनाने और संपादित करने के लिए बहुत सरल है
  • उपयोगकर्ताओं के लिए सरल साधनों (यानी पाठ संपादकों, grep आदि) के साथ हेरफेर करना आसान है
  • बाइनरी दस्तावेजों का कुशल भंडारण

XML या डिस्क पर JSON फ़ाइलें

  • जैसा कि ऊपर, लेकिन संरचना को मान्य करने की थोड़ी अधिक क्षमता के साथ।

स्प्रेडशीट / सीएसवी फ़ाइल

  • व्यापार उपयोगकर्ताओं को समझने के लिए बहुत आसान मॉडल

तोड़फोड़ (या समान डिस्क आधारित संस्करण नियंत्रण प्रणाली)

  • डेटा के संस्करण के लिए बहुत अच्छा समर्थन

बर्कले डीबी (मूल रूप से, डिस्क आधारित हैशटेबल)

  • वैचारिक रूप से बहुत सरल (सिर्फ अन-टाइप की / वैल्यू)
  • जल्दी
  • कोई प्रशासन उपर नहीं
  • मेरा मानना ​​है कि लेनदेन का समर्थन करता है

अमेज़ॅन की साधारण डीबी

  • बहुत कुछ बर्कले डीबी जैसा मैं मानता हूं, लेकिन मेज़बान

Google का ऐप इंजन डेटास्टोर

  • होस्टेड और अत्यधिक स्केलेबल
  • प्रति दस्तावेज़ कुंजी-मूल्य संग्रहण (अर्थात लचीला डेटा मॉडल)

CouchDB

  • दस्तावेज़ फोकस
  • अर्द्ध संरचित / दस्तावेज़ आधारित डेटा का सरल भंडारण

मूल भाषा संग्रह (मेमोरी में संग्रहीत या डिस्क पर क्रमबद्ध)

  • बहुत तंग भाषा एकीकरण

कस्टम (हाथ से लिखा हुआ) स्टोरेज इंजन

  • आवश्यक उपयोग मामलों में संभावित रूप से बहुत उच्च प्रदर्शन

मैं उनके बारे में बहुत कुछ जानने का दावा नहीं कर सकता, लेकिन आप ऑब्जेक्ट डेटाबेस सिस्टम में देखना भी पसंद कर सकते हैं ।


10
यह बहुत अच्छा होगा यदि आपने प्रत्येक पसंद की कमियां भी बताई हैं, अन्यथा किसी को कैसे चुना जाना चाहिए? धन्यवाद,
स्किल्विज

4
एक DB में लाखों पंक्तियों को लिखने में एक दिन लग सकता है जबकि एक फ़ाइल में लॉग की एक लाख पंक्तियों को जोड़कर केवल मिनट लगते हैं। मैं यह कभी नहीं समझ पाऊंगा कि लोग लॉग डेटा को डेटाबेस में डालने पर जोर क्यों देते हैं।
आरोन दिगुल्ला

33
हारून: मेरे पास एक कारण है: संदेश लॉग इन करें का चयन करें (दिनांक BETWEEN 2009-01-01 और 2009-03-01) और टाइप करें = 'त्रुटि' और सिस्टम = 'विंडोज़' :) आप इसे एक पाठ फ़ाइल से कैसे लोड करेंगे ?
टॉम फेजर

1
जब भी संभव हो मैं पाठ फ़ाइलों के पक्ष में दृढ़ता से हूं। तुम हमेशा उन्हें इस्तेमाल नहीं कर सकते, लेकिन इतना आसान में समस्याओं का निदान करने आप वे कर रहे हैं कर सकते हैं जब।
लोरेन Pechtel

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

26

मैट शेपर्ड का जवाब बहुत अच्छा है (मॉड अप), लेकिन मैं एक स्पिंडल के बारे में सोचते समय इन कारकों को ध्यान में रखूंगा:

  1. संरचना: क्या यह स्पष्ट रूप से टुकड़ों में टूटता है, या आप ट्रेडऑफ़ बना रहे हैं?
  2. उपयोग: डेटा का विश्लेषण / पुनर्प्राप्त / grokked कैसे किया जाएगा?
  3. लाइफटाइम: डेटा कब तक उपयोगी है?
  4. आकार: कितना डेटा है?

RDBMSes पर CSV फ़ाइलों का एक विशेष लाभ यह है कि वे संक्षेप में और किसी अन्य मशीन को व्यावहारिक रूप से स्थानांतरित करने में आसान हो सकते हैं। हम बड़े डेटा ट्रांसफर करते हैं, और सब कुछ सरल है बस हम एक बड़ी CSV फ़ाइल का उपयोग करते हैं, और rsync जैसे टूल का उपयोग करके स्क्रिप्ट को आसान बनाते हैं। बड़ी CSV फ़ाइलों पर पुनरावृत्ति को कम करने के लिए, आप YAML जैसी किसी चीज़ का उपयोग कर सकते हैं । मुझे यकीन नहीं है कि मैं JSON या XML जैसे कुछ भी स्टोर करूंगा, जब तक कि आपके पास महत्वपूर्ण संबंध आवश्यकताएं नहीं थीं।

जहाँ तक नहीं बताया गया विकल्प, Hadoop को छूट न दें , जो कि MapReduce का एक खुला स्रोत कार्यान्वयन है। यदि आपके पास शिथिल संरचित डेटा का एक TON है, जिसका विश्लेषण करने की आवश्यकता है, तो यह अच्छी तरह से काम करना चाहिए, और आप एक ऐसे परिदृश्य में रहना चाहते हैं जहाँ आप डेटा प्रोसेसिंग को संभालने के लिए सिर्फ 10 और मशीनों को जोड़ सकते हैं।

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

नोट मैं "बड़े" आकारों के साथ सोचने के अधिक आदी हूँ।


5
CSV फ़ाइलों का एक खतरा यह है कि सही होने की जरूरत है; अपनी ': एक CSV पाठक या लेखक हैं जो वास्तव में कल्पना का पालन नहीं करता है, क्योंकि यह इतना भ्रामक सरल लग रहा है और वहाँ कुछ बारीकियों हैं लागू करना आसान en.wikipedia.org/wiki/Comma-separated_values#Specification
जारेड अपडाइक

10

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



6

यदि आपको ACID की आवश्यकता नहीं है , तो आपको शायद RDBMS के ओवरहेड की आवश्यकता नहीं है। इसलिए, यह निर्धारित करें कि आपको पहले क्या चाहिए। यहां उपलब्ध अधिकांश गैर-आरडीबीएमएस उत्तर एसीआईडी ​​प्रदान नहीं करते हैं।


1
क्या आप एक उदाहरण दे सकते हैं कि क्यों / जब ACID की आवश्यकता नहीं है?
इवान वोरोशिलिन

1
@vibneiro, यदि डेटाबेस में केवल एकल उपयोगकर्ता है जो केवल अनुक्रमिक संचालन करता है, या बिजली की विफलता के मामले में डेटाबेस विसंगतियों का जोखिम स्वीकार्य है, या डेटाबेस लेनदेन की अवधारणा लागू नहीं होती है, या बाधाओं की कोई आवश्यकता नहीं है, झरने, चलाता या, जैसे फिर एक गैर एसिड गैर आरडीबीएमएस प्रदाता (उदाहरण के लिए एक आरडीबीएमएस की तरह एपीआई के साथ एक पाठ फ़ाइल) ही पर्याप्त होता। उदाहरण के लिए, आपका एप्लिकेशन ऐतिहासिक नैदानिक ​​संदेशों का एक डेटाबेस रख सकता है जिसके लिए ACID पूरी तरह अप्रासंगिक है और "log.txt" पर्याप्त होगा।
bzlm

यह बताता है कि बहुत दुर्लभ मामलों में ACID की आवश्यकता नहीं है। मुझे आश्चर्य है कि तब NoSQL डेटाबेस इतने लोकप्रिय क्यों हैं? उनमें से अधिकांश पूर्ण ACIDity का समर्थन नहीं करते हैं।
इवान वोरोशिलिन

@vibneiro, NoSQL आमतौर पर आसान, अधिक हल्का, अधिक एम्बेड करने योग्य, अधिक आत्म-बंधक, अधिक सहज, अधिक लचीला और आमतौर पर कुछ ACID के साथ होता है । यदि आपके पास संबंधपरक डेटा नहीं है, तो RDBMS संभवतः वह नहीं है, जिसकी आपको आवश्यकता है।
बज़ल्म

6

कस्टम (हाथ से लिखा) भंडारण इंजन / संभावित उपयोग के मामलों में संभावित रूप से बहुत उच्च प्रदर्शन

http://www.hdfgroup.org/

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

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

HDF बहुआयामी सरणियों, रेखापुंज छवियों और तालिकाओं सहित कई अलग-अलग डेटा मॉडल का समर्थन करता है।

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

HDF5 एक ऐसा सूट है जो बेहद बड़े और जटिल डेटा संग्रह के प्रबंधन को संभव बनाता है।

नासा / जेपीएल रिमोट सेंसिंग डेटा की पेटाबाइट्स के बारे में सोचें।


4

अच्छा दिन,

एक मामला जो मैं सोच सकता हूं वह यह है कि जब आप जो डेटा मॉडलिंग कर रहे हैं वह आसानी से एक रिलेशनल डेटाबेस में प्रस्तुत नहीं किया जा सकता है।

एक बार ऐसा उदाहरण मोबाइल टेलीफोन ऑपरेटरों द्वारा मोबाइल टेलीफोन नेटवर्क के लिए बेस स्टेशनों की निगरानी और नियंत्रण के लिए उपयोग किया जाता है।

मैं इन सभी मामलों में, एक ओ.ओ. डी.बी. का उपयोग करता है, या तो एक वाणिज्यिक उत्पाद या एक स्वयं-लुढ़का हुआ सिस्टम जो वस्तुओं के उत्तराधिकार की अनुमति देता है।

मैंने एक बड़ी कंपनी के लिए 3 जी मॉनिटरिंग एप्लिकेशन पर काम किया है, जो नामहीन रहेगी, लेकिन जिसका लोगो रेड वाइन का दाग है (-:, और उन्होंने ऐसे OO DB का उपयोग व्यक्तिगत कोशिकाओं के लिए सभी विभिन्न विशेषताओं पर नज़र रखने के लिए किया है) नेटवर्क।

ऐसे DBs की पूछताछ स्वामित्व तकनीकों का उपयोग करके की जाती है जो आमतौर पर SQL से पूरी तरह से मुक्त होती हैं।

HTH।

चियर्स,

लूटना


4
ऐसा क्यों है कि बेसस्टेशन डेटा रिलेशनल मॉडल के लिए अच्छी तरह से उधार नहीं देता है?
20

3

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


3

कुछ मामलों में (उदाहरण के लिए वित्तीय बाजार डेटा और प्रक्रिया नियंत्रण) आपको RDBMS के बजाय वास्तविक समय डेटाबेस का उपयोग करने की आवश्यकता हो सकती है। विकी लिंक देखें


3

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

अन्य OODBMS उत्पादों में ऑब्जेक्टिविटी , जेमस्टोन शामिल है (आपको विजुअलवर्क्स प्राप्त करने की आवश्यकता होगी Smalltalk संस्करण चलाने के Smalltalk लेकिन एक जावा संस्करण भी है)। इस स्पेस में कुछ ओपन-सोर्स रिसर्च प्रोजेक्ट भी थे - EXODUS और इसके वंशज SHORE के दिमाग में आते हैं।

अफसोस की बात है कि यह अवधारणा मृत्यु को कम करती दिख रही थी, शायद SQL-आधारित RDMBS सिस्टम के सापेक्ष स्पष्ट रूप से दृश्यमान मानक और अपेक्षाकृत खराब तदर्थ क्वेरी क्षमता की कमी के कारण।

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


2
यह सही था कि आपको GemStone / S (डेस्कटॉप एप्स के लिए) का उपयोग करने के लिए क्लाइंट स्मॉलटाक की जरूरत थी, लेकिन वेब फ्रेमवर्क Aida ( helpaweb.si ) के साथ, और Seaside ( seaside.st ) GemStone / S का उपयोग सीधे एप्लिकेशन के रूप में किया जा सकता है। सर्वर। GLASS ( seaside.gemstone.com ) पर जानकारी देखें
डेल हेनरिक्स

एक और कारण होगा यदि आप डेटा गुणवत्ता के बारे में परवाह करते हैं। रत्न की तरह एक OODB में जटिल वैधता नियमों को लागू करना बहुत आसान है।
स्टीफन एगरमॉन्ट

OODBMS की तदर्थ क्वेरी क्षमता SQL आधारित RDBMS-es की तुलना में बहुत बेहतर है
Stephan Eggermont

1

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

RDBMS में बहुत अच्छी तरह से फिट नहीं होने वाली अन्य चीजें पदानुक्रमित डेटा संरचनाएं हैं और मैं अनुमान लगा रहा हूं कि भू-स्थानिक डेटा और 3D मॉडल या तो आसान नहीं हैं।

अमेज़ॅन एस 3 जैसी सेवाएं सरल भंडारण मॉडल (कुंजी> मूल्य) प्रदान करती हैं जो एसक्यूएल का समर्थन नहीं करती हैं। स्केलेबिलिटी वहां की कुंजी है।

एक्सेल फाइलें उपयोगी भी हो सकती हैं, खासकर अगर उपयोगकर्ताओं को किसी परिचित वातावरण में डेटा को हेरफेर करने में सक्षम होना चाहिए और ऐसा करने के लिए एक पूर्ण एप्लिकेशन का निर्माण करना संभव नहीं है।


1

डेटा को संग्रहीत करने के लिए बड़ी संख्या में तरीके हैं - यहां तक ​​कि "रिलेशनल डेटाबसे" में कोड की एक साधारण लाइब्रेरी से कई विकल्पों को शामिल किया गया है जो एक स्थानीय फ़ाइल (या फ़ाइलों) को हेरफेर करता है जैसे कि यह एकल उपयोगकर्ता आधार पर एक रिलेशनल डेटाबेस था, के माध्यम से फ़ाइल आधारित सिस्टम, गंभीर "सर्वर" आधारित प्रणालियों के एक उदार चयन के लिए कई-उपयोगकर्ताओं को संभाल सकता है।

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

हमारे लिए यह है कि इसके बारे में - हम या तो कुछ का उपयोग करने जा रहे हैं जो एसक्यूएल करेगा (एमएस एक उपकरण का एक सेट प्रदान करता है जो एक .DLL से एंटरप्राइज़ सर्वर के माध्यम से सभी उपयोगकर्ता सामान करने के लिए चलता है और वे सभी एक ही एसक्यूएल बोलते हैं (निचले छोर पर सीमाओं के साथ)) या हम XML को एक प्रारूप के रूप में उपयोग करने जा रहे हैं क्योंकि (हमारे लिए) वर्बोसिटी शायद ही कभी एक मुद्दा है।

हमें वर्तमान में अपने ऐप्स में बाइनरी डेटा में हेरफेर करने की आवश्यकता नहीं है, ताकि सवाल न उठे।

Murph


1

एक पारंपरिक SQL डेटाबेस के स्थान पर LDAP सर्वर के उपयोग पर विचार करना चाह सकता है यदि अनुप्रयोग डेटा प्रकृति में भारी / मूल्य उन्मुख और पदानुक्रमित है।


1

बीट्री फाइलें अक्सर रिलेशनल डेटाबेस की तुलना में बहुत तेज होती हैं। SQLite में यह एक बीट्री लाइब्रेरी है जो सार्वजनिक डोमेन में है (जैसा कि 'सार्वजनिक डोमेन' में है, शिथिल शब्द का उपयोग नहीं करते हुए)।

सच कहूँ, अगर मैं एक बहु-उपयोगकर्ता प्रणाली चाहता था, तो मुझे एक सभ्य सर्वर रिलेशनल डेटाबेस का उपयोग न करने के लिए बहुत समझाने की आवश्यकता होगी।


बीट्रीस सामान्य सूचकांक का मूल कार्यान्वयन है। ओरेकल इंडेक्स-ऑर्गेनाइज़्ड टेबल का समर्थन करता है जो इंडेक्स के रूप में लागू की जाने वाली टेबल है। वे पढ़ने में तेज हैं, लिखने में धीमा हैं और बी-ट्री का उपयोग करते हैं। देखें: < oracle.com/technology/products/oracle9i/datasheets/iots/… >
borjab

1

पूर्ण-पाठ डेटाबेस, जिसे निकटता ऑपरेटरों से "जैसे 10 शब्दों के भीतर," आदि के साथ उद्धृत किया जा सकता है।

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

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


1

इसके अलावा: * एंबेडेड परिदृश्य - जहां आमतौर पर कुछ छोटे का उपयोग करना आवश्यक होता है तो एक पूर्ण विकसित RDBMS। Db4o एक ODB है जिसे इस तरह के मामले में आसानी से इस्तेमाल किया जा सकता है। * रैपिड या प्रूफ-ऑफ-कॉन्सेप्ट डेवलपमेंट - जहां आप व्यवसाय पर ध्यान केंद्रित करना चाहते हैं और दृढ़ता परत के बारे में चिंता नहीं करते हैं


1

सीएपी प्रमेय इसे स्पष्ट रूप से समझाता है। SQL मुख्य रूप से "स्ट्रांग कंसिस्टेंसी" प्रदान करता है: सभी क्लाइंट्स समान दृश्य देखते हैं, यहां तक ​​कि अपडेट की उपस्थिति में भी "।


1

KISS: रखें यह लघु और सरल


1
वह विनम्र संस्करण है ... मैंने अक्सर सुना है "इसे सरल, मूर्ख रखें" ... या, गपशप, शायद यही वह है जो लोग मुझे बताते हैं! :-(
ग्रीनमैट

1

मैं RDBMS की पेशकश करूंगा :) अगर आपको सेटलाइट के लिए परेशानी नहीं है / SQLite के लिए प्रशासन जाना है। पूर्ण SQL समर्थन के साथ RDBMS में निर्मित। यहां तक ​​कि यह आपको किसी भी कॉलम में किसी भी प्रकार के डेटा को स्टोर करने की अनुमति देता है।

उदाहरण लॉग फ़ाइल के खिलाफ मुख्य लाभ: यदि आपके पास बहुत बड़ा है, तो आप इसमें कैसे खोज करेंगे? SQL इंजन के साथ आप बस सूचकांक बनाते हैं और नाटकीय रूप से ऑपरेशन को गति देते हैं।

पूर्ण पाठ खोज के बारे में: SQLite पूर्ण पाठ खोज के लिए भी मॉड्यूल है ..

बस अपने डेटा के लिए अच्छे मानक इंटरफ़ेस का आनंद लें :)


0

संबंधपरक डेटाबेस का उपयोग नहीं करने का एक अच्छा कारण यह होगा कि जब आपके पास एक विशाल डेटा सेट हो और डेटा पर बड़े पैमाने पर समानांतर और वितरित प्रसंस्करण करना चाहते हों। Google वेब इंडेक्स ऐसे मामले का एक आदर्श उदाहरण होगा।

Hadoop में Google फ़ाइल सिस्टम का भी कार्यान्वयन है, जिसे Hadoop Distributed File System कहा जाता है ।


0

मैं जोर से लूका को SQLite- तरह के डेटा भंडारण के विकल्प के रूप में सुझाएगा।

इसलिये:

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

यह स्वीकृत उत्तर का "मूल भाषा संग्रह" विकल्प है। यदि आप एप्लिकेशन स्तर के रूप में C / C ++ का उपयोग कर रहे हैं, तो लुआ इंजन (बाइनरी के 100kB) को केवल कॉन्फ़िगर / डेटा पढ़ने या उन्हें लिखने के लिए फेंकना पूरी तरह से उचित है।


लुआ एक प्रोग्रामिंग भाषा है। इस सुझाव को किसी भी प्रोग्रामिंग भाषा के किसी भी दृढ़ता / क्रमबद्धता के सुझाव के लिए सामान्यीकृत किया जा सकता है (उदाहरण के लिए पायथन / शेल्व में, या पर्ल एट अल के लिए JSON / YAML, और इसी तरह)। यह समवर्ती पहुँच को संबोधित नहीं करता है और ACID गारंटी देता है।
जिम डेनिस

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