एएसपी.नेट एमवीसी छवि अपलोड स्टोर स्थान (डीबी बनाम फाइल सिस्टम)

Question

मैं एएसपी.नेट एमवीसी + एनएचबीरनेट + पोस्ट्रेस स्टैक का उपयोग कर वेब एप्लिकेशन लिख रहा हूं। मुझे आश्चर्य है कि अपलोड की गई छवियों को डेटाबेस में बाइनरी ब्लॉब्स या फाइल सिस्टम पर संग्रहीत किया जाना चाहिए (और केवल डीबी में संदर्भ)। डीबी स्टोरेज का एक लाभ मैं सोच सकता हूं कि फाइल सिस्टम कॉपी टूल्स को वापस किए बिना सभी डेटा का आसान बैकअप/रिकवरी है। दूसरी तरफ मुझे संदेह है कि फाइल सिस्टम एक्सेस तेज हो सकता है (लेकिन क्या यह विशेष रूप से कई समवर्ती अनुरोधों से निपटने पर है?) आपके सुझाव क्या हैं?

Answer 1

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

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

पोस्टग्रेएसक्यूएल के लिए केवल एक कार्यान्वयन नोट विशेष रूप से: आप अपने छवि डेटा वाले "स्टोरेज मोड" को "बाहरी" में सेट कर सकते हैं: यह पोस्टग्रेएसक्यूएल को छवि डेटा को संपीड़ित करने की कोशिश कर देगा (zlib का उपयोग करके, जो नहीं है किसी भी लाभ प्रदान करने की संभावना है) और यदि आप छवि मेटाडेटा से पूछताछ कर रहे हैं तो बेहतर प्रदर्शन प्रदान करते हुए, इसे एक सहायक टोस्ट तालिका में छवि डेटा स्टोर कर देगा। ALTER TABLE आदेश के "सेट भंडारण" खंड, उदा .:

ALTER TABLE media.image ALTER COLUMN content SET STORAGE EXTERNAL 

Answer 2

यह निर्भर करता है। क्या आप सीधे किसी छवि से लिंक करने में सक्षम होने का मानते हैं, या क्या आप हमेशा डीबी को कॉल करने के लिए सर्वर साइड संसाधनों का उपयोग करना चाहते हैं, और फिर छवि के लिए बाइनरी डेटा लिखना चाहते हैं?

Answer 3

देखें हम बैकअप के लिए डेटाबेस में मूल के भंडारण का उपयोग, लेकिन नीचे छवियों कि वेबसर्वर पर फाइल सिस्टम पर कैश किया गया है बढ़ाया से जेनरेट किए।

हालांकि, हम संभवतः डेटाबेस में किसी भी राउंडट्रिप्स से बचने की कोशिश करते हैं, क्योंकि यह भारी लोड उत्पन्न करता है क्योंकि एक पृष्ठ आमतौर पर प्रति पेज-व्यू के कई छवि-अनुरोधों को आमंत्रित करता है।

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

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

बस मेरे दो सेंट।