क्या डेटाबेस में बड़ी फ़ाइलों (10 एमबी) को स्टोर करना एक बुरा अभ्यास है?

Question

मैं वर्तमान में एक वेब एप्लिकेशन बना रहा हूं जो उपयोगकर्ताओं को फ़ाइलों, 1 एमबी - 10 एमबी को आकार में स्टोर और साझा करने की अनुमति देता है।

यह मुझे लगता है कि डेटाबेस में फ़ाइलों को संग्रहीत करने से डेटाबेस की पहुंच काफी कम हो जाएगी।

क्या यह एक वैध चिंता है? क्या फ़ाइल सिस्टम में फ़ाइलों को संग्रहीत करना और डेटाबेस में फ़ाइल नाम और पथ को सहेजना बेहतर है? क्या डेटाबेस के साथ काम करते समय फ़ाइलों को संग्रहीत करने से संबंधित कोई सर्वोत्तम प्रथा है?

मैं इस परियोजना के लिए PHP और MySQL में काम कर रहा हूं, लेकिन अधिकांश वातावरण ( रूबी ऑन रेल्स , PHP , .NET ) और डेटाबेस (MySQL, PostgreSQL ) के लिए एक ही मुद्दा है ।

Comments

DBA.SE पर संबंधित प्रश्न: फाइलें - डेटाबेस में हैं या नहीं?

— निक चामास

आश्चर्य हुआ कि इस मुद्दे पर (SQL सर्वर 2008 के लिए) किसी ने भी MS शोध को पोस्ट नहीं किया: BLOB या नॉट टू BLOB: लार्ज ऑब्जेक्ट स्टोरेज इन ए डेटाबेस या फाइलसिस्टम

— Oded

बड़ी एक सापेक्ष मात्रा है, मैं (और कई अन्य शायद) 10MBएक आधुनिक प्रणाली में बड़े रूप में नहीं देखते हैं ।

एफएक्यू के अनुसार यह ऑन-टॉपिक है - यह गोलियों के नीचे "डिजाइन पैटर्न" (स्लैश एंटीपैटर्नस) और "डिजिटल आर्किटेक्चर" के तहत फिट बैठता है। इसे बंद क्यों किया गया?

— इज़्काता

मुझे प्रश्न में कोई अस्पष्टता नहीं दिख रही है क्योंकि यह अब है। मुझे नहीं पता कि इसे बंद क्यों किया गया।

— रीयरियरपोस्ट

Answer 1

डेटाबेस में फ़ाइलों को संग्रहीत करने के पक्ष में कारण:

1. डेटाबेस के बाहर फ़ाइलों को संग्रहीत करने पर जटिल अद्यतन के रोलबैक सहित ACID संगति। यह हल्के ढंग से चमकाने के लिए नहीं है। फ़ाइलों और डेटाबेस को सिंक में रखना और लेनदेन में भाग लेने में सक्षम होना बहुत उपयोगी हो सकता है।
2. फ़ाइलें डेटाबेस के साथ जाती हैं और इससे अनाथ नहीं किया जा सकता है।
3. बैकअप में स्वचालित रूप से फ़ाइल बायनेरिज़ शामिल हैं।

डेटाबेस में फ़ाइलें संग्रहीत करने का कारण:

