Django में छवि फ़ाइलों को कैसे स्टोर करें?

Question

Django में छवि फ़ाइलों को संग्रहीत करने का सामान्य परिदृश्य क्या है? अधिक विशेष रूप से, स्थानीय फाइल सिस्टम या अमेज़ॅन एस 3 पर सीधे डेटाबेस डेटाबेस (जैसे मोंगोडीबी ग्रिडएफएस) में संग्रहीत छवियां हैं? छवियों को संग्रहीत करने के साथ अपने जीवन को सरल बनाने के लिए सभी तीन मामलों के लिए उपकरण या django संकुल उपलब्ध हैं?

मैं वर्तमान में स्थानीय विकास सर्वर पर Django प्रोजेक्ट में मीडिया फ़ोल्डर से छवियों को सहेज रहा हूं और सेवा कर रहा हूं। किसी ने मुझे बताया कि यह एक ही मशीन पर स्थिर फाइलों की सेवा करने के लिए एक बुरा अभ्यास है। तो Django में स्थिर छवियों को संग्रहित और सेवा करने का एक सामान्य असली दुनिया परिदृश्य क्या है?

Answer 1

एक ठेठ, वास्तविक दुनिया उदाहरण आपकी साइट की media/ निर्देशिका :)

यह अगर आप अपने अनुप्रयोग सर्वर की तुलना में अधिक छवियों को स्टोर करने की जरूरत है एक समस्या बन सकता है की एक उपनिर्देशिका में अपलोड की गई छवियों को स्टोर करने के होगा हार्ड डिस्क है स्थान, या आपको एक से अधिक ऐप सर्वर की आवश्यकता है, या आप अपनी विलंबता को कम करने के लिए सीडीएन का उपयोग करना चाहते हैं, या ... हजारों अन्य चीज़ों में से एक।

लेकिन, जब तक कि आपको विशिष्ट अप-फ्रंट आवश्यकताएं न मिलें, तब तक यह जानने का एकमात्र तरीका है कि उन हजारों चीजों में से कौन सा (यदि कोई है) आपको चिंता करने की आवश्यकता होगी कि आपकी साइट लॉन्च हो, और सबसे तेज़ तरीका ऐसा करें media/ की उपनिर्देशिका में छवियों को स्टोर करना है।

आप इस एक FileField का उपयोग कर, और आप ग्रहण करने के लिए नहीं अपने कोड में सावधान, उदाहरण के लिए कर रहे हैं, उस छवि को अपने स्थानीय डिस्क पर एक फ़ाइल है (उदाहरण के लिए, आप की .url() विधि का उपयोग कर FileFile और आप .path संपत्ति का उपयोग करें), यह उन छवियों को एक और उचित बैकएंड पर ले जाने के लिए सीधे आगे होगा जब (और यदि) समय आता है।

Answer 2

डिफ़ॉल्ट रूप से, Django saves all of your files (and images) in the MEDIA_ROOT। हालांकि आप इसे अन्य स्थानों पर सहेजने के लिए custom file storage लिख सकते हैं।

क्या चुनना है? यह वास्तव में निर्भर करता है।
आप कितनी फाइलें स्टोर करने की योजना बना रहे हैं? वे कितना भंडारण उपयोग करेंगे? कितनी बैंडविड्थ? क्या आपको लगता है कि बहुत अधिक उपयोग की चोटी होगी?

आमतौर पर, स्थानीय फ़ाइल सिस्टम सबसे तेज़ विकल्प है; लेकिन यदि आप देखते हैं कि वे छवियां आपकी बैंडविड्थ का अधिक उपयोग करती हैं, तो आप उन्हें ऑफ़लोड करना चाहेंगे, खासकर यदि उपयोग पैटर्न उच्च चोटियों को देखता है। इसके विपरीत, यदि आपको कई सर्वरों पर स्केल करने की आवश्यकता है, तो आप उन्हें डेटाबेस में स्थानांतरित करने के लिए फायदेमंद पा सकते हैं।

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

Answer 3

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

आपके द्वारा उपयोग किए जा सकने वाले टूल के संदर्भ में, मैं पीआईएल में देखूंगा।http://www.pythonware.com/products/pil/

Answer 4

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

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

हालांकि, वहाँ एक अलग उपडोमेन के तहत निश्चित संसाधनों की सेवा में लाभ है। आप एक ही सर्वर का उपयोग कर सकते हैं, लेकिन सबडोमेन (जैसे static.mysite.com) का उपयोग करके ब्राउज़र को कुछ समानांतर डाउनलोड करने की अनुमति मिल जाएगी, कुछ मामलों में, और कम से कम, मुख्य वेबसाइट से कुकीज़ को प्रत्येक स्थिर से संलग्न होने से रोकती है निवेदन।