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

Question

बाइनरी फ़ाइलों को संग्रहीत करने के लिए सबसे अच्छी जगह क्या है जो आपके डेटाबेस में डेटा से संबंधित हैं? अगर आप:

1. डेटाबेस में एक बूँद के साथ स्टोर करें
2. डेटाबेस में एक लिंक के साथ फाइलसिस्टम पर स्टोर करें
3. फाइलसिस्टम में स्टोर करें लेकिन सामग्री के हैश का नाम बदलें और डेटाबेस पर हैश को स्टोर करें
4. कुछ मैंने सोचा नहीं है

(1) के फायदे (दूसरों के बीच) हैं कि लेनदेन की परमाणुता संरक्षित है। लागत यह है कि आप नाटकीय रूप से भंडारण (और संबंधित स्ट्रीमिंग / बैकअप) आवश्यकताओं को बढ़ा सकते हैं

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

संपादित करें:

ऐसा लगता है कि कुछ आरडीबीएमएस ने अपने व्यक्तिगत तरीकों से इसे कवर किया है - मुझे यह जानने में दिलचस्पी होगी कि दूसरे कैसे करते हैं - और विशेष रूप से पोस्टग्रेज के समाधान में

Comments

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

— मैरियन

Answer 1

1. डेटाबेस में एक बूँद के साथ स्टोर करें

   एक नुकसान यह है कि यह आपके डेटाबेस फ़ाइलों को अपने मौजूदा सेट अप के साथ बैकअप लेने के लिए काफी बड़ा और संभवतः बहुत बड़ा बनाता है। एक लाभ अखंडता और परमाणु है।

2. डेटाबेस में एक लिंक के साथ फाइलसिस्टम पर स्टोर करें

   मैं ऐसा करने वाली भयानक आपदाओं में आया हूं, और यह मुझे डराता है कि लोग इसका सुझाव देते रहें। कुछ आपदाओं में शामिल हैं:

   • एक विशेषाधिकार प्राप्त उपयोगकर्ता जो फ़ाइलों को पुनर्व्यवस्थित करेगा और अक्सर DB में पथों के बीच के लिंक को तोड़ देगा और जहां वे अब हैं (लेकिन किसी तरह यह मेरी गलती बन गई)।
   • जब एक सर्वर से दूसरे में जा रहा है, तो कुछ फाइलों का स्वामित्व पुरानी मशीन के प्रशासक खाते (जो पुरानी वेबसाइट पर चल रहा था) के लिए SID के रूप में खो गया था, डोमेन का हिस्सा नहीं था और इसलिए प्रतिलिपि की गई फ़ाइलों में ACL थे जो कर सकते थे इस प्रकार उपयोगकर्ता / पासवर्ड / डोमेन लॉगिन प्रॉम्प्ट के साथ उपयोगकर्ताओं को प्रस्तुत करने का समाधान नहीं किया जाना चाहिए।
   • रास्तों में से कुछ से अधिक समय तक 256 से पात्रों किया जा रहा समाप्त हो गया C:\सभी तरह के .docऔर NT के सभी संस्करणों नहीं लंबे रास्तों से निपटने के लिए सक्षम थे।

3. फाइलसिस्टम में स्टोर करें लेकिन सामग्री के हैश का नाम बदलें और डेटाबेस पर हैश को स्टोर करें

   पिछली बार मैंने जिस पर काम किया था वह उपरोक्त परिदृश्यों के बारे में मेरी व्याख्या के आधार पर किया था। उन्होंने सोचा कि यह बड़े डेटाबेस के साथ अनुभव प्राप्त करने में संगठन की अक्षमता के बीच एक समझौता था (लगभग 40G से बड़ा कुछ भी "बहुत बड़ा" होने के लिए ठहराया गया था), बड़ी हार्ड ड्राइव खरीदने में असमर्थता, और अधिक आधुनिक खरीद करने में असमर्थता समाधान, और जोखिम # 1 & # 3 से दूर होने की आवश्यकता जिसे मैंने ऊपर पहचाना।