1. एक बाइनरी फ़ाइल का आकार डेटाबेस के बीच भिन्न होता है। SQL सर्वर पर, जब FILESTREAM ऑब्जेक्ट का उपयोग नहीं किया जाता है, उदाहरण के लिए, यह 2 जीबी है। यदि उपयोगकर्ताओं को बड़ी फ़ाइलों को संग्रहीत करने की आवश्यकता होती है (जैसे कि मूवी कहते हैं), तो आपको उस जादू को बनाने के लिए हुप्स के माध्यम से कूदना होगा।
2. डेटाबेस का आकार बढ़ाता है। एक सामान्य अवधारणा जिसे आपको ध्यान में रखना चाहिए: डेटाबेस को बनाए रखने के लिए आवश्यक ज्ञान का स्तर डेटाबेस के आकार के अनुपात में ऊपर जाता है।यानी, बड़े डेटाबेस छोटे डेटाबेस की तुलना में अधिक जटिल होते हैं। डेटाबेस में फ़ाइलों को संग्रहीत करना डेटाबेस को बहुत बड़ा बना सकता है। यहां तक ​​कि अगर कहते हैं कि एक दैनिक पूर्ण बैकअप एक बड़े डेटाबेस आकार के साथ पर्याप्त होगा, तो आप अब ऐसा करने में सक्षम नहीं होंगे। आपको फ़ाइलों को एक अलग फ़ाइल समूह पर रखने पर विचार करना पड़ सकता है (यदि डेटाबेस उस का समर्थन करता है), बैकअप के लिए डेटा के बैकअप को फ़ाइलों के बैकअप से अलग करने के लिए ट्विक करें आदि। इनमें से कोई भी चीज़ सीखना असंभव नहीं है, लेकिन करें रखरखाव के लिए जटिलता जोड़ें जो व्यवसाय के लिए लागत का मतलब है। बड़े डेटाबेस भी अधिक मेमोरी का उपभोग करते हैं क्योंकि वे मेमोरी में जितना संभव हो उतना डेटा रखने की कोशिश करते हैं।
3. पोर्टेबिलिटी एक चिंता का विषय हो सकता है यदि आप SQL सर्वर के FILESTREAMऑब्जेक्ट जैसी सिस्टम विशिष्ट सुविधाओं का उपयोग करते हैं और एक अलग डेटाबेस सिस्टम में माइग्रेट करने की आवश्यकता होती है।
4. डेटाबेस में फाइल लिखने वाला कोड एक समस्या हो सकती है। एक कंपनी, जिसके लिए मैंने कुछ समय पहले इतने सारे चंद्रमाओं से परामर्श नहीं किया था, अपने डेटाबेस सर्वर से एक माइक्रोसॉफ्ट एक्सेस फ्रंटएंड से जुड़ा था और अपने ओले ऑब्जेक्ट कंट्रोल का उपयोग करके "कुछ भी" अपलोड करने की एक्सेस की क्षमता का उपयोग किया था। बाद में उन्होंने एक अलग नियंत्रण का उपयोग करने के लिए बदल दिया जो अभी भी ओले पर निर्भर था। बहुत बाद में किसी ने कच्चे बाइनरी को स्टोर करने के लिए इंटरफ़ेस बदल दिया। उन ओले ऑब्जेक्ट को निकालना नरक का एक नया स्तर था। जब आप फ़ाइल सिस्टम पर फ़ाइलों को संग्रहीत करते हैं, तो स्रोत फ़ाइल को लपेटने / मोड़ने / बदलने के लिए एक अतिरिक्त परत शामिल नहीं होती है।
5. किसी वेबसाइट पर फ़ाइलों की सेवा करना अधिक जटिल है। बाइनरी कॉलम के साथ ऐसा करने के लिए, आपको डेटाबेस से फ़ाइल बाइनरी को स्ट्रीम करने के लिए एक हैंडलर लिखना होगा। यदि आप फ़ाइल पथ संग्रहीत करते हैं, तो भी आप ऐसा कर सकते हैं, लेकिन आपको ऐसा करने की आवश्यकता नहीं है । फिर से, एक हैंडलर जोड़ना असंभव नहीं है, लेकिन जटिलता जोड़ता है और विफलता का एक और बिंदु है।
6. आप क्लाउड स्टोरेज का लाभ नहीं उठा सकते हैं। मान लीजिए कि एक दिन आप अपनी फाइलों को अमेजन S3 बाल्टी में स्टोर करना चाहते हैं। यदि आप डेटाबेस में जो स्टोर करते हैं वह फ़ाइल पथ हैं, तो आपको S3 में उन रास्तों को बदलने की क्षमता प्रदान की जाती है। जहां तक ​​मुझे पता है, किसी भी परिदृश्य में किसी भी DBMS के साथ संभव नहीं है।

IMO, डेटाबेस में फ़ाइलों के भंडारण को ख़त्म करना या "खराब" के रूप में परिस्थितियों और आवश्यकताओं के बारे में अधिक जानकारी की आवश्यकता नहीं है। क्या आकार और / या फ़ाइलों की संख्या हमेशा छोटी होने वाली है? क्या क्लाउड स्टोरेज का उपयोग करने की कोई योजना नहीं है? क्या फ़ाइलों को एक वेबसाइट या विंडोज एप्लिकेशन की तरह एक द्विआधारी निष्पादन योग्य बनाया जाएगा?

