मैं एक नई वेबसाइट विकसित करता हूं और सभी उपयोगकर्ताओं के अपलोड के लिए ग्रिड के रूप में ग्रिड्सएफएस का उपयोग करना चाहता हूं, क्योंकि यह सामान्य फाइल सिस्टम स्टोरेज की तुलना में बहुत अधिक लाभ प्रदान करता है।
Nginx द्वारा सेवा की गई GridFS के साथ बेंचमार्क इंगित करता है, कि यह nginx द्वारा सेवा की गई एक सामान्य फाइल सिस्टम के रूप में तेज़ नहीं है।
क्या कोई बाहर है, जो पहले से ही उत्पादन के माहौल में ग्रिड्स का उपयोग करता है, या एक नई परियोजना के लिए इसका उपयोग करेगा?
जवाबों:
मैं अपने एक सर्वर पर काम करने के लिए ग्रिडफ़ोर्स का उपयोग करता हूं जो कि माननीय ट्रैफ़िक आँकड़ों (प्रति दिन 25k आगंतुकों के आसपास) के साथ मूल्य-तुलना करने वाली वेबसाइट का हिस्सा है। सर्वर में बहुत अधिक रैम, 2gigs नहीं है, और यहां तक कि सीपीयू वास्तव में तेज नहीं है (कोर 2 डुओ 1.8Ghz) लेकिन सर्वर में बहुत अधिक स्टोरेज स्पेस है: छापे 0 कॉन्फ़िगरेशन में 10Tb (sata)। सर्वर जो काम कर रहा है वह बहुत सरल है:
हमारी कीमत-तुलना करने वाले प्रत्येक उत्पाद में एक छवि होती है (हमारे उत्पाद db के अनुसार लगभग 10 मिलियन उत्पाद होते हैं), और सर्वर का काम छवि को डाउनलोड करना, उसका आकार बदलना, उसे ग्रिडफिश पर स्टोर करना और आगंतुकों के ब्राउज़र तक पहुंचाना है। .. अगर यह ग्रिड में मौजूद नहीं है ... या ... इसे विज़िटर ब्राउज़र में वितरित करें यदि यह ग्रिड में पहले से ही संग्रहीत है। तो, इसे 'पारंपरिक सीडीएन स्कीमा' कहा जा सकता है।
हमने इस सर्वर पर 4 मिलियन छवियों को संग्रहीत और संसाधित किया है क्योंकि यह ऊपर और चल रहा है। आकार और भंडार सामान एक साधारण php स्क्रिप्ट द्वारा किया जाता है ... लेकिन निश्चित रूप से, एक पायथन स्क्रिप्ट, या जावा जैसी कोई चीज़ तेज़ हो सकती है।
वर्तमान डेटा का आकार: 11.23 जी
वर्तमान भंडारण का आकार: 12.5 ग्राम
संकेत: 5
सूचकांक का आकार: 849.65 मी
विश्वसनीयता के बारे में: यह बहुत विश्वसनीय है। सर्वर लोड नहीं करता है, इंडेक्स का आकार ठीक है, क्वेरीज़ तेज़ हैं
गति के बारे में: निश्चित रूप से, क्या यह स्थानीय फ़ाइल संग्रहण के रूप में तेज़ नहीं है, हो सकता है कि 10% धीमा हो, लेकिन तेजी से वास्तविक समय में उपयोग किया जा सकता है जब छवि को संसाधित करने की आवश्यकता होती है, जो हमारे मामले में बहुत php पर निर्भर है। रखरखाव और विकास के समय को भी कम कर दिया गया है: एक एकल या कई छवियों को हटाना इतना सरल हो गया: बस एक साधारण डिलीट कमांड के साथ db को क्वेरी करें। एक और दिलचस्प बात: जब हमने अपने पुराने सर्वर को रीबूट किया, तो स्थानीय फ़ाइल स्टोरेज (हजारों फ़ोल्डरों में लाखों फाइलें), यह कभी-कभी घंटों तक लटका रहता है, क्योंकि सिस्टम एक फ़ाइल अखंडता जांच कर रहा था (यह वास्तव में घंटों ...)। हमें ग्रिडफ़स के साथ यह समस्या नहीं है, हमारी छवियां अब बड़े मोंगोडब चंक्स में संग्रहीत हैं (2 जीबी फाइलें)
इसलिए ... मेरे दिमाग में ... हां, उत्पादन के लिए इस्तेमाल किए जाने वाले ग्रिडएफ़ तेज़ और विश्वसनीय हैं।
जैसा कि उल्लेख किया गया है, यह एक साधारण फाइलसिस्टम की तरह तेज नहीं हो सकता है, लेकिन फिर यह आपको सामान्य फाइलसिस्टम से अधिक लाभ देता है जो मुझे लगता है कि इसके लिए थोड़ी गति देने के लायक है।
अंत में, शार्पिंग के साथ, आप एक ऐसे बिंदु पर पहुंच सकते हैं, जहाँ ग्रिड्स भंडारण वास्तव में एक साधारण फाइल सिस्टम और एक नोड के विपरीत तेज विकल्प बन जाता है।
बड़े DBs की मरम्मत पर हेड-अप हालांकि - एक नई प्रणाली जिसे हम विकसित कर रहे हैं, मोंगो सफाई से बाहर नहीं निकली, और 7TB ग्रिड्स की मरम्मत करने से ऐसा लगता है कि यह 130 घंटे लगेगा।
इस वजह से, मुझे लगता है कि मैं ओपनस्टैक स्विफ्ट या सेफ पर स्विच करना चाहूंगा। फिर भी, तब तक अच्छा था। और नेगनेक्स-ग्रिडफ़्स मॉड्यूल मीठा है।
जब तक आप नहीं जानते कि आप क्या कर रहे हैं, मैं ग्रिडफ़ोर्स का उपयोग करने की सलाह नहीं देता। GridFS सिर्फ अमूर्त परत है जो चंक्स के लिए फ़ाइलों को विभाजित करती है और फ़ाइलों को दो संग्रहों में संग्रहीत करती है। अधिक फाइलें - अधिक ओवरहेड। यदि आप उम्मीद करते हैं कि फ़ाइलें समान आकार की होंगी, तो 32M या उससे अधिक नहीं - आप सही तरीके से हैं। ग्रिडफ़्स पर बड़ी फ़ाइलों को संग्रहीत करने का प्रयास न करें। क्यों?
यदि आप पढ़े गए लोड किए गए प्रोजेक्ट के बारे में सोचते हैं - फ़ाइलों को सीधे डॉक्स में लोड करने पर विचार करें (यदि 16M या उससे कम आकार में) या किसी अन्य क्लस्टर का चयन करें, और फ़ाइल नाम / इनकोड को अपने तर्क से लिंक करें।
उम्मीद है की यह मदद करेगा।