मेरी राय है कि DB में एक ब्लॉब के रूप में भंडारण एक बेहतर समाधान है और बहु-सर्वर परिदृश्य में अधिक स्केलेबल है, खासकर विफलता और उपलब्धता चिंताओं के साथ।

Comments

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

— फिल लेलो

मेरे पास एक बार एक मुद्दा था जहां सैकड़ों मेगाबाइट प्रत्येक पंक्ति में दिन में हजारों बार लिखे गए थे । वे DB में एक GZIP फ़ाइल को 10000 सर्वर के लिए एक बाइनरी के रूप में संग्रहीत कर रहे थे, लेकिन एक बग पेश किया गया था जहां हर सर्वर ने प्रत्येक सर्वर के लिए जानकारी दर्ज की थी, प्रति अलर्ट। यह बहुत घटिया था। उस घटना के बाद, मैं 'नो (MAX) डेटा प्रकारों के बारे में अडिग हो गया जब तक कि यह अत्यंत न्यायसंगत नहीं है।'

— अली रज़ेगी

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

— टेक

Answer 2

पूर्ण डेटा अखंडता के लिए नंबर 1। यदि आप डेटा गुणवत्ता की परवाह नहीं करते हैं तो अन्य विकल्पों का उपयोग करें। यह इत्ना आसान है।

अधिकांश RDBMS में वैसे भी BLOBs (जैसे SQL सर्वर फाइलस्टार) के भंडारण के लिए अनुकूलन हैं

Comments

इसके बारे में (3) विशेष रूप से क्या डेटा अखंडता को खतरे में डालता है? (आप अपने व्यवहार एपीआई मिल कल्पना करते हुए)

— जैक डगलस

@JackPDouglas: आपके पास हैश है जो सही डेटा नहीं है और अभी भी डैट्स अखंडता के लिए एक बाहरी निर्भरता है

— gbn

@JackPDouglas इस बात की भी संभावना है कि सर्वर एडमिन और DBA अलग-अलग टीमें हैं, संबद्ध जोखिम के साथ कि फाइलें गलती से डिलीट हो जाती हैं, या बैक-अप नहीं होती क्योंकि उन्हें अस्थायी फाइल के रूप में समझा जाता है।

— फिल लेलो

Answer 3

यदि ओरेकल के लिए जा रहे हैं, तो dbfs और Secure Files पर एक नज़र डालें।

सुरक्षित फ़ाइलें यह सब कहती हैं, अपने सभी डेटा को डेटाबेस में सुरक्षित रखें। यह lobs में आयोजित किया जाता है। सिक्योर फाइल्स लॉब्स का एक आधुनिक संस्करण है, जिसे सक्रिय किया जाना चाहिए।

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

अधिक लाभ हैं: उपलब्धता, बैकअप, वसूली, सभी अन्य संबंधपरक डेटा के अनुरूप हैं।

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

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

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

Answer 4

मुझे लगता है कि यहां सही उत्तर आपके आवेदन पर बहुत कुछ निर्भर करता है, और वे दस्तावेज कितने महत्वपूर्ण हैं।

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

हालाँकि, कई अनुप्रयोग हैं जहाँ मेरा मानना ​​है कि विपरीत निर्णय उचित है।

हेल्पडेस्क सिस्टम और विकी-टाइप सिस्टम वे हैं, जहां मुझे लगता है कि डेटा को डेटाबेस से बाहर रखने के लिए बहुत मायने रखता है । मेरा मानना ​​है कि कुछ, जीरा की तरह, वास्तव में यह चुनने का विकल्प प्रदान करते हैं कि आप दस्तावेजों को इनलाइन स्टोर करना चाहते हैं या नहीं।

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

मैं व्यक्तिगत रूप से कुछ ही मिनटों में (आमतौर पर कम महत्वपूर्ण) दस्तावेजों के साथ एक टिकटिंग प्रणाली को ऑनलाइन वापस लाना पसंद करूंगा, मेरे "यह टूट गया है और सीटीओ मेरी गर्दन को नीचे कर रहा है" बढ़ाने के बजाय आरटीओ को बहाल करने के लिए और रीप्ले लॉग एक बहुत बड़े बैकअप से।