सामान्य तौर पर, मेरे अनुभव में पाया गया है कि एसीआईडी ​​की कमी और अनाथों की संभावना के लिए लेखांकन के लिए पथ को संग्रहीत करना व्यवसाय के लिए कम महंगा है। हालांकि, इसका मतलब यह नहीं है कि फ़ाइल भंडारण के साथ गलत हो रही ACID नियंत्रण की कमी की कहानियों के साथ इंटरनेट कानूनी नहीं है, लेकिन इसका मतलब यह है कि सामान्य रूप से समाधान बनाना, समझना और बनाए रखना आसान है।

Comments

आप CDN का उपयोग क्यों नहीं कर सकते? यह बहुत ही हर CDN के साथ एक समर्थित परिदृश्य है जिसके बारे में मैंने कभी सुना है।

— बिली ओनली

@BillyONeal - आप सीडीएन का उपयोग नहीं कर सकते हैं और डेटाबेस में फाइल स्टोर कर सकते हैं । जब तक आप दोहराव के साथ ठीक नहीं होते हैं, आप दोनों नहीं हो सकते।

— थॉमस

एर्म, एक CDN का पूरा बिंदु दोहराव है। सीडीएन केवल एक वेब पते के लक्ष्य को कैश करता है - केवल आवश्यकता यह है कि सामग्री की सेवा करने वाला एक HTTP होस्ट है, और यह कि सामग्री शायद ही कभी बदलती है। (पृथ्वी पर सीडीएन यह बताने वाला है कि आपने छवि को किसी भी तरह से कहां से खींचा है?)

— बिली ओनली

@ बिलियन - हालांकि, मुझे लगता है कि यह मेरी ओर से शब्दों का बुरा विकल्प है और मैंने अपना उत्तर समायोजित कर लिया है। विशेष रूप से, यदि आप क्लाउड स्टोरेज का उपयोग करना चाहते हैं (और फिर शायद अपने क्लाउड स्टोरेज के साथ CDN का उपयोग करते हैं), तो आप इसे डेटाबेस स्टोरेज समाधान के साथ मूल रूप से नहीं कर सकते। आपको डेटाबेस से फ़ाइलों को खींचने के लिए एक सिंक्रनाइज़ेशन रूटीन लिखना होगा और फिर उन्हें अपने क्लाउड स्टोरेज प्रदाता को भेजना होगा।

— थॉमस

@ बिलियन - एक तरह से, आपकी टिप्पणी सबसे अच्छा जवाब थी। आप DB भंडारण के सभी लाभ हो सकते हैं, लेकिन समस्याओं में से कोई भी नहीं।

— बी सेवन

Answer 2

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

हालाँकि! कुछ डेटाबेस, जैसे SQL सर्वर में एक FILESTREAM स्तंभ प्रकार होता है। इस स्थिति में, आपका डेटा वास्तव में डेटाबेस सर्वर पर एक अलग फ़ाइल में संग्रहीत किया जाता है और केवल एक आईडी से फ़ाइल को तालिका में सहेजा जाता है। इस मामले में मुझे SQL सर्वर में डेटा को न रखने का एक कारण दिखाई नहीं देता है। फ़ाइलों को स्वचालित रूप से सर्वर बैकअप के भाग के रूप में शामिल किया जाता है, और डेटाबेस और फाइलें कभी भी सिंक से बाहर नहीं होती हैं। फ़ाइल नामों को संग्रहीत करने के टोनी के सुझाव के साथ समस्या यह है कि डेटाबेस और फाइल सिस्टम सिंक से बाहर निकल सकते हैं। डिस्क पर डिलीट होने पर डेटाबेस किसी फाइल के मौजूद होने का दावा करेगा। यदि एक प्रक्रिया डेटाबेस को संशोधित कर रही है और फिर क्रैश हो जाती है, तो फाइलें और डेटाबेस मेल नहीं खाएंगे (यानी डेटाबेस के बाहर की फाइलों के साथ कोई एसीआईडी नहीं )।

Comments

मैं इस कथन से असहमत हूं कि 'यदि कोई प्रक्रिया DB को संशोधित कर रही है और फिर क्रैश हो जाती है, तो फ़ाइलें और DB मेल नहीं खाएंगे।' जब कुछ गलत हो जाता है तो उन्हें सिंक में रखना काफी आसान होता है।

— ब्रिजिड्स

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

— वार्टेक

