ब्लॉब में डेटा संग्रहीत करने के बीच क्या अंतर है, बनाम फ़ाइल में पॉइंटर संग्रहीत करना?

Question

मेरे पास MySQL में blob डेटा प्रकार के बारे में कोई प्रश्न है।

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

लेकिन मैं थोड़ा उलझन में हूं क्योंकि मैंने पढ़ा है कि ब्लॉब फ़ील्ड इन-पंक्ति में संग्रहीत नहीं हैं और इसकी सामग्री को पुनर्प्राप्त करने के लिए एक अलग रूपरेखा की आवश्यकता है। तो क्या फाइल सिस्टम पर फ़ाइल में पॉइंटर संग्रहीत करने से कोई अलग है?

Answer 1

मैंने पढ़ा कि डेटा प्रकार फ़ाइलों को स्टोर करने के लिए उपयोग किया जा सकता है।

ब्लॉब पर MySQL manual पृष्ठ के अनुसार, एक BLOB एक द्विआधारी बड़ी वस्तु है कि डेटा की एक परिवर्तनीय मात्रा पकड़ कर सकते हैं।

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

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

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

मैं भी पढ़ा है कि एक विकल्प डिस्क पर फ़ाइल की दुकान करने के लिए है और मन में

असर सब से ऊपर विचार वेब अनुप्रयोगों के लिए एक आम बात स्टोर करने के लिए है डेटाबेस में उसके स्थान का सूचक शामिल आपकी फाइलें आपके MySQL से कहीं और फिर बस अपने डेटाबेस पर इसका पथ संग्रहीत करें। इस दृष्टिकोण मई बड़ी मात्रा में डेटा से निपटने के दौरान अपने डेटाबेस को तेज करें।

लेकिन मैं थोड़ा उलझन में हूं क्योंकि मैंने पढ़ा है कि ब्लॉब फ़ील्ड इन-पंक्ति में संग्रहीत नहीं हैं और इसकी सामग्री को पुनर्प्राप्त करने के लिए एक अलग रूपरेखा की आवश्यकता है।

वास्तव में यह निर्भर करेगा कि आप किस स्टोरेज इंजन का उपयोग कर रहे हैं क्योंकि प्रत्येक इंजन डेटा का व्यवहार करता है और इसे विभिन्न तरीकों से स्टोर करता है।इनो डीबी इंजन के लिए, जो रिलेशनल डेटाबेस के लिए उपयुक्त है, आप इस आलेख को MySQL Performance blog से पढ़ सकते हैं कि ब्लॉब MySQL में कैसे संग्रहीत किया जाता है। पर संग्रहीत करने के लिए

InnoDB भंडार पंक्ति पृष्ठ पर या तो पूरा ब्लॉब या केवल 20 बाइट्स ब्लॉब सूचक छोटे स्तंभों को वरीयता देने के:

लेकिन सार में, MySQL 5 पर और आगे ब्लॉब निम्नलिखित के रूप में संग्रहीत किया जाता है पृष्ठ, जो उचित है क्योंकि आप उनमें से अधिक स्टोर कर सकते हैं।

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

बैकअप के लिए ब्लॉब्स संग्रह करने का लाभ this post पर बेहतर चर्चा की गई है, जिसने उत्तर देने वाले व्यक्ति की तुलना में इसी तरह की समस्या थी।

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

एक ऐसे एप्लिकेशन में जो प्रमाणीकरण और उपयोग के लिए MySQL विशेषाधिकार प्रणाली पर निर्भर करता है। यह निश्चित रूप से एक प्लस है क्योंकि आइए एक आक्रमणकर्ता को आपकी डिस्क से किसी छवि को पुनर्प्राप्त करने के लिए एक आक्रमणकारक (या एक ज़िप वाली फ़ाइल जैसी एक बाइनरी फ़ाइल) कहने के लिए थोड़ा कठिन होगा।

तो मैं कहेंगे कि

