डेटाबेस में ब्लॉब्स के रूप में दस्तावेज़ संग्रहीत करना - कोई नुकसान?

Question

मेरे दस्तावेज़ प्रबंधन प्रणाली के लिए आवश्यकताओं थे:

1. निर्देशिका के सरल नकल के कारण यह चोरी से सुरक्षित होना चाहिए (भौतिक फ़ाइल का संक्रमण)
2. , फ़ाइलों आदि
3. पारंपरिक वायरस के संक्रमण के खिलाफ सुरक्षित होना चाहिए पुनः प्राप्त करने के लिए तेजी से होना चाहिए
4. भंडार आकस्मिक (निर्देशिका) को दिखाई नहीं होना चाहिए ब्राउज़ कर उन आदि

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

मेरा सवाल है - क्या कोई गंभीर जोखिम या चीजें हैं जिन्हें मैंने अनदेखा किया है इस डिजाइन और कार्यान्वयन के साथ?

संपादित करें नोट: डीबी पोस्टग्रेएसक्यूएल है, ब्लॉब्स को बहुत अच्छी तरह से संभालता है और असाधारण रूप से स्केल करता है। पर्यावरण बहु-उपयोगकर्ता है।

Answer 1

जब आपका डीबी बड़ा और बड़ा हो जाता है तो यह बैकअप के लिए कठिन हो जाएगा। 100 जीबी डेटा वाले टेबल के बैकअप को पुनर्स्थापित करना ऐसा कुछ नहीं है जो आपको खुश कर देता है।

एक और चीज जो प्राप्त करती है वह है कि सभी तालिका प्रबंधन कार्य धीमे और धीमे हो जाते हैं क्योंकि डेटासेट बढ़ता है।
लेकिन यह आपकी डेटा तालिका बनाकर केवल 2 फ़ील्ड: आईडी और बीएलओबी बनाकर दूर किया जा सकता है।

डेटा पुनर्प्राप्त करना (प्राथमिक कुंजी द्वारा) डेटासेट का बैक अप लेने के बाद दीवार को मारने के बाद ही समस्या हो सकती है।

Answer 2

यह article अधिकांश मुद्दों को शामिल करता है। यदि आप SQL Server 2008 का उपयोग कर रहे हैं, तो पॉल रैंडल here द्वारा चर्चा के अनुसार नए FILESTREAM प्रकार का उपयोग देखें।

Answer 3

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

good reference (PDF) here है जो ब्लब्स के पेशेवरों और विपक्ष को कवर करता है।

Answer 4

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

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

रखरखाव और प्रशासन परिप्रेक्ष्य से आप एमएस एसक्यूएल सर्वर से निपटने के दौरान स्वयं को SAN तक सीमित कर देंगे। दस्तावेज़ जैसे समाधान डिस्क पर सरल भंडारण के साथ एक अलग दृष्टिकोण लेते हैं और आप फिट बैठते समय स्टोरेज समाधान को लागू करने की अनुमति देते हैं।

संपादित

मुझे मेरे बयान स्पष्ट करते हैं - SQL सर्वर के साथ आप विकल्पों को सीमित कर दिया है जब आप बॉक्स के भौतिक भंडारण क्षमता से अधिक है। यह वास्तव में शेयरपॉइंट की बड़ी कमजोरियों में से एक है कि आप किसी भी प्रकार के नेटवर्क स्टोरेज को आसानी से संलग्न करने में सक्षम नहीं हैं।

Answer 5

यह डाटाबेसटाइप पर निर्भर करता है। ओरेकल या एसक्यूएल सर्वर? एक नुकसान के बारे में जागरूक रहें - एक दस्तावेज़ की बहाली।

Answer 6

मेरे अनुभव से, कुछ मुद्दों थे:

1. गति फाइल सिस्टम पर फ़ाइलों होने बनाम।

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

3. मेमोरी बाधाएं। मेरे आखिरी काम पर हमारे पास डेटाबेस में 40 एमबी पीडीएफ था, और लॉग फ़ाइल में Java OutOfMemoryErrors प्राप्त करना जारी रखा। हमें अंततः एहसास हुआ कि पूरे 80 एमबी पीडीएफ को केवल एक बार ढेर में पढ़ा नहीं गया था, लेकिन हाइबरनेट ओआरएम में एक सेटिंग के लिए TWICE धन्यवाद (यदि कोई वस्तु उत्परिवर्तनीय है, तो यह स्मृति में संपादन के लिए एक प्रति बनाता है)। एक बार जब पीडीएफ उपयोगकर्ता को वापस स्ट्रीम किया गया था, तो ढेर साफ़ कर दिया गया था, लेकिन एक दस्तावेज़ को स्ट्रीम करने के लिए एक बार में ढेर से 80 एमबी चूसने के लिए यह एक बड़ी हिट थी। अपना कोड जानें और स्मृति का उपयोग कैसे किया जा रहा है!

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

Answer 7

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

बीएलओबी भंडारण के लिए एक बेहतर समाधान मौजूद होना चाहिए। सर्वोत्तम प्रथाएं क्या हैं?

Answer 8

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

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

आप व्हील का पुन: आविष्कार करने के बजाय किसी प्रकार के एपीआई के साथ ईसीएम सिस्टम की जांच करना चाह सकते हैं।