फ़ाइल / DB विधि के साथ अन्य संभावित समस्याएं: 1) आपको कॉपी-ऑन-राइट के रूप में अपडेट करना होगा। यदि आपकी प्रक्रिया अपडेट के दौरान क्रैश हो जाती है, तो DB स्थिति वापस आ जाएगी, फ़ाइल नहीं होगी। 2) ऐसा करने के लिए पुरानी फ़ाइल के कुछ प्रकार के कचरा संग्रह की आवश्यकता होती है। 3) DB में सब कुछ स्टोर करने का मतलब है कि DB के संस्करण और फाइलें बैकअप के बाद सिंक में हैं। 2 सप्ताह पहले अपने DB को अपने राज्य में पुनर्स्थापित करें ... अब उस समय फ़ाइलों की सामग्री क्या है?

— टिमोथी बाल्ड्रिज

@briddums - नहींं, क्योंकि SQL सर्वर सीधे फाइल सिस्टम में एकीकृत होता है और OS की ओर से उन फाइलों का प्रबंधन करता है। मैंने स्वयं उनका उपयोग नहीं किया है, लेकिन दस्तावेज़ इसे FILESTREAM की तरह दिखता है और इसके वंशज FileTables आपको दोनों दुनिया का सबसे अच्छा अनुदान देते हैं: फ़ाइलें डेटाबेस और संबंधित डेटा (आपको अपने डेटा को केंद्र में प्रबंधित करने की अनुमति) के बिना कसकर बाध्य करती हैं डेटाबेस।

— निक चामास

मैं निक से सहमत हूं। हमने अपने डिस्क + DB सिस्टम को FILESTREAM कॉलम से बदल दिया है और कभी भी पीछे मुड़कर नहीं देखा। यह अच्छा है कि FK के माध्यम से फाइल को अन्य तालिकाओं के साथ जोड़ने में सक्षम होना अच्छा है। तो आप वास्तव में कह सकते हैं "प्रत्येक व्यक्ति के पास एक या एक से अधिक एचआर डॉक्स उनसे जुड़े होने चाहिए", या ऐसा कुछ और।

— टिमोथी बाल्ड्रिज

Answer 3

हाँ, यह एक बुरा अभ्यास है।

DB पर प्रदर्शन प्रभाव:

• यदि आप SELECTकिसी भी BLOB कॉलम के साथ करते हैं , तो आप हमेशा डिस्क एक्सेस करेंगे, जबकि BLOB के बिना आपको सीधे रैम से डेटा प्राप्त करने का मौका मिलेगा (उच्च थ्रूपुट डीबी रैम में फिट टेबल के लिए अनुकूलित किया जाएगा);
• प्रतिकृति धीमी होगी, प्रतिकृति देरी में उच्च होगी, क्योंकि इसमें गुलाम को गुलामों को धक्का देना होगा। उच्च प्रतिकृति विलंब सभी प्रकार की दौड़ स्थितियों और अन्य सिंक्रनाइज़ेशन समस्याओं का कारण होगा, जब तक कि आप स्पष्ट रूप से इसे ध्यान में नहीं रखते हैं;
• DB बैकअप / पुनर्स्थापना में बहुत अधिक समय लगेगा;

गति लाभ - कोई नहीं ! जबकि कुछ पुराने फाइल सिस्टम लाखों फाइलों के साथ अच्छी तरह से निर्देशिकाओं को नहीं संभालेंगे, अधिकांश आधुनिक को कोई समस्या नहीं है और वास्तव में उसी तरह की डेटा संरचनाओं का उपयोग करें जैसे कि बीडीएस (आमतौर पर बी-ट्री)। उदाहरण के लिए ext4 (डिफ़ॉल्ट लिनक्स फाइल सिस्टम) Htree का उपयोग करता है ।

निष्कर्ष: यह आपके DB प्रदर्शन में बाधा उत्पन्न करेगा और फ़ाइल पुनर्प्राप्ति प्रदर्शन में सुधार नहीं करेगा।

इसके अलावा, जब से आप वेब एप्लिकेशन के बारे में बात कर रहे हैं - आधुनिक वेबसर्वर का उपयोग करके फाइलसिस्टम से सीधे स्थिर फ़ाइलों की सेवा करना, जो कि sendfile()syscall कर सकता है जबरदस्त प्रदर्शन सुधार है। यह निश्चित रूप से संभव नहीं है यदि आप DB से फाइलें ला रहे हैं। उदाहरण के लिए इस बेंचमार्क पर विचार करें , जिसमें Ngnix कम अंत वाले लैपटॉप पर 1000 समवर्ती कनेक्शन के साथ 25K req / s दिखा रहा है । उस तरह का भार किसी भी प्रकार के डीबी को भून देगा।

Comments

