2012-01-11 12 views
8

मैं बस बेहतर समझना चाहता हूं, जो मैंने वर्षों से सीखा है, एक दस्तावेज आधारित समाधान धीमा है और मुझे बहुत से I/O की आवश्यकता है। एक पीएचपी प्रोजेक्ट में उदाहरण के लिए, आमतौर पर यह कहा जाता है कि रेडिस, मेमेकैच, या एपीसी जैसे मेमोरी कैश का उपयोग करना बहुत बेहतर है क्योंकि वे डेटा को वास्तविक फ़ाइल में कैशिंग करने के बजाय मेमोरी आधारित हैं।दस्तावेज़ आधारित डीबी इतनी तेजी से कैसा है?

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

उत्तर

4

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

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

http://en.wikipedia.org/wiki/Document-oriented_database

आह और क्यों वे redis तुलना में तेजी से हो सकता है:
मान लीजिए कि आप (यानी हर डाटासेट एक ही लग रहा है एक सेट में कुछ गैर रेखीय जानकारी स्टोर करने की जरूरत है और आपके पास अलग डेटाटाइप्स मिला एक सेट में। रेडिस पर आप केवल कुंजी-मूल्य जोड़ों को स्टोर कर सकते हैं ताकि आपको उन्हें अपने कोड/कार्यान्वयन में सेट पर एक साथ जोड़ना होगा। नोएसक्यूएल डाटाबेस पर यह आपके लिए डेटाबेस (संभवतः) में संभाला जाता है। अधिक अनुकूलित तरीका :)

+0

रेडिस केवल कुंजी/मूल्य जोड़े को स्टोर नहीं करता है, यह अधिक डेटा प्रकारों को स्टोर कर सकता है (देखें: http://redis.io/topics/data-types) – Carpetsmoker

0

पहली बात यह है कि - आप नोएसQL डीबी को इन-मेमोरी डीबी से तुलना नहीं कर सकते । नोएसQL डीबी डेटा के लिए मानसिक हैं जो स्मृति में फिट नहीं होंगे।

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

+4

'नोएसक्यूएल डीबी डेटा के लिए महत्वपूर्ण हैं जो नहीं स्मृति में फिट '। यह सादा गलत है। आप ऐसा क्यों कह रहे हैं? – jgauffin

+0

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

+1

'अधिकांश समय' अभी भी गलत है। वे आरडीबीएमएस के लिए बस एक विकल्प हैं, लेकिन स्कीमलेस और कुल जड़ों के लिए बेहतर समाधान के साथ। – jgauffin

2

NoSQL बात करते हैं, गलतफहमी होने का खतरा हो सकता है के रूप में अवधारणाओं में से कुछ के नाम, कि पारंपरिक एक के लिए एक अलग अर्थ है का उपयोग करेगा:

  • फ़ाइल आधारित है (जरूरी) इसका मतलब यह नहीं है कि डेटास्टोर प्रत्येक रिकॉर्ड को एक फाइल में लिख देगा - इसका मतलब यह है कि डेटास्टोर में रिकॉर्ड फ़ील्ड की पूर्वनिर्धारित स्कीमा के अनुरूप नहीं होंगे यदि एक निश्चित डेटा प्रकार। एक्सएमएल, जेएसओएन या दोस्तों जैसे कुछ के रूप में "फाइल" के बारे में सोचें।
  • (अधिकतर) नोएसक्यूएल डेटास्टोर की प्रदर्शन जीत कीमत पर आती है: आम तौर पर अच्छी तरह से समझा जाने वाला एसीआईडी ​​वादे एक लूसर स्थिरता मॉडल के खिलाफ कारोबार किया जाता है।
  • एसक्यूएल डेटाबेस को रिलेशनल करने की शक्ति इस तथ्य से एक बड़े हिस्से में आती है, जितनी अच्छी है कि प्रत्येक प्रश्न मौजूदा स्कीमा के खिलाफ लिखा जा सकता है। यह NoSQL डेटास्टोर के साथ हमेशा सत्य नहीं है: रिकॉर्ड के लिए सबसे चरम संस्करण तक पहुंच केवल रिकॉर्ड-आईडी के माध्यम से संभव है।
  • अधिकांश NoSQL डेटा संग्रहों एक ठेठ रिलेशनल डेटाबेस की तुलना में बेहतर स्केल करेगा - वे सवाल स्केलिंग सीमा "
0

काबू पाने के लिए" क्या हम एक अच्छी तरह से समझ में आ संबंधपरक DB से त्याग करने की क्या ज़रूरत है "का जवाब कर रहे हैं एक विचार प्राप्त करने के लिए, इस पर विचार करें:

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

हालांकि एक mongo क्वेरी एक mysql क्वेरी से धीमी हो सकती है, 1 mongo क्वेरी की तुलना 100 mysql क्वेरीज़ से अधिक तेज़ी से होने जा रही है।

0

जादू घटक जरूरी नहीं कि एक "तेजी" डेटाबेस, यह एक डेटाबेस है जो डिजाइन और "तेज" प्रणाली के कार्यान्वयन के लिए सक्षम बनाता है। यही कारण है कि NoSQL डेटाबेस को गेम परिवर्तक माना जाता है।

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

इसके अलावा, अधिकांश नोएसक्यूएल डेटाबेस की एक आम विशेषता यह है कि वे सरल हैं क्योंकि वे SQL डेटाबेस के "सामान्य मामले" दृष्टिकोण से अधिक विशिष्ट हैं। इसका मतलब है कि कम तर्क/कोड जिसे प्रत्येक ऑपरेशन, सरल डेटा संरचनाओं (जिसे कम आईओ की आवश्यकता हो सकती है) और सामान्य रूप से कम ओवरहेड, बेहतर प्रदर्शन पर चलने की आवश्यकता होती है।

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