दस्तावेजों को अलग रखने के अन्य लाभ हैं।

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

मुझे लगता है कि # 2 और # 3 का एक संकर संयोजन चतुर हो सकता है। मूल फ़ाइलनाम रखें, लेकिन दस्तावेज़ के हैश / चेकसम की गणना करें और संग्रहीत करें, ताकि आपके पास कुछ संदर्भ बिंदु हों जो किसी को स्थानांतरित करने या फ़ाइल का नाम बदलने की स्थिति में पुनर्प्राप्ति में सहायता करेंगे।

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

Answer 5

यह मत करो।

वहाँ वास्तव में डेटाबेस में संग्रहीत फ़ाइलों को रखने के लिए एक उल्टा नहीं है।

क्या यह पहले से ही अजीब और गड़बड़ महसूस नहीं करता है जब आप अपने बारे में सोचते हैं:

क्या मुझे एक डेटाबेस या एक फाइल सिस्टम में फाइल स्टोर करनी चाहिए ?

इससे भी बेहतर है, इसे जोर से कहें।

तथ्यों पर:

डेटाबेस का उपयोग करना

" PROS " ... लेकिन काफी नहीं :

• "एटोमिसिटी" जो सही है लेकिन यह एक दोहरी धार वाली तलवार है। क्योंकि यह इसके साथ साथ कान भी पीटता है।
• अखंडता। ऊपर की तरह।

मैं वास्तव में पक्षपाती नहीं होना चाहता, लेकिन मुझे नहीं लगता कि जोड़ने के लिए अधिक है। यदि आप इसके बारे में सोचते हैं तो यह नियम वास्तव में इतने महान नहीं हैं।

अगर मैं नीचे कुछ टिप्पणी भूल गया, इस बीच नीचे पढ़ते रहें।

कान्स:

• नौकरी के लिए गलत उपकरण
• बनाए रखने के लिए कठिन
• धीरे
• प्रति उपयोगकर्ता सैकड़ों MB / गीगाबाइट डेटा संग्रहीत करने के बारे में भूल जाएं ।
• तेजी से बढ़ती साइटों का समर्थन एक बुरा सपना होगा।
• बहाल करना / हिलाना भी चूसना होगा।

फाइलसिस्टम का उपयोग करना

पेशेवरों:

• राह आसान बनाए रखने के लिए
• उपवास
• डेटाबेस बैक अप का इससे कोई लेना-देना नहीं है
• संभवतः अधिक पोर्टेबिलिटी *

कान्स :

• कोई नहीं *

*ठीक छाप

अभी तुम अपने आप से पूछ रहे हो, तुम पर पकड़ मतलब कोई विपक्ष है ?! कैसे?

यहां सबसे बड़ी गलती यह है कि लोग हथौड़े से एक पेंच कसने की कोशिश कर रहे हैं।

मुख्य कारण और मैं केवल यह कहने के लिए कहूंगा कि यह फ़ाइल लिंक के कारण है ।

यह एक समस्या है जिसे डेटाबेस हल करने के लिए नहीं है। यदि आप इसके बारे में सोचते हैं तो यह मूर्खतापूर्ण भी लगता है।

"डेटाबेस मेरी फ़ाइल लिंकिंग समस्याओं को ठीक करेगा।"

जब वास्तविकता में, तार्किक रूप से आवेदन को वास्तव में लिंक को संभालने और सेवा करने का प्रभारी होना चाहिए ।

एक तरकीब:

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

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

इसे लागू करने के तरीके के रूप में इस उत्तर के दायरे से परे है, लेकिन आप एक सामान्य उदाहरण पर एक नज़र डाल सकते हैं, जो निश्चित रूप से सबसे अधिक उपयोग की जाने वाली वेब भाषा (PHP) है:

https://github.com/symfony/Routing

https://github.com/kriswallsmith/assetic

ये दोनों एक साथ वास्तव में शक्तिशाली हैं।

Comments