तुम अपने MySQL और सभी डेटा आप इसे में है और नियमित रूप से बैकअप कर सकते हैं या बदल सकते हैं या यहां तक ​​कि ओएस के भविष्य के परिवर्तन पर विचार करने का इरादा चाहिए, और एक सभ्य राशि का प्रबंधन करते हैं हार्डवेयर और इसे आपके MySQL अनुकूलित करें, बीएलओबी के लिए जाएं।

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

मुझे आशा है कि इससे मदद मिलेगी। चीयर्स

Answer 2

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

Answer 3

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

डेटाबेस बड़े ब्लॉब्स के साथ भी तेजी से बढ़ सकता है और फिर बैकिंग की तरह कार्य धीमे हो जाते हैं। मैं फाइल सिस्टम पर भौतिक भंडारण के साथ डेटाबेस में फ़ाइल स्थान के साथ जाऊंगा।

Answer 4

हां, माईएसQL ब्लॉब्स जो पंक्ति के समान पृष्ठ में फिट नहीं होते हैं, ओवरफ्लो पृष्ठों पर संग्रहीत होते हैं ध्यान दें कि कुछ ब्लब्स इतने छोटे हैं कि वे किसी अन्य कॉलम की तरह शेष पंक्ति के साथ संग्रहीत होते हैं। ब्लॉब पेज उस पृष्ठ के नजदीक नहीं हैं जो उनकी पंक्ति को संग्रहीत किया जाता है, इसलिए परिणामस्वरूप उन्हें अतिरिक्त I/O मिल सकता है।

दूसरी तरफ, किसी भी अन्य पेज प्रकार की तरह, ब्लॉब पेज इनो डीबी बफर पूल में स्मृति पर कब्जा कर सकते हैं, इसलिए बाद में ब्लॉब्स पढ़ने से बहुत तेज़ होते हैं भले ही वे अलग-अलग पृष्ठों पर हों। फ़ाइलों को ऑपरेटिंग सिस्टम द्वारा कैश किया जा सकता है, लेकिन आमतौर पर वे डिस्क से पढ़े जाते हैं।

यहाँ कुछ अन्य कारक है कि अपने निर्णय को प्रभावित कर सकते हैं:

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

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

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

• यदि आप प्रतिकृति का उपयोग करते हैं, तो ब्लब्स को स्वचालित रूप से प्रतिकृति दास में कॉपी करने का एकमात्र स्वचालित तरीका डेटाबेस में ब्लॉब्स को स्टोर करना है।

Answer 5

यदि आप डेटा स्टोर करते हैं तो BLOB फ़ील्ड है, तो आप इसे अपने ऑब्जेक्ट अबास्ट्रक्शन का हिस्सा बना रहे हैं।

ब्लॉब फायदे:

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

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

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

फ़ाइल फायदे:

1. कुछ डेटाबेस बल्कि खराब BLOBs संभाल। उदाहरण के लिए, जबकि MySQL में आधिकारिक बीएलओबी सीमा 4 जीबी है, लेकिन वास्तविकता में यह डिफ़ॉल्ट कॉन्फ़िगरेशन में केवल 1 एमबी है। आप MySQL कमांड बफर को बढ़ाने के लिए क्लाइंट और सर्वर कॉन्फ़िगरेशन दोनों को ट्वीव करके 16-32 एमबी तक बढ़ा सकते हैं, लेकिन प्रदर्शन और सुरक्षा के मामले में इसमें कई अन्य प्रभाव हैं।

2. भले ही डेटाबेस में कुछ अजीब आकार सीमाएं न हों, फिर भी यह हमेशा एक फ़ाइल की तुलना में बीएलओबी को संग्रहीत करने में कुछ ओवरहेड होगा। इसके अलावा, यदि बीएलओबी बड़ा है, तो कुछ डेटाबेस टुकड़े द्वारा ब्लॉब टुकड़े तक पहुंचने के लिए इंटरफ़ेस प्रदान नहीं करते हैं, या stream, जो आपके वर्कफ़्लो के लिए बड़ी बाधा हो सकती है।

अंत में, यह आपके ऊपर है। मैं आमतौर पर इसे बीएलओबी में रखने की कोशिश करता हूं, जब तक यह अनुचित प्रदर्शन समस्याओं को उत्पन्न न करे।