क्या आप डेटाबेस में या फ़ाइल सिस्टम में बाइनरी डेटा स्टोर करेंगे?

Question

यह एक प्रश्न है जो पहले से पूछा गया है (large-text-and-images-in-sql) लेकिन मुख्य रूप से डेटा के लिए जो बदलेगा। मेरे मामले में डेटा संग्रहीत किया जाएगा और कभी नहीं बदला जाएगा। सब कुछ एक साथ रखने के लिए बस समझदार लगता है।

क्या कोई कारण है कि मुझे डेटाबेस में स्थिर बाइनरी डेटा स्टोर नहीं करना चाहिए?

मान लीजिए कि यह एक समझदार बात है, क्या अलग-अलग तालिकाओं में ऐसे डेटा को संग्रहीत करने के कोई फायदे हैं? (अब आप महसूस कर सकते हैं कि मैं डीबी विशेषज्ञ नहीं हूं ...)

स्पष्ट करें: शायद 10-20 से अधिक उपयोगकर्ता नहीं होंगे लेकिन ये अमेरिका और ब्रिटेन में होंगे। द्विआधारी डेटा किसी भी मामले में स्थानांतरित किया जाना होगा।

Answer 1

डीबी में डेटा संग्रहीत करने का लाभ डीबी सुरक्षा तंत्र का लाभ ले रहा है और रखरखाव लागत को कम करना (बैकअप, ...)। इसका नुकसान डीबी लोड और उपभोग कनेक्शन बढ़ रहा है (जो प्रति कनेक्शन लाइसेंस प्राप्त डेटाबेस सर्वर के लिए महंगा हो सकता है)। यदि आप SQL Server 2008 का उपयोग कर रहे हैं, FILESTREAM एक अच्छा विकल्प हो सकता है।

वैसे, वेब ऐप्स (या डेटा को स्ट्रीम करने की आवश्यकता हो सकती है) के लिए, आमतौर पर डीबी के बाहर डेटा स्टोर करने के लिए अधिक समझदार होता है।

Answer 2

यदि आप ब्लॉबर्स संग्रहीत कर रहे हैं तो सबसे बड़ा नुकसान स्मृति खपत है। क्या आप कल्पना कर सकते हैं कि एक्स से * प्रत्येक में 45k छवि के साथ हजारों रिकॉर्ड के लिए क्या होगा?

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

Answer 3

क्या यह वही नहीं है जो LOBs या CLOBs या .... डिज़ाइन किए गए थे?

हमने सीएलओबी का उपयोग एक प्रमुख एयरलाइन सिस्टम के लिए क्रेडिट कार्ड कार्ड लेनदेन के बड़े एन्क्रिप्शन स्टोर करने के लिए किया था।

मेमोरी खपत हालांकि आपका सबसे बड़ा अपराधी है।

HTH

चियर्स,

Answer 4

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

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

मुझे नहीं लगता कि लोगों को पहले स्थान पर select * प्रश्नों का उपयोग करना चाहिए। आप जो करते हैं वह डेटा प्राप्त करने के दो तरीके प्रदान करता है, एक विधि सारांश जानकारी देता है, दूसरा ब्लॉब वापस कर देगा। मैं कल्पना नहीं कर सकता कि आपको एक बार में हजारों छवियों को वापस क्यों लौटना होगा।

Answer 5

कुछ डेटाबेस (उदा। Postgresql) स्वचालित रूप से क्षेत्रों सेक, शायद यह तेजी से जब उन्हें सीधे पढ़ने डाटाबेस से है।और यह भी, कार्यक्रम सभी क्षेत्रों और छवि को एक झुकाव में पढ़ सकता है।

Answer 6

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

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

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

Answer 7

ऊपर दिए गए पते के रूप में प्रदर्शन समस्या यहां है, इसलिए मैं इसे दोहराना नहीं चाहूंगा। लेकिन मुझे लगता है कि यदि आप चीजों को संग्रहित कर रहे हैं तो एक अच्छी युक्ति है (जैसे वेब साइट पर छवियों/दस्तावेजों) को कैशिंग सिस्टम में बनाना है।

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

