मैं यहाँ केवल MongoDB के लिए उत्तर दे सकता हूँ, मैं यह दिखावा नहीं करूँगा कि मैं HDFS और ऐसी अन्य तकनीकों के बारे में बहुत कुछ जानता हूँ।
GridFs का कार्यान्वयन पूरी तरह से ड्राइवर के भीतर ही क्लाइंट साइड है। इसका मतलब है कि MongoDB के भीतर ही फ़ाइल सेवा के संदर्भ की कोई विशेष लोडिंग या समझ नहीं है, प्रभावी रूप से MongoDB स्वयं यह भी नहीं समझता है कि वे फ़ाइलें हैं ( http://docs.mongodb.org/manual/applications/gridfs/ )।
इसका मतलब है कि files . के किसी भी हिस्से के लिए क्वेरी करना या chunks संग्रह उसी प्रक्रिया में परिणत होगा जैसा कि यह किसी अन्य क्वेरी के लिए होता है, जिससे यह आपके काम करने वाले सेट ( http://en.wikipedia.org/wiki/Working_set ) में आवश्यक डेटा लोड करता है जो डेटा के एक सेट का प्रतिनिधित्व करता है (या सभी लोडेड डेटा) इष्टतम प्रदर्शन को बनाए रखने के लिए एक निश्चित समय सीमा के भीतर MongoDB द्वारा आवश्यक है। यह इसे RAM में पेज करके करता है (तकनीकी रूप से OS करता है)।
विचार करने के लिए एक और बिंदु यह है कि यह ड्राइवर लागू किया गया है। इसका मतलब है कि विनिर्देश भिन्न हो सकते हैं, हालांकि, मुझे नहीं लगता कि यह करता है। सभी ड्राइवर आपको files . से दस्तावेज़ों के एक सेट के लिए क्वेरी करने की अनुमति देंगे संग्रह जिसमें केवल फ़ाइलें मेटा डेटा होती हैं, जो आपको बाद में chunks . से फ़ाइल की सेवा करने की अनुमति देती हैं एक ही प्रश्न के साथ संग्रह।
हालाँकि यह महत्वपूर्ण बात नहीं है, आप फ़ाइल को स्वयं सेवा देना चाहते हैं, जिसमें उसका डेटा भी शामिल है; इसका मतलब है कि आप files लोड कर रहे होंगे संग्रह और उसके बाद के chunks आपके कार्य सेट में संग्रह।
इस बात को ध्यान में रखते हुए हमने पहला रोड़ा पहले ही मारा है:
<ब्लॉकक्वॉट>क्या ग्रिडफ्स की फाइलें रैम में कैश की जाएंगी और यह पढ़ने-लिखने के प्रदर्शन को कैसे प्रभावित करेगी?
सीधे RAM से छोटी फ़ाइलों का पठन प्रदर्शन कमाल का हो सकता है; लेखन उतना ही अच्छा होगा।
बड़ी फ़ाइलों के लिए, ऐसा नहीं है। अधिकांश कंप्यूटरों में 600 जीबी रैम नहीं होगा और वास्तव में, एक फ़ाइल के 600 जीबी विभाजन को एक mongod पर रखना वास्तव में काफी सामान्य है। उदाहरण। यह एक समस्या पैदा करता है क्योंकि उस फ़ाइल को परोसने के लिए, आपके काम करने वाले सेट में फिट होने की आवश्यकता होती है, हालांकि यह आपकी रैम से असंभव रूप से बड़ी है; इस बिंदु पर आपके पास पेज थ्रैशिंग हो सकता है ( http://en.wikipedia.org/wiki/Thrashing_%28computer_science%29 ) जिससे सर्वर सिर्फ पेज फॉल्टिंग 24/7 फाइल लोड करने की कोशिश कर रहा है। यहाँ लिखने वाले भी बेहतर नहीं हैं।
इसका एकमात्र तरीका यह है कि एक ही फाइल को कई टुकड़ों में डालना शुरू किया जाए :\ ।
नोट:एक और बात पर विचार करना है कि एक chunks . का डिफ़ॉल्ट औसत आकार "चंक" 256KB है, इसलिए 600GB फ़ाइल के लिए बहुत सारे दस्तावेज़ हैं। यह सेटिंग अधिकांश ड्राइवरों में हेरफेर करने योग्य है।
जब मैं एक साथ कुछ फाइलें लिखने की कोशिश करता हूं तो ग्रिडफ के साथ क्या होगा। क्या रीड/राइट ऑपरेशंस के लिए कोई लॉक होगा? (मैं इसे केवल फ़ाइल संग्रहण के रूप में उपयोग करूंगा)
ग्रिडएफएस, केवल एक विनिर्देश होने के नाते, किसी भी अन्य संग्रह के समान ताले का उपयोग करता है, दोनों डेटाबेस स्तर (2.2+) या वैश्विक स्तर (पूर्व-2.2) पर ताले पढ़ते और लिखते हैं। दोनों एक-दूसरे के साथ भी हस्तक्षेप करते हैं, यानी आप जिस दस्तावेज़ को लिखा जा रहा है, उसे लगातार पढ़ना कैसे सुनिश्चित कर सकते हैं?
कहा जा रहा है कि विवाद की संभावना आपके परिदृश्य की बारीकियों, ट्रैफ़िक, समवर्ती लेखन/पढ़ने की संख्या और कई अन्य चीजों के आधार पर मौजूद है, जिनके बारे में हमें कोई जानकारी नहीं है।
<ब्लॉकक्वॉट>हो सकता है कि कुछ अन्य समाधान हों जो मेरी समस्या को अधिक कुशलता से हल कर सकते हैं?
मैंने व्यक्तिगत रूप से पाया है कि कम अतिरेक प्रारूप में S3 (जैसा कि @mluggy ने कहा) MongoDB के भीतर फ़ाइल के बारे में मेटा डेटा के एक मात्र हिस्से को संग्रहीत करने के लिए सबसे अच्छा काम करता है, बहुत कुछ GridFS का उपयोग करना पसंद करता है, लेकिन भाग संग्रह के बिना, S3 को उस सभी वितरण, बैकअप और आपके लिए अन्य सामान।
उम्मीद है कि मैं स्पष्ट हूं, उम्मीद है कि यह मदद करता है।
संपादित करें:मैंने जो गलती से कहा था, उसके विपरीत, MongoDB में संग्रह स्तर का ताला नहीं है, यह एक डेटाबेस स्तर का ताला है।