+1। अपने वेब सर्वर को वह करें जो वह सबसे अच्छा करता है, डिस्क से फाइल परोसता है। इसे PHP से मत पूछिए, क्योंकि PHP को MySQL इत्यादि पूछना होगा

— deizel

जब प्रोग्रामर सीखेंगे कि प्रदर्शन सब मायने नहीं रखता है?

— रीइनरएयरपोस्ट

@reinierpost: योग्य। शायद जब हम उदार कला की बड़ी कंपनियों को प्राप्त करते हैं ;-)

— vartec

@ बिलियन: आप ऐसा क्यों मानते हैं, कि आपके पास स्थिर और गतिशील सामग्री के लिए एक ही सर्वर होना चाहिए? सर्वर पर फ़ाइलों को सिंक्रनाइज़ करने के लिए, विशेष रूप से उस के लिए डिज़ाइन किए गए उपकरण हैं, जो डेटाबेस से बहुत अधिक कुशल हैं। फाइलरवर के रूप में डेटाबेस का उपयोग करना एक पेचकश के साथ एक कील को हथौड़ा करने की कोशिश करने जैसा है।

— 12 vartec

@ बिलियन: मैं मानता हूं कि कुछ "समाधान" हैं जहां यह काम करेगा, मैंने MySQL में छवियों के साथ काफी शौकिया PHP सेटअप देखे हैं। हालाँकि, इस तरह के सेटअप में एक DB कभी भी BLOB की सेवा देने वाले उच्च यातायात का समर्थन नहीं करेगा।

— वर्तक

Answer 4

मैं इसके बारे में व्यावहारिक होगा, और "अभी तक अनुकूलन न करें" सिद्धांत का पालन करें। समाधान करें जो इस समय समझ में आता है, और आपके पास विकास संसाधनों को ठीक से लागू करने के लिए है। बहुत सारी संभावित समस्याएं हैं । लेकिन जरूरी नहीं कि वे वास्तविक समस्याएं हों। उदाहरण के लिए, यदि आपके 100 उपयोगकर्ता हैं तो यह संभवतः एक समस्या नहीं होगी। यदि आपके पास 100,000 या 10,000,000 उपयोगकर्ता हैं, तो यह एक समस्या हो सकती है। लेकिन बाद के मामले में, सभी मुद्दों से निपटने के लिए अधिक विकास संसाधनों का एक आधार होना चाहिए।

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

मैं व्यक्तिगत रूप से डेटाबेस में डेटा को संग्रहीत करने का चयन करूंगा, लेकिन सुनिश्चित करें कि BLOBS को तब तक नहीं पढ़ा जाता है जब तक कि उन्हें वास्तव में आवश्यक न हो, अर्थात ब्लॉग वाले उन तालिकाओं पर कोई "SELECT * FROM ..." निष्पादित नहीं किया जाता है। और मैं यह सुनिश्चित करूंगा कि डेटा को डेटाबेस से बाहर ले जाना आसान हो जाए, अगर आपको प्रदर्शन समस्याएं आती हैं, तो फाइल सिस्टम में। उदाहरण के लिए फ़ाइल जानकारी को एक अलग फ़ाइल तालिका में संग्रहीत करें , इस प्रकार फ़ाइल जानकारी को अन्य व्यावसायिक संस्थाओं से दूर रखें।

यह मानते हुए कि आपके पास डेटाबेस में पढ़ी गई फ़ाइल का प्रतिनिधित्व करने के लिए एक फ़ाइल वर्ग है, तो बाद में इसे बाहर ले जाने का कोडिंग प्रभाव न्यूनतम होगा।

Comments

यह एक उत्कृष्ट सुझाव है। आपके पास जो समस्याएं हैं, उन्हें हल करना शुरू न करें।

— हैवी

Answer 5

माइक्रोसॉफ्ट ने कुछ साल पहले इस बारे में एक श्वेत पत्र जारी किया था। यह SqlServer पर केंद्रित है, लेकिन आपको वहां कुछ रोचक जानकारी मिल सकती है:

BLOB करने के लिए या BLOB करने के लिए नहीं? डेटाबेस या फाइलसिस्टम में बड़ी वस्तु संग्रहण?

उनके निष्कर्ष का एक बहुत संक्षिप्त संस्करण है:

NTFS फाइल सिस्टम और SQL सर्वर 2005 की तुलना करते समय, 256KB से छोटे BLOBS SQL सर्वर द्वारा अधिक कुशलता से नियंत्रित किए जाते हैं, जबकि NTFS BLMBS के लिए 1MB से अधिक बड़ा होता है।