Answer 8

मैं एक काफी अच्छे आकार ओएसएस परियोजना है कि अपनी स्थापना के समय निर्णय MySQL डेटाबेस में छवियों को स्टोर करने के लिए बनाया से परिचित हूँ, और सर्वोच्च 3 बुरा विचारों वे जब से के साथ मुकाबला करने की है, के बीच साबित हो रहा है। (वास्तव "refactor निर्दयता" अभिशाप है ने और बढ़ा दिया है, लेकिन यह एक और कहानी है।)

गंभीर समस्याओं का कारण है इस के अलावा

:

1. अधिकतम कुशल डेटाबेस आकार (mysql) से अधिक। (छवियों के लिए आवश्यक कुल स्थान अन्य सभी को परिमाण के कम से कम 2 ऑर्डर से अधिक करता है)।

2. छवि फ़ाइलों को उनकी "सुंदरता" खो देते हैं। कोई दिनांक आकार इत्यादि नहीं। जब तक कि तारीखों के रूप में संग्रहीत (अनावश्यक रूप से) (जिसके लिए प्रबंधन के लिए कोड की आवश्यकता होती है)।

3. मनमाने ढंग से बाइट अनुक्रम भंडारण या हेरफेर के लिए हर समय अच्छी तरह से संसाधित नहीं करते हैं।

4. "हमें कभी भी छवियों को बाहरी रूप से एक्सेस करने की आवश्यकता नहीं होगी" एक खतरनाक धारणा है।

5. फ्रैगिलिटी। क्योंकि पूरी व्यवस्था अप्राकृतिक और स्पर्शपूर्ण है, और आप नहीं जानते कि यह कहां काट देगा (एंटी-रिफैक्टर मानसिकता में योगदान)।

लाभ? कोई भी जिसे मैं सोच सकता हूं, सिवाय इसके कि उस समय कम से कम प्रतिरोध का मार्ग हो सकता है।

Answer 9

किसी सिद्धांत के दृष्टिकोण से समस्या को संबोधित करते हुए, एक संबंधित डेटाबेस (मुख्य रूप से) संरचित डेटा संग्रहीत करने के लिए वहां है। यदि आप कोई क्वेरी स्थिति नहीं बना सकते हैं या डेटा तत्व पर शामिल नहीं हो सकते हैं तो यह शायद डेटाबेस में नहीं है। मुझे एक WHERE खंड में उपयोग की जाने वाली छवि BLOB नहीं दिखाई दे रही है, इसलिए मैं इसे डेटाबेस के बाहर रखूंगा। दूसरी तरफ एक सीएलओबी प्रश्नों में इस्तेमाल किया जा सकता है।

Answer 10

"टेबल से चयन करें" करने के बारे में यह सब बात बड़ी मेमोरी और/या बैंडविड्थ मुद्दों के कारण होती है जब तालिका में एक LOB है, यह एक गैर-मुद्दा है। जो कुछ भी लौटाया गया है वह प्रश्न में LOB के लिए एक सूचक है। टिप्पणी को संदर्भ में रखने के लिए पर्याप्त प्रतिष्ठा नहीं है, लेकिन इस पर ध्यान देने वाले लोगों को पता होना चाहिए कि यह कोई मुद्दा नहीं है।

Answer 11

किसी भी डेटाबेस में किसी छवि (या अन्य बाइनरी दस्तावेज़) को संग्रहीत करने का विचार रखने वाला कोई व्यक्ति नहीं है जिसे मैं बहुत खुश हूं। डेटाबेस [ज्यादातर?] इंडेक्सबल, डिस्क्रेट डेटा के भंडारण के लिए हैं। अर्थहीन बाइनरी डेटा के बीएलओबी नहीं। यदि आपने पहले बाइनरी डेटा के लिए बीएलओबी के साथ काम किया है, तो आप इसे पहले ही जानते हैं।

आपको फाइल सिस्टम में फ़ाइल का संदर्भ संग्रहीत करना चाहिए। का सर्वोत्तम अभ्यास एक फ़ाइल नाम है, पूर्ण (या यहां तक ​​कि सापेक्ष) पथ नहीं।