आप इस में रुचि हो सकती: research.microsoft.com/apps/pubs/default.aspx?id=64525 पता चलता है कि डेटाबेस में धब्बे भंडारण वास्तव में फाइल सिस्टम में की तुलना में तेजी है (माइक्रोसॉफ्ट द्वारा एक शोध धब्बे के कुछ आकार के लिए कम से कम)। यह मेरे परीक्षणों के अनुरूप है जिसमें पता चला है कि मध्यम आकार की बूँदें (<~ 1MB) के लिए जैसे पोस्टग्रैज़ भी एक फाइल सिस्टम की तुलना में तेज़ है। ओरेकल के लिए यह उसी प्रदर्शन के बारे में है, लेकिन मैंने अभी तक नए सुरक्षित भंडारण प्रारूप का परीक्षण नहीं किया है (लेकिन उनका दावा है कि यह पुराने भंडारण प्रारूप की तुलना में तेज है)

— a_horse_with_no_name

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

— Tek

Answer 6

मैं यहां अपने अनुभव को ट्रेडऑफ के रूप में जोड़ना चाहता हूं। PostgreSQL में, कम से कम, प्रदर्शन प्रभाव db सर्वर के संदर्भ में काफी कम हैं। बड़े ब्लब्स को अलग-अलग फ़ाइलों में संग्रहीत किया जाता है, न कि मुख्य ढेर तालिकाओं में ताकि उन्हें संचालन के तरीके से बाहर निकालने के लिए जो बड़ी संख्या में रिकॉर्ड की गिनती कर सकें। अन्य डीबीएस भी कुछ ऐसा ही कर सकते हैं।

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

प्रमुख नुकसान वह नहीं है जिसे मैंने ऊपर कवर किया है, और यह फ्रंट-एंड पर मेमोरी उपयोग है। मुझे ठीक से पता नहीं है कि हर db इसे कैसे संभालता है इसलिए यह कार्यान्वयन पर निर्भर हो सकता है लेकिन PostgreSQL के लिए, डेटा एक एस्केप ASCII स्ट्रिंग (संभवतः हेक्साडेसिमल, संभवतः इनबिल्ड एस्केप के साथ) के रूप में आता है। इसके बाद आगे के अंत में बाइनरी में परिवर्तित होना होगा। ऐसा करने के लिए मैंने जो कई चौखटे देखे हैं, उनमें मूल्य (संदर्भ के रूप में नहीं) को पारित करना और फिर उसके आधार पर एक नया बाइनरी स्ट्रिंग का निर्माण शामिल है। मैंने गणना की कि ऐसा करने के लिए पर्ल का उपयोग करना कई बार मूल बाइनरी की स्मृति को पूरा करने के लिए समाप्त होता है।

निर्णय: यदि फ़ाइलें केवल कभी-कभी एक्सेस की जा रही हैं तो मैं db में संग्रहीत करूंगा। यदि उन्हें बार-बार और बार-बार एक्सेस किया जा रहा है, तो कम से कम PostgreSQL के साथ, मुझे लगता है कि लागत लाभ को कम करती है।

Answer 7

दिन में वापस, Microsoft डेटाबेस में छवियों (और इसी तरह के बूँद डेटा प्रकार) को संग्रहीत करने की क्षमता को देखकर सम्मोहित हो गया। SQL Server 2000 की एक शांत नई विशेषता थी (मुझे पूरा यकीन है कि यह 2000 था, 7.0 नहीं था) और कई लोग बैंडवागन पर कूद गए।

डेटाबेस में ब्लॉब्स रखने के फायदे और नुकसान हैं:

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

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

SQL सर्वर 2008 ने फ़ाइल स्ट्रीमिंग की शुरुआत की। डेटाबेस में फ़ाइलों के लिए संकेत होते हैं, फाइलें सर्वर पर रहती हैं, डेटाबेस में नहीं, लेकिन जब आप डेटाबेस का बैकअप लेते हैं तो फाइलें भी बैकअप होती हैं।

आपके बैकअप काफी बड़े हो सकते हैं, लेकिन आप अनाथ फ़ाइलों / दस्तावेजों / ब्लॉब्स / छवियों के साथ समाप्त नहीं होते हैं।