मैं आपको सलाह दूंगा कि आप अपने विशेष उपयोग के मामले में कुछ छोटे परीक्षण लिखें। ध्यान रखें कि आपको कैशिंग प्रभावों से सावधान रहना होगा। (मैं पहली बार हैरान था कि मुझे डिस्क-टू-स्पीड मिली जो शारीरिक रूप से संभव से अधिक थ्रूपुट था ऐसा लगता है!)।

Comments

आपको पता होना चाहिए कि जब आप अधिक एकल निर्देशिका में ~ 100K फ़ाइलों को डालते हैं तो NTFS बहुत गलत तरीके से व्यवहार करना शुरू कर देता है। फ़ाइल का उपयोग काफी कम हो जाता है (कम से कम परिमाण का एक क्रम) और फ़ाइल के खुले संचालन में विफलता (स्पष्ट रूप से) बेतरतीब ढंग से शुरू होती है। मैंने विंडोज 2008 और विंडोज 7 सिस्टम पर इस प्रभाव का अनुभव किया है। जब मैंने कई निर्देशिकाओं के बीच फाइलों को फिर से वितरित किया, तो सब कुछ सामान्य हो गया। मुझे नहीं पता कि तब से स्थिति में सुधार हुआ है या नहीं।

— फारुशियो

Answer 6

डेटाबेस के बाहर फ़ाइलों को संग्रहित करने की पुरानी पारंपरिक ज्ञान अब धारण नहीं कर सकती है। सिद्धांत के रूप में, मैं गति पर अखंडता का समर्थन करता हूं, और एक आधुनिक DBMS के साथ, आप दोनों हो सकते हैं।

टॉम Kyte सहमत प्रतीत होता है :

मुझे उस डेटा को संग्रहीत करने के लिए कोई लाभ नहीं है जिसे मैं डेटाबेस के बाहर लंबे समय तक रखना चाहता हूं।

अगर यह डेटाबेस में है तो मैं कर सकता हूं

सुनिश्चित करें कि यह पेशेवर रूप से प्रबंधित है

को समर्थन

पुनर्प्राप्त करने योग्य (शेष डेटा के साथ)

सुरक्षित

स्केलेबल

मैं आसानी से हटाना (फ्लैशबैक) कर सकता हूं

मेरे पास ताला है

मैंने निरंतरता पढ़ी है ...

Answer 7

हाँ।

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

डेटाबेस से बाहर फाइलें सेव करने का मतलब है कि आपको डेटाबेस सर्वर की डिस्क से डेटाबेस सर्वर मेमोरी में डेटा कॉपी करना होगा, फिर डीबी सर्वर की मेमोरी से डीबी सर्वर के नेटवर्क पोर्ट में, फिर नेटवर्क से आपकी वेब सर्वर प्रक्रिया में, फिर से फिर से बाहर करना होगा। आउटगोइंग नेटवर्क कनेक्शन।

जब तक आपके पास वास्तव में अच्छा कारण नहीं है, तब तक फ़ाइल सिस्टम से स्थिर फ़ाइलों की सेवा करना हमेशा बेहतर होता है।

Comments

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

— maple_shaft

मेरी समझ यह है कि उपयोगकर्ता द्वारा अपलोड की गई फ़ाइलों की सेवा के बारे में प्रश्न है। "मैं वर्तमान में एक वेब एप्लिकेशन बना रहा हूं जो उपयोगकर्ताओं को फ़ाइलों को संग्रहीत करने और साझा करने की अनुमति देता है [...] यह मुझे लगता है कि फ़ाइलों को डेटाबेस में संग्रहीत करना [...]"। मुझे नहीं लगता है कि यह वास्तव में सुविधाजनक है कि डेटाबेस में बहुत सारे मल्टी-मेगाबाइट के साथ डीबी डंप करना आसान है। भी: हाँ, फाइलों से निपटना कठिन है; सिंकिंग, आर्काइविंग, सभी अधिक कठिन हैं। हालांकि, ऐसा नहीं है बहुत अधिक कठिन है, और अपने हर रात को बैकअप स्क्रिप्ट में कुछ लाइनें को बचाने के लिए ऑनलाइन प्रदर्शन का त्याग एक बड़ी गलती है।

— इवान पी।

Answer 8

