तो मैं एक ऐसे ऐप का उपयोग कर रहा हूं जो डीबी में छवियों को बहुत अधिक संग्रहीत करता है। इस पर आपका दृष्टिकोण क्या है? मैं फाइलसिस्टम में स्थान को स्टोर करने के लिए एक प्रकार से अधिक हूं, सीधे डीबी में स्टोर करने से।
क्या आपको लगता है कि पेशेवरों / विपक्ष हैं?
जवाबों:
मैं कुछ एप्लिकेशन का प्रभारी हूं जो कई टीबी छवियों का प्रबंधन करता है। हमने पाया है कि डेटाबेस में फ़ाइल पथों को संग्रहीत करना सबसे अच्छा है।
कुछ मुद्दे हैं:
अधिकांश मुद्दों के साथ, यह उतना सरल नहीं है जितना लगता है। ऐसे मामले हैं जहां यह डेटाबेस में छवियों को संग्रहीत करने के लिए समझ में आता है।
दूसरी ओर इससे जुड़ी समस्याएं हैं
फ़ाइल स्टोर। फेसबुक के इंजीनियरों ने इसके बारे में बहुत अच्छी बात की। एक निर्देशिका में फ़ाइलों की व्यावहारिक सीमा जानने के लिए दूर ले जाना था।
यह थोड़ा लंबा शॉट हो सकता है, लेकिन यदि आप SQL सर्वर 2008 का उपयोग कर रहे हैं (या उपयोग करने की योजना बना रहे हैं) तो मैं नए फाइलस्ट्रीम डेटा प्रकार पर एक नज़र डालने की सलाह दूंगा ।
FileStream DB में फ़ाइलों को संग्रहीत करने के आसपास की अधिकांश समस्याओं को हल करता है:
हालाँकि SQL का "पारदर्शी डेटा एन्क्रिप्शन" FileStream ऑब्जेक्ट्स को एन्क्रिप्ट नहीं करता है, इसलिए यदि यह एक विचार है, तो आप उन्हें varbinary के रूप में संग्रहीत करने से बेहतर हो सकते हैं।
MSDN आलेख से:
Transact-SQL स्टेटमेंट्स, अपडेट, क्वेरी, सर्च, और FILESTREAM डेटा का बैकअप ले सकते हैं। Win32 फ़ाइल सिस्टम इंटरफ़ेस डेटा को स्ट्रीमिंग एक्सेस प्रदान करता है।
FILESTREAM फ़ाइल डेटा कैशिंग के लिए NT सिस्टम कैश का उपयोग करता है। यह किसी भी प्रभाव को कम करने में मदद करता है जो कि FILESTREAM डेटा डेटाबेस इंजन प्रदर्शन पर हो सकता है। SQL सर्वर बफ़र पूल का उपयोग नहीं किया जाता है; इसलिए, यह मेमोरी क्वेरी प्रोसेसिंग के लिए उपलब्ध है।
DB में फ़ाइल पथ निश्चित रूप से जाने का मार्ग है - मैंने ग्राहकों से कहानी के बाद कहानी सुनी है छवियों के टीबी के साथ कि यह एक दुःस्वप्न को किसी भी महत्वपूर्ण मात्रा में DB में संग्रहीत करने की कोशिश कर रहा है - प्रदर्शन अकेले बहुत अधिक है।
मेरे अनुभव में, कभी-कभी सबसे सरल समाधान प्राथमिक कुंजी के अनुसार छवियों को नाम देना है । इसलिए उस छवि को ढूंढना आसान है जो एक विशेष रिकॉर्ड से संबंधित है, और इसके विपरीत। लेकिन एक ही समय में आप डेटाबेस में छवि के बारे में कुछ भी संग्रहीत नहीं कर रहे हैं ।
यहाँ चाल एक जोल नहीं बनना है।
यहां एक बात ध्यान देने वाली है कि प्रो फाइल सिस्टम कैंप में किसी ने भी किसी विशेष फाइल सिस्टम को सूचीबद्ध नहीं किया है। क्या इसका मतलब यह है कि FAT16 से ZFS तक हर चीज हर डेटाबेस को हर्ट करती है?
नहीं।
सच्चाई यह है कि कई डेटाबेस कई फाइल सिस्टम को हरा देते हैं, यहां तक कि जब हम केवल कच्ची गति के बारे में बात कर रहे होते हैं।
कार्रवाई का सही तरीका आपके सटीक परिदृश्य के लिए सही निर्णय लेना है, और ऐसा करने के लिए, आपको कुछ नंबरों और कुछ उपयोग केस अनुमानों की आवश्यकता होगी।
उन जगहों पर जहाँ आप संदर्भात्मक अखंडता और ACID अनुपालन की गारंटी देते हैं, डेटाबेस में छवियों को संग्रहीत करना आवश्यक है।
आप लेन-देन की गारंटी नहीं दे सकते कि डेटाबेस में संग्रहीत उस छवि के बारे में छवि और मेटा-डेटा एक ही फ़ाइल को संदर्भित करता है। दूसरे शब्दों में, यह गारंटी देना असंभव है कि फ़ाइल सिस्टम पर फ़ाइल केवल एक ही समय में और मेटाडेटा के समान लेनदेन में कभी-कभी बदल जाती है।
जैसा कि दूसरों ने कहा है कि एसक्यूएल 2008 एक फाइलरेस्ट प्रकार के साथ आता है जो आपको डीबी में एक पॉइंटर के रूप में एक फ़ाइलनाम या पहचानकर्ता को संग्रहीत करने की अनुमति देता है और अपने फाइल सिस्टम पर छवि को स्वचालित रूप से संग्रहीत करता है जो एक महान परिदृश्य है।
यदि आप एक पुराने डेटाबेस पर हैं, तो मैं कहूंगा कि यदि आप इसे बूँद डेटा के रूप में संग्रहीत कर रहे हैं, तो आप वास्तव में खोज सुविधाओं के रास्ते में डेटाबेस से कुछ भी प्राप्त नहीं करने वाले हैं, इसलिए यह संभवतः सबसे अच्छा है किसी फ़ाइल सिस्टम पर एक पता संग्रहीत करने के लिए, और उस तरह से छवि को संग्रहीत करें।
इस तरह आप अपने फाइल सिस्टम पर स्पेस भी बचाते हैं, क्योंकि आप केवल स्पेस की सही मात्रा, या फाइल सिस्टम पर कॉम्पैक्ट स्पेस को बचाने के लिए जा रहे हैं।
इसके अलावा, आप कुछ संरचना या तत्वों के साथ सहेजने का निर्णय ले सकते हैं जो आपको बिना किसी डीबी हिट के अपने फाइल सिस्टम में कच्ची छवियों को ब्राउज़ करने या किसी अन्य सिस्टम, हार्ड ड्राइव, एस 3 या किसी अन्य परिदृश्य में बल्क में फ़ाइलों को स्थानांतरित करने की अनुमति देता है - स्थान को अपडेट करना आपके कार्यक्रम, लेकिन भंडारण को बढ़ाने की कोशिश करते समय, अपने डीबी से छवियों को लाने की कोशिश कर रहे हिट के बिना फिर से संरचना रखें।
संभवतः, यह आपको कुछ कैशिंग तत्व को फेंकने की अनुमति देगा, जो आमतौर पर आपके वेब इंजन / प्रोग्राम में हिट छवि के आधार पर होता है, इसलिए आप स्वयं को भी वहीं सहेज रहे हैं।
छोटी स्थिर छवियां (एक जोड़े से अधिक नहीं), जिन्हें अक्सर संपादित नहीं किया जाता है, उन्हें डेटाबेस में संग्रहीत किया जाना चाहिए। इस विधि में आसान पोर्टेबिलिटी (चित्र डेटाबेस के साथ स्थानांतरित), आसान बैकअप / पुनर्स्थापना (छवियां डेटाबेस के साथ समर्थित हैं) और बेहतर स्केलेबिलिटी (हज़ारों छोटे फ़ाइल फ़ाइलों वाला एक फ़ाइल सिस्टम फ़ोल्डर) स्केलेबिलिटी दुःस्वप्न की तरह लगता है सहित कई लाभ हैं मुझे)।
एक डेटाबेस से छवियों की सेवा करना आसान है, बस एक http हैंडलर लागू करें जो DB सर्वर से बाइनरी स्ट्रीम के रूप में लौटे बाइट सरणी को परोसता है।
यहाँ विषय पर एक दिलचस्प श्वेत पत्र है।
BLOB या नहीं BLOB करने के लिए: एक डेटाबेस या एक फाइल सिस्टम में बड़ी वस्तु भंडारण
उत्तर है, यह निर्भर करता है।" निश्चित रूप से यह डेटाबेस सर्वर और ब्लॉब स्टोरेज के लिए इसके दृष्टिकोण पर निर्भर करेगा। यह इस बात पर भी निर्भर करता है कि ब्लॉब्स में किस प्रकार का डेटा संग्रहीत किया जा रहा है, साथ ही उस डेटा तक कैसे पहुँचा जा सकता है।
भंडारण प्रणाली के रूप में डेटाबेस का उपयोग करके छोटे आकार की फ़ाइलों को कुशलतापूर्वक संग्रहीत और वितरित किया जा सकता है। फ़ाइल सिस्टम का उपयोग करके बड़ी फ़ाइलों को संभवतः सबसे अच्छा संग्रहित किया जाएगा, खासकर यदि वे अक्सर संशोधित / अपडेट किए जाएंगे। (प्रदर्शन के संबंध में बूँद विखंडन एक मुद्दा बन जाता है।)
यहां एक और बात ध्यान रखने की है। ब्लॉब्स को संग्रहीत करने के लिए डेटाबेस के उपयोग का समर्थन करने वाले कारणों में से एक ACID अनुपालन है। हालाँकि, एप्रोच जो कि व्हाइट पेपर में इस्तेमाल किया गया था, (थोक सर्वर का थोक लॉग ऑप्शन), जिसने एसक्यूएल सर्वर थ्रूपुट को दोगुना कर दिया, प्रभावी रूप से ACID में 'D' को 'd' में बदल दिया, क्योंकि ब्लॉब डेटा लॉग इन नहीं था लेन-देन के लिए प्रारंभिक लिखता है। इसलिए, यदि आपके सिस्टम के लिए पूर्ण ACID अनुपालन एक महत्वपूर्ण आवश्यकता है, तो डेटाबेस I के लिए SQL सर्वर थ्रूपुट के आंकड़ों को आधा लिखें जब I / O से डेटाबेस ब्लॉब I / O की तुलना करें।
एक बात जो मैंने अभी तक किसी का उल्लेख नहीं देखा है, लेकिन निश्चित रूप से ध्यान देने योग्य है कि ज्यादातर फाइल सिस्टम में बड़ी मात्रा में छवियों को संग्रहीत करने से जुड़े मुद्दे हैं। उदाहरण के लिए यदि आप उपर्युक्त दृष्टिकोण लेते हैं और प्राथमिक कुंजी के बाद प्रत्येक छवि फ़ाइल को नाम देते हैं, तो अधिकांश फाइल सिस्टम में आप उन मुद्दों पर चलेंगे यदि आप सभी छवियों को एक बड़ी निर्देशिका में रखने का प्रयास करते हैं, जब आप बहुत बड़ी संख्या में चित्र तक पहुँचते हैं ( हजारों या लाखों की संख्या में)।
एक बार इसका सामान्य समाधान उपनिर्देशिका के संतुलित वृक्ष में उन्हें हैश करना है।
किसी ने कुछ भी उल्लेख नहीं किया है कि DB परमाणु कार्यों, लेन-देन की अखंडता और संगामिति से संबंधित गारंटी देता है। यहां तक कि संदर्भित रूप से अखंडता एक फ़ाइल सिस्टम के साथ खिड़की से बाहर है - तो आपको कैसे पता चलेगा कि आपकी फ़ाइल के नाम वास्तव में अभी भी सही हैं?
यदि आपके पास फ़ाइल-सिस्टम में आपकी छवियां हैं और कोई व्यक्ति फ़ाइल को पढ़ रहा है जैसा कि आप एक नया संस्करण लिख रहे हैं या फ़ाइल को हटा भी रहे हैं - तो क्या होता है?
हम ब्लब्स का उपयोग करते हैं क्योंकि वे प्रबंधन करना आसान है (बैकअप, प्रतिकृति, स्थानांतरण) भी। वे हमारे लिए अच्छा काम करते हैं।
एक डेटाबेस में केवल फ़ाइलपथ को संग्रहीत करने के साथ समस्या यह है कि डेटाबेस की अखंडता को अब मजबूर नहीं किया जा सकता है।
यदि फ़ाइलपथ द्वारा इंगित वास्तविक छवि अनुपलब्ध है, तो डेटाबेस में अनजाने में एक अखंडता त्रुटि है।
यह देखते हुए कि छवियां वास्तविक डेटा के बाद मांगी जा रही हैं, और उन्हें किसी एक तरह के फाइल सिस्टम के साथ इंटरफेस करने के बजाय एक एकीकृत डेटाबेस में आसान (चित्र अचानक गायब नहीं होंगे) प्रबंधित किया जा सकता है (यदि फाइल सिस्टम स्वतंत्र रूप से एक्सेस किया गया है) चित्र अचानक "गायब" हो जाते हैं), मैं उन्हें सीधे बीएलओबी या ऐसे स्टोर करने के लिए जाऊंगा।
जिस कंपनी में मैं काम करता था, वहां हमने Oracle 8i (तब 9i) डेटाबेस में 155 मिलियन इमेज स्टोर की थीं। 7.5 टीबी मूल्य।
आम तौर पर, मैं आपके इन्फ्रास्ट्रक्चर (डेटाबेस) के बड़े पैमाने पर सबसे महंगे और सबसे मुश्किल हिस्से को लेने और उसमें सारा बोझ डालने के खिलाफ हूँ। दूसरी ओर: यह बैकअप रणनीति को बहुत सरल करता है, खासकर जब आपके पास कई वेब सर्वर हैं और किसी तरह डेटा को सिंक्रनाइज़ रखने की आवश्यकता है।
अधिकांश अन्य चीजों की तरह, यह अपेक्षित आकार और बजट पर निर्भर करता है।
हमने एक डॉक्यूमेंट इमेजिंग सिस्टम लागू किया है जो SQL2005 बूँद फ़ील्ड में सभी छवियों को संग्रहीत करता है। इस समय कई सौ जीबी हैं और हम उत्कृष्ट प्रतिक्रिया समय और कम या कोई प्रदर्शन गिरावट देख रहे हैं। इसके अलावा, fr विनियामक अनुपालन, हमारे पास एक मिडलवेयर परत है जो एक पोस्ट किए गए दस्तावेजों को एक ऑप्टिकल ज्यूकबॉक्स सिस्टम में संग्रहीत करता है जो उन्हें मानक NTFS फाइल सिस्टम के रूप में उजागर करता है।
हम परिणामों से बहुत प्रसन्न हुए हैं, विशेषकर सम्मान के साथ:
धारणा: एप्लिकेशन वेब सक्षम / वेब आधारित है
मुझे आश्चर्य है कि किसी ने भी वास्तव में इसका उल्लेख नहीं किया है ... इसे अन्य लोगों को सौंपें जो विशेषज्ञ हैं -> एक 3 पार्टी छवि / फ़ाइल होस्टिंग प्रदाता का उपयोग करें ।
अपनी फ़ाइलों को किसी भुगतान की गई ऑनलाइन सेवा की तरह संग्रहीत करें
एक और StackOverflow धागे के बारे में यहाँ बात कर रहा है ।
यह धागा बताता है कि आपको तीसरे पक्ष के होस्टिंग प्रदाता का उपयोग क्यों करना चाहिए।
यह इसके लायक है। वे इसे कुशलता से संग्रहीत करते हैं। कोई बैंडवाइट आपके सर्वर से क्लाइंट अनुरोधों आदि पर अपलोड नहीं हो रहा है।
यदि आप SQL Server 2008 पर नहीं हैं और आपके पास डेटाबेस में विशिष्ट छवि फ़ाइलों को रखने के लिए कुछ ठोस कारण हैं, तो आप "दोनों" दृष्टिकोण ले सकते हैं और एक अस्थायी कैश के रूप में फाइल सिस्टम का उपयोग कर सकते हैं और डेटाबेस को मास्टर रिपॉजिटरी के रूप में उपयोग कर सकते हैं। ।
उदाहरण के लिए, यदि आवश्यक हो तो डेटाबेस से पुनर्प्राप्त करने से पहले एक छवि फ़ाइल डिस्क पर मौजूद है, तो आपके व्यवसाय तर्क की जांच कर सकते हैं। यह आपको कई वेब सर्वर और कम समन्वयन समस्याओं की क्षमता खरीदता है।
मुझे यकीन नहीं है कि यह "वास्तविक दुनिया" का कितना उदाहरण है, लेकिन मेरे पास वर्तमान में एक आवेदन है जो कार्ड के लिए छवियों सहित एक ट्रेडिंग कार्ड गेम के लिए विवरण संग्रहीत करता है। दी गई गणना डेटाबेस के लिए रिकॉर्ड की तारीख तक केवल 2851 रिकॉर्ड है, लेकिन इस तथ्य को देखते हुए कि कुछ कार्डों को कई बार जारी किया गया है और वैकल्पिक कलाकृति है, यह वास्तव में कलाकृति के "प्राथमिक वर्ग" को स्कैन करने के लिए और फिर गतिशील रूप से अधिक कुशल आकार था। अनुरोध करने पर कार्ड के लिए सीमा और विविध प्रभाव उत्पन्न करें।
इस छवि पुस्तकालय के मूल निर्माता ने एक डेटा एक्सेस क्लास बनाया जो छवि को अनुरोध के आधार पर प्रस्तुत करता है, और यह देखने और व्यक्तिगत कार्ड के लिए काफी तेज करता है।
यह नए कार्ड जारी होने पर तैनाती / अपडेट को भी कम कर देता है, इसके बजाय छवियों के एक पूरे फ़ोल्डर को ज़िप करने और पाइप को नीचे भेजने और उचित फ़ोल्डर संरचना सुनिश्चित करने के बजाय, मैं बस डेटाबेस को अपडेट करता हूं और उपयोगकर्ता को इसे फिर से डाउनलोड करता हूं। यह वर्तमान में 56 एमबी तक का है, जो बहुत अच्छा नहीं है, लेकिन मैं भविष्य के रिलीज के लिए एक वृद्धिशील अद्यतन सुविधा पर काम कर रहा हूं। इसके अलावा, एप्लिकेशन का एक "नो इमेजेज" वर्जन है, जो डायल-अप को डाउनलोड विलंब के बिना एप्लिकेशन प्राप्त करने की अनुमति देता है।
इस समाधान ने बहुत अच्छा काम किया है क्योंकि एप्लिकेशन को डेस्कटॉप पर एकल उदाहरण के रूप में लक्षित किया गया है। एक वेब साइट है जहाँ यह सारा डेटा ऑनलाइन एक्सेस के लिए संग्रहीत किया गया है, लेकिन मैं इसके लिए किसी भी तरह के समाधान का उपयोग नहीं करूंगा। मैं मानता हूं कि फ़ाइल का उपयोग बेहतर होगा क्योंकि यह छवियों के लिए किए जा रहे अनुरोधों की आवृत्ति और मात्रा के लिए बेहतर होगा।
उम्मीद है कि यह बहुत अधिक कठिन नहीं है, लेकिन मैंने इस विषय को देखा और अपेक्षाकृत छोटे / मध्यम स्तर के आवेदन से अपनी कुछ अंतर्दृष्टि प्रदान करना चाहता था।
SQL Server 2008 एक समाधान प्रदान करता है जिसमें दोनों दुनिया के सबसे अच्छे हैं: फाइलस्ट्रीम डेटा प्रकार ।
इसे एक नियमित तालिका की तरह प्रबंधित करें और फ़ाइल सिस्टम का प्रदर्शन करें।
यह उन छवियों की संख्या पर निर्भर करता है जिन्हें आप स्टोर करने जा रहे हैं और उनके आकार भी। मैंने अतीत में छवियों को संग्रहीत करने के लिए डेटाबेस का उपयोग किया है और मेरा अनुभव काफी अच्छा रहा है।
IMO, छवियों को संग्रहीत करने के लिए डेटाबेस का उपयोग करने के पेशेवरों हैं,
A. आपको अपनी छवियों को रखने के लिए FS संरचना की आवश्यकता नहीं है
। बी। डेटाबेस इंडेक्स एफएस पेड़ों की तुलना में बेहतर प्रदर्शन करते हैं जब अधिक संख्या में आइटम संग्रहीत किए जाते हैं
। सी। स्मार्टली ट्यून किए गए डेटाबेस क्वेरी परिणामों को कैच करने में अच्छा काम करते हैं।
हैं। डी बैकअप सरल हैं। यह भी अच्छी तरह से काम करता है यदि आपके पास प्रतिकृति सेट अप है और सामग्री उपयोगकर्ता के पास सर्वर से वितरित की जाती है। ऐसे मामलों में, स्पष्ट सिंक्रनाइज़ेशन की आवश्यकता नहीं है।
यदि आपकी छवियां छोटी होने जा रही हैं (<64k) और आपके db का स्टोरेज इंजन इनलाइन (रिकॉर्ड में) BLOBs को सपोर्ट करता है, तो यह प्रदर्शन में सुधार करता है क्योंकि किसी अप्रत्यक्ष की आवश्यकता नहीं है (संदर्भ का स्थान प्राप्त होता है)।
जब आप बहुत बड़ी संख्या में विशाल आकार की छवियों के साथ काम कर रहे हों, तो छवियों को संग्रहीत करना एक बुरा विचार हो सकता है। Db में छवियों को संग्रहीत करने के साथ एक और समस्या यह है कि, मेटाडेटा जैसे निर्माण, संशोधन तिथियां आपके आवेदन द्वारा नियंत्रित की जानी चाहिए।
मैंने हाल ही में एक PHP / MySQL ऐप बनाया है जो एक MySQL टेबल में PDF / Word फ़ाइलों को संग्रहीत करता है (अब तक की फ़ाइल के अनुसार 40 एमबी जितना बड़ा)।
पेशेवरों:
विपक्ष:
मैं अपने कार्यान्वयन को एक सफलता कहूंगा, यह बैकअप आवश्यकताओं का ध्यान रखता है और परियोजना के लेआउट को सरल करता है। एप्लिकेशन का उपयोग करने वाले 20-30 लोगों के लिए प्रदर्शन ठीक है।
Im मेरा अनुभव मुझे दोनों स्थितियों का प्रबंधन करना था: डेटाबेस में संग्रहीत चित्र और db में संग्रहीत पथ के साथ फ़ाइल सिस्टम पर छवियां।
डेटाबेस में पहला समाधान, चित्र कुछ हद तक "क्लीनर" है क्योंकि आपके डेटा एक्सेस लेयर को केवल डेटाबेस ऑब्जेक्ट्स से निपटना होगा; लेकिन यह तभी अच्छा है जब आपको कम संख्या से निपटना होगा।
जब आप द्विआधारी बड़ी वस्तुओं के साथ सौदा करते हैं तो जाहिर तौर पर डेटाबेस का उपयोग प्रदर्शन अपमानजनक होता है, और डेटाबेस का आयाम बहुत बढ़ जाएगा, जिससे फिर से प्रदर्शन हानि हो सकती है ... और आमतौर पर डेटाबेस स्पेस फ़ाइल सिस्टम स्पेस की तुलना में बहुत अधिक महंगा होता है।
दूसरी ओर फ़ाइल सिस्टम में संग्रहीत बड़ी बाइनरी ऑब्जेक्ट्स के कारण आपके पास बैकअप योजनाएं होंगी जो डेटाबेस और फ़ाइल सिस्टम दोनों पर विचार करना होगा, और यह कुछ प्रणालियों के लिए एक समस्या हो सकती है।
फ़ाइल सिस्टम के लिए जाने का एक अन्य कारण यह है कि जब आपको अपने चित्र डेटा (या ध्वनियाँ, वीडियो, जो भी हो) को तृतीय पक्ष एक्सेस के साथ साझा करना होगा: इस दिनों में मैं एक वेब ऐप विकसित कर रहा हूं जो उन छवियों का उपयोग करता है जिन्हें "बाहर" से एक्सेस करना होता है "मेरा वेब फार्म इस तरह से है कि द्विआधारी डेटा को पुनः प्राप्त करने के लिए एक डेटाबेस का उपयोग बस असंभव है। तो कभी-कभी ऐसे डिज़ाइन विचार भी होते हैं जो आपको पसंद करेंगे।
इस बात पर भी विचार करें, जब बाइनरी ऑब्जेक्ट्स को एक्सेस करते समय आपको अनुमति और प्रमाणीकरण से निपटना पड़ता है, तो: इन आवश्यकताओं को सामान्य रूप से आसान तरीके से हल किया जा सकता है जब डेटा को डीबी में संग्रहीत किया जाता है।
मैंने एक बार एक इमेज प्रोसेसिंग एप्लिकेशन पर काम किया था। हमने अपलोड की गई छवियों को एक निर्देशिका में संग्रहीत किया है जो कुछ इस तरह की थी / छवियां / [आज की तारीख] / [आईडी नंबर]। लेकिन हमने छवियों से मेटाडेटा (एक्जिफ़ डेटा) भी निकाला और डेटाबेस में संग्रहीत किया, साथ ही टाइमस्टैम्प और जैसे।
पिछले प्रोजेक्ट में मैंने फाइल सिस्टम पर इमेजेस को स्टोर किया था, और जिसके कारण बैकअप, प्रतिकृति और डेटाबेस के साथ फाइल सिस्टम सिंक से बाहर निकल रहा था।
मेरे नवीनतम प्रोजेक्ट में मैं डेटाबेस में छवियों को संग्रहीत कर रहा हूं, और उन्हें फाइलसिस्टम पर कैशिंग कर रहा हूं, और यह वास्तव में अच्छी तरह से काम करता है। मुझे अब तक कोई समस्या नहीं है।
दूसरा फ़ाइल पथों पर अनुशंसा। मैंने कुछ परियोजनाओं पर काम किया है, जिनके लिए बड़े-ईश संपत्ति संग्रह को प्रबंधित करने की आवश्यकता होती है, और डीबी में सीधे चीजों को स्टोर करने के किसी भी प्रयास से दर्द और निराशा लंबे समय तक बनी रहती है।
एकमात्र वास्तविक "समर्थक" मैं उन्हें डीबी में संग्रहीत करने के बारे में सोच सकता हूं जो व्यक्तिगत छवि परिसंपत्तियों के आसान के लिए संभावित है। यदि उपयोग करने के लिए कोई फ़ाइल पथ नहीं हैं, और सभी छवियों को सीधे DB से बाहर प्रवाहित किया जाता है, तो उपयोगकर्ता को उन फ़ाइलों को खोजने का कोई खतरा नहीं है जिनकी उन्हें पहुंच नहीं होनी चाहिए।
ऐसा लगता है कि यह एक वेब-दुर्गम फ़ाइल स्टोर से डेटा खींचने वाले मध्यस्थ स्क्रिप्ट के साथ बेहतर हल होगा, हालांकि। तो DB भंडारण वास्तव में आवश्यक नहीं है।
सड़क पर शब्द यह है कि जब तक आप एक डेटाबेस विक्रेता साबित करने की कोशिश नहीं कर रहे हैं कि आपका डेटाबेस ऐसा कर सकता है (जैसे, मान लें कि Microsoft SQL Server में एक bajillion छवियों को संग्रहीत करने वाले Terraserver के बारे में घमंड करता है) यह बहुत अच्छा विचार नहीं है। जब वैकल्पिक - डेटाबेस में फ़ाइल सर्वर और पथ पर छवियों को संग्रहीत करना इतना आसान है, तो परेशान क्यों? बूँद क्षेत्र एसयूवी की ऑफ-रोड क्षमताओं की तरह होते हैं - ज्यादातर लोग उनका उपयोग नहीं करते हैं, जो लोग आमतौर पर परेशानी में पड़ जाते हैं, और फिर ऐसे लोग होते हैं जो ऐसा करते हैं, लेकिन केवल इसके मज़े के लिए।
डेटाबेस में एक छवि को संग्रहीत करने का अभी भी मतलब है कि छवि डेटा फ़ाइल सिस्टम में कहीं खत्म हो गया है लेकिन अस्पष्ट है ताकि आप इसे सीधे एक्सेस न कर सकें।
+ Ves:
-ves:
दोनों विधियाँ सामान्य और प्रचलित हैं। फायदे और नुकसान पर एक नजर। किसी भी तरह से, आपको यह सोचना होगा कि नुकसान को कैसे दूर किया जाए। डेटाबेस में संग्रहीत करने का मतलब आमतौर पर डेटाबेस मापदंडों को ट्विक करना और किसी प्रकार के कैशिंग को लागू करना है। फाइलसिस्टम का उपयोग करने के लिए आपको फाइलसिस्टम + डेटाबेस को सिंक में रखने का कोई तरीका खोजना होगा।