मेरी व्यक्तिगत प्राथमिकता डेटाबेस स्टोर पॉइंटर्स / नेटवर्क स्थानों को देना है, और एक फ़ाइल सर्वर को फाइलों को संभालने देना है। फ़ाइल सर्वर वैसे भी ऐसे कार्यों के लिए बेहतर अनुकूलित हैं।

Comments

इस बात पर कभी ध्यान न दें कि यदि आप सर्वर के मालिक नहीं हैं, तो आप डेटाबेस स्पेस बनाम फ़ाइल स्पेस के लिए प्रति एमबी एक बहुत अधिक का भुगतान करने जा रहे हैं। इसके अलावा डिस्क पर फ़ाइल होने से समस्या निवारण में बहुत आसान हो जाता है - आप SELECT image FROM tableएसएसएमएस में कैसे करते हैं और यह सत्यापित करते हैं कि सही छवि है?

— हारून बर्ट्रेंड

Answer 8

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

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

• डेटाबेस में फ़ाइलों के लिए कोई फ़ाइलहैंड्स नहीं । इसका क्या मतलब है?

  • प्रोग्रामर-टॉक: आप तलाश नहीं कर सकते ( fseek), अतुल्यकालिक पहुंच ( asyncioया epoll) के साथ संसाधन का प्रबंधन करने की कोई क्षमता नहीं है , कोई नहीं है sendfile(आपको कर्नेल स्थान से प्रतिलिपि सहेजना)।

  • व्यावहारिक अनुप्रयोग: HTTP2 / 3 पर ग्राहक को वीडियो या चित्र भेजना चाहते हैं? यदि यह डेटाबेस में है, तो आपको पहले इसे क्वेरी करना होगा। जो भी क्वेरी उस फ़ाइल को लौटाती है, उसके लिए आपको अगले चरण के लिए स्थानांतरित होने से पहले पूरी क्वेरी के लिए इंतजार करना होगा । वेब सर्वर की तुलना में एक अलग सर्वर पर एक rdbms के साथ स्थापित उत्पादन में, आपको सबसे पहले फ़ाइल को पूरी तरह से rdbms से वेबसर्वर में स्थानांतरित करने के बजाय इसे स्थानांतरित करना होगा। हालाँकि, अगर ट्रांसफ़ॉर्मेशन लेयर ने फाइल-सिस्टम एब्स्ट्रैक्शन (जो NFS भी सपोर्ट करता है) प्रदान किया है, तो आप फाइल के माध्यम से आधे रास्ते की तलाश कर सकते हैं और तुरंत फाइल को जरूरत से ज्यादा बफर किए बिना क्लाइंट को वापस स्ट्रीमिंग शुरू कर सकते हैं। यह वेबसर्वर द्वारा नियमित रूप से किया जाता हैnginx , Apache , PureFTP, और ProFTP।

• RDBMS पर डबल कॉपी। इस तथ्य से कि यह डेटाबेस में है, आप संभवतः इसे दो बार लिखेंगे। एक बार राइट-फॉरवर्ड लॉग (वाल) में, और फिर फिर से टेबलस्पेस में।

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

• फ़ाइल को पढ़ें और क्वेरी को धीमा करने के लिए स्थानांतरण करें यदि फ़ाइल स्वयं एक पंक्ति पर संग्रहीत है जिसे आपको क्वेरी करने की आवश्यकता है, तो पूरी पंक्ति को या तो फ़ाइल के हस्तांतरण के लिए इंतजार करना होगा, या आपको दो अलग-अलग क्वेरी जारी करनी होगी ।

• डीबी-क्लाइंट पर मेमोरी का उपयोग । DB- क्लाइंट (libpq, jdbc, odbc, freetds, आदि) या इस तरह संभवतः स्मृति में क्वेरी बफर होगी। जब वह इन-मेमोरी बफर समाप्त हो जाता है, तो यह डिस्क-बफर शुरू कर सकता है या इससे भी बदतर यह डिस्क को पृष्ठांकित करने के लिए कर्नेल पर वापस गिर सकता है।