प्रसिद्ध टॉम कायटे ने लिखा है कि वे (ओरेकल) ओरेकल डेटाबेस का उपयोग फाइल सर्वर के रूप में कर रहे हैं और यह पूरी तरह से ठीक काम कर रहा है, यहां तक ​​कि सामान्य फाइलसिस्टम, पूर्ण लेनदेन के साथ, कोई प्रदर्शन हानि और एकल बैकअप के साथ नहीं।

हां, लेकिन ध्यान दें, वे ओरेकल डीबी के निर्माता हैं, और किसी भी अन्य उपयोगकर्ता के लिए लागत मुद्दे हैं। फाइलों के भंडारण के लिए ओरेकल जैसे वाणिज्यिक डीबी का उपयोग करना महज अप्रभावी है।

हालाँकि, उदाहरण के लिए PostgreSQL के साथ, आप बस एक और DB उदाहरण केवल ब्लॉब स्टोरेज के लिए चला सकते हैं। आपके पास तब पूर्ण लेन-देन का समर्थन है। लेकिन ट्रांजेक्शनलिटी में डीबी स्पेस खर्च होता है। कई समवर्ती लेनदेन के लिए कई बूँद उदाहरणों को संग्रहीत करने के लिए डेटाबेस की आवश्यकता होती है। PostgreSQL पर यह सबसे दर्दनाक है, क्योंकि यह डेटाबेस लेन-देन के लिए किए गए ब्लूबस के डुप्लिकेट को संग्रहीत करता है, भले ही वे अब ज़रूरत न हों, जब तक कि VACUUM प्रक्रिया नहीं की जाती है।

फाइलसिस्टम स्टोरेज के साथ, दूसरी ओर, आपको बहुत ही केयरफुल होना चाहिए जब कोई व्यक्ति फ़ाइल को संशोधित करता है, क्योंकि लेनदेन को वापस रोल किया जा सकता है और फ़ाइल की प्रतिलिपि तब तक रखी जानी चाहिए जब तक कि पुराना संस्करण दिखाई न दे।

उस सिस्टम में जहां फ़ाइलें केवल जोड़ी जाती हैं और हटा दी जाती हैं, और फ़ाइलों तक लेन-देन की पहुंच कोई समस्या नहीं है, फ़ाइल सिस्टम संग्रहण IMHO सबसे अच्छा विकल्प होगा।

Comments

नमस्ते, जब आपने कहा था "फ़ाइल के भंडारण के लिए ओरेकल, केवल लागत अप्रभावी है", क्या होगा यदि हम पहले से ही अन्य गैर-फाइल डेटा के भंडारण के ओरेकल का उपयोग कर रहे हैं? क्या अब भी लागत अप्रभावी रहेगी?

— जिओ पेंग - ZenUML.com

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

— DocSalvager

Answer 9

आमतौर पर बड़े BLOB को एक अलग तालिका में संग्रहीत करना सबसे अच्छा है और अपने मुख्य तालिका में BLOB के लिए एक विदेशी कुंजी संदर्भ रखें। इस तरह, आप अभी भी डेटाबेस से फ़ाइल को पुनः प्राप्त कर सकते हैं (इसलिए आपको किसी विशेष कोड की आवश्यकता नहीं है) और आप बाहरी DB निर्भरता (DB और फाइल सिस्टम को सिंक में रखना, आदि) के आसपास की समस्याओं से बचते हैं, लेकिन आप केवल उस ओवरहेड को लाइक करते हैं यदि आप स्पष्ट रूप से उस तालिका में शामिल होते हैं (या एक अलग कॉल करते हैं)। 10MB बहुत बड़ा नहीं है, अधिकांश आधुनिक वाणिज्यिक डेटाबेस में कोई समस्या नहीं होगी। फाइलसिस्टम में फ़ाइल को स्टोर करने का एकमात्र कारण डेटाबेस बैंडविड्थ में कटौती करना है। यदि आपका डेटाबेस इन फ़ाइलों में बहुत फेरबदल करने जा रहा है, तो आपको वर्कलोड को विभाजित करने की आवश्यकता हो सकती है और केवल किसी प्रकार के फ़ाइल डिस्क्रिप्टर को स्टोर करना होगा। तब आपके पास किसी अन्य सर्वर से फ़ाइल लोड करने के लिए एक अलग कॉल हो सकती है,

Answer 10

आप इस समस्या में से कुछ में भाग सकते हैं:

• एक ऐसा करना SELECT *जिसमें बड़ी बूँद के साथ पंक्ति शामिल होती है, भले ही आपको बूँद की ज़रूरत न हो (बेशक आपको एक विशिष्ट चयन करना चाहिए, लेकिन कभी-कभी इस तरह से आवेदन लिखे जाते हैं)
• बैकअप करने में अधिक समय लग सकता है। अपनी आवश्यकताओं के आधार पर आपको बैकअप के समय के लिए अपनी तालिकाओं को लॉक करने की आवश्यकता हो सकती है, इसलिए आप अपना बैकअप समय कम रखना चाहते हैं
• बहाल करने में भी अधिक समय लगेगा।
• यदि आप अंतरिक्ष से बाहर भागते हैं, तो आपको इस समस्या को हल करने के लिए कुछ तरीके (शायद पूरे डेटाबेस को एक नए सर्वर पर ले जाने) के बारे में सोचना होगा। फ़ाइल सिस्टम पर फ़ाइलों को संग्रहीत करना आप हमेशा एक और हार्ड ड्राइव को माउंट कर सकते हैं और सॉफ्ट लिंक सेट कर सकते हैं।
• बस डिबगिंग या अन्य जानकारी के लिए एक फ़ाइल देखना उतना आसान नहीं है। इसमें ऐसी स्क्रिप्ट भी शामिल हैं, जिनकी डेटाबेस तक पहुंच नहीं हो सकती है, लेकिन विभिन्न फ़ाइलों से कुछ जानकारी की आवश्यकता होती है।

निश्चित रूप से आपको कुछ लाभ भी मिलेंगे:

• डेटा और फ़ाइल मेनस का बैकअप लेना वे सिंक में हैं
• डेटाबेस को जाने बिना फ़ाइल को हटाना संभव नहीं है
• आपको डिस्क से फ़ाइल पढ़ने की ज़रूरत नहीं है, लेकिन इसे एक sql स्टेटमेंट में कर सकते हैं
• आप डेटाबेस डाउनलोड कर सकते हैं, अपने विकास के माहौल में डंप को शामिल कर सकते हैं और सभी निर्भरताएं वहीं पर हैं

व्यक्तिगत रूप से मैं ऐसा नहीं करता क्योंकि मुझे पेशेवरों की तुलना में विपक्ष बहुत भारी लगता है। लेकिन जैसा कि ऊपर कहा गया है यह पूरी तरह से आपके उपयोग के मामले और इस तरह पर निर्भर करता है।

Answer 11

कुछ Enterpirse Content Management Systems, जैसे SiteCore, एक डेटाबेस का उपयोग पेज डेटा स्टोर करने के लिए और दूसरा डेटाबेस फ़ाइलों को स्टोर करने के लिए कर रहे हैं। वे MS SQL सर्वर का उपयोग कर रहे हैं।

Comments

यह पूछे गए प्रश्न का उत्तर कैसे देता है?

— गनत

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

— 20

Answer 12

व्यावहारिक कार्यान्वयन के लिए, यहाँ आप क्या चिंता कर सकते हैं:

लाभ:

1. सभी फ़ाइल सामग्री निश्चित रूप से आपकी तालिका के साथ सिंक्रनाइज़ हैं। जैसा कि ऊपर टिप्पणी में कहा गया है, डेटा का बैकअप लेना पूरी तरह से सुविधाजनक है क्योंकि आपको फ़ाइल सिस्टम के साथ डेटा को सिंक्रनाइज़ रखने की आवश्यकता नहीं है।
2. कोडिंग से, आप सीधे SQL सेलेक्ट से फाइल कंटेंट प्राप्त कर सकते हैं।
3. किसी क्वेरी से, आप SQL सामग्री से फ़ाइल सामग्री या उसके आकार को स्पष्ट रूप से फ़िल्टर कर सकते हैं।

downsides:

1. किस संरचना के डेटाबेड की तुलना में शब्दार्थ समान है लेकिन फ़ाइल सामग्री संग्रहीत नहीं करता है, तो आप डेटाबेस क्वेरी करते समय मौलिक रूप से अधिक मेमोरी का उपभोग करते हैं।
2. ऑटो बैकअप प्रदर्शन की समस्या पैदा कर सकता है लेकिन ज्यादा नहीं। आइए कल्पना करें कि आपका डेटाबेस सर्वर हर 6 घंटे में चीजों का बैकअप ले रहा है और आपके पास जो डेटाबेस हैं वे प्रति रिकॉर्ड 10-एमबी फाइल जमा कर रहे हैं। वह परिदृश्य वह नहीं है जो आप चाहते हैं।