• क्वेरी-थ्रॉटलिंग कई डेटाबेस प्रश्नों को मारने और रीप करने की क्षमता प्रदान करते हैं जब वे समय या संसाधनों के रूप में बहुत अधिक लेते हैं। ध्यान रखें कि फाइल ट्रांसफर किसी भी कार्यान्वयन में मद में नहीं किया जाएगा। क्या उस क्वेरी को 3-सेकंड के बाद मार दिया गया था? या इसे 1 सेकंड का समय लगा और बैकएंड ने 2-सेकंड एक फ़ाइल को स्थानांतरित करने में खर्च किया? न केवल "आइटम किए गए", आप प्रभावी रूप से यह बताने जा रहे हैं कि 99.9% क्वेरीज़ 1 केबी वापस आने पर कितना समय लेना चाहिए और दूसरा 1 जीबी देता है?

• नो-कॉपी-ऑन-राइट या डे-डुप्लीकेशन एक्सएफएस और बीटीआरएफएस कॉपी-ऑन-राइट और डी-डुप्लिकेट को पारदर्शी तरीके से समर्थन करते हैं। इसका मतलब यह है कि हर जगह एक ही तस्वीर होना या इसकी दूसरी प्रति की आवश्यकता को पारदर्शी रूप से फाइल सिस्टम द्वारा नियंत्रित किया जा सकता है । हालाँकि, यदि फ़ाइल स्वयं से खड़ी नहीं है, और या तो एक पंक्ति में है या किसी स्टोर में है तो फ़ाइल सिस्टम संभवतः इसे समाप्त करने में असमर्थ है।

• ईमानदारी बहुत सारे लोग यहां हैं अखंडता के बारे में बात कर रहे हैं। आपको क्या लगता है कि फ़ाइल-सिस्टम के भ्रष्टाचार का पता लगाने में बेहतर है, एक ऐसा अनुप्रयोग जो फाइल सिस्टम या फाइल सिस्टम की मुख्य उपयोगिताओं का उपयोग करता है? एक पंक्ति में, या आउट-ऑफ-लाइन और किसी भी फाइल सिस्टम भ्रष्टाचार को डेटाबेस में संग्रहीत किया जाएगा। xfs_repairजब आपके पास फाइलसिस्टम या हार्ड ड्राइव भ्रष्टाचार है, तो ठीक होने में बहुत अच्छा है और अगर यह विफल हो जाता है तो डेटा फॉरेंसिक करना बहुत आसान हो जाएगा।

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

अपवाद

डेटाबेस में फ़ाइलें संग्रहीत करने के कुछ मान्य उपयोग मामले हैं,

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

mitigations

• कुछ डेटाबेस में "बाह्य रूप से प्रबंधित संसाधन" की धारणा होती है, जहां डेटाबेस डिस्क पर निजी रूप से फ़ाइल का प्रबंधन करता है जैसे

  • लार्ज ऑब्जेक्ट इन्फ्रास्ट्रक्चर के माध्यम से PostgreSQL लेनदेन की अवधि के लिए एक संसाधन के लिए एक फ़ाइलहैंडल प्रदान करता है।

  • SQL सर्वर 2017 का फ़िलेस्ट्रीम इन्फ्रास्ट्रक्चर एक अस्थायी पहुँच प्रदान करता है जो लेन-देन की अवधि तक रहता है जिसका उपयोग आप फ़ाइल पथ को प्राप्त करने और फ़ाइल हैंडल को खोलने के लिए कर सकते हैं।

  • Oracle प्रदान करता है BFILE(इसका आंतरिक LOB सामान से कोई लेना-देना नहीं है जिसे कहा जाता हैSecureFile

• कुछ डेटाबेस बड़ी द्विआधारी वस्तुओं को ऑरेकल सिक्योरफाइल की तरह आउट-ऑफ-लाइन या स्टोर कर सकते हैं। यह आपको फ़ाइल को फिर से लिखे बिना, पंक्ति को अद्यतन करने की अनुमति देता है।

• Oracle जैसे कुछ डेटाबेस अपने MVC को एक वाल लॉग के बिना करते हैं और फ़ाइल को डबल-लिखने की ज़रूरत नहीं है।

• कुछ डेटाबेस, जैसे SQL सर्वर और ओरेकल फाइल को "हैंडल" करने की क्षमता प्रदान करते हैं, कभी भी फाइल को हैंडल किए बिना। यह डेटाबेस क्वेरी से अलग कनेक्शन पर चल भी सकता है और नहीं भी। लेकिन यहाँ कुंजी यह है कि जब आप फ़ाइल को (सिद्धांत में) स्ट्रीम कर सकते हैं , तो मैं उस सुविधा का उपयोग करने वाले प्रदाता द्वारा बनाए गए किसी भी उत्पाद का कोई सबूत नहीं ढूंढ सकता। उदाहरण के लिए, NGINX / Apache पुल आपको ऐसा करने की अनुमति देने के लिए कहां है?

• Oracle आंतरिक-LOB स्टोरेज (SecureFile) के माध्यम से वैकल्पिक समर्पण, संपीड़न और एन्क्रिप्शन प्रदान करता है।

निष्कर्ष

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

इसे सरल रखें, और सामान्य नियम फाइलों को डीबी से बाहर रखें ।

उपाय

आपको कई किरायेदारों और उपयोगकर्ताओं के लिए प्रभावी ढंग से काम करने के लिए इस तरह से फाइलों को कैसे संग्रहीत करना चाहिए या एक फाइल सिस्टम को अमूर्त करना चाहिए? मैं फ़ाइल सामग्री को हैशिंग के लिए आंशिक हूँ। यह इन दिनों बहुत आम है और अच्छी तरह से काम करता है।

Answer 9

यद्यपि यह आंशिक रूप से अनुप्रयोग / पर्यावरण (लोगों को शामिल) पर निर्भर करता है, मैं बूँद के लिए जाऊंगा।

डेटाबेस में सब कुछ रखने का मतलब है कि फ़ाइल डेटा के लिए प्रतिकृति काम करती है। आपको FS फ़ाइलों को सिंक्रनाइज़ करने के लिए एक अलग तंत्र की आवश्यकता होगी।

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

यह मानकर कि हमने कई उपयोगकर्ताओं / एप्लिकेशन को अलग-अलग अनुमतियों के साथ प्राप्त किया है, तो किसी भी फाइल सिस्टम स्टोरेज से DB और FS एक्सेस अधिकारों में अंतर का अवसर मिलता है।

यदि मैं समझ में आता है, तो मुझे BLOB स्टोरेज को परिष्कृत करने पर विचार करना होगा। यदि आपको 20Mb BLOB में से केवल 512 बाइट्स की आवश्यकता है, तो इस सेक्टर की तरह पहुंच एक वास्तविक वरदान है, खासकर यदि आप दूरस्थ ग्राहकों के साथ काम कर रहे हैं (और फिर से, एक आंशिक अद्यतन बहुत कम प्रतिकृति ट्रैफ़िक बनाता है)।

Answer 10

मेरा वोट न तो होगा। डेटा को अमेज़ॅन S3 या माइक्रोसॉफ़्ट की CDN जैसी प्रणाली में संग्रहीत करें और डेटाबेस में उस URL को संग्रहीत करें।

इस तरह से आपको डेटा से निपटने के लिए राक्षस आकार डेटाबेस के बिना हमेशा सुलभ होने की विश्वसनीयता मिलती है।

Answer 11

पोस्टग्रेज के लिए:

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

Answer 12

Ms SQL सर्वर और फ़ाइलों की एक बड़ी संख्या का मेरा अनुभव साझा करें। हम फाइल सर्वर पर फाइल सेव करते हैं। डेटाबेस में दो टेबल हैं, फाइल फोल्डर के लिए एक और एक्सेस क्रेडेंशियल्स, फाइलनाम के लिए एक। डेटाबेस और फ़ाइलों को बनाए रखना आसान है। आप आसानी से फ़ाइलों को स्थानांतरित कर सकते हैं यहां तक ​​कि सर्वरों को भी पार कर सकते हैं, बस फ़ोल्डर्स तालिका को संशोधित करने की आवश्यकता है।