रीयल

Question

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

मेरा सवाल यह है कि यह सबसे अच्छा अभ्यास क्यों है? उपर्युक्त से जुड़े उत्तरों कारण बताते हैं कि आप एक ब्लोएटेड डेटाबेस के साथ समाप्त क्यों नहीं करते हैं। लेकिन यह एक समस्या क्यों है? डिस्क पर बहुत सारी छवियों के साथ मेरे डेटाबेस में बहुत सारी छवियों के बीच अंतर क्या है?

क्या यह एक गति मुद्दा है? यदि हां, तो क्या ऐप में डिस्क से किसी छवि को एक्सेस करने में सक्षम होने के लिए रीयलम जैसे डेटाबेस समाधान से इसका उपयोग करने में सक्षम होने में एक चिह्नित गति अंतर है?

अग्रिम धन्यवाद।

Answer 1

यह वास्तव में केवल वास्तविकता के लिए स्थानीय समस्या नहीं है। मुझे कोर डेटा के साथ भी यही सलाह दी जा रही है।

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

कोर डेटा (यानी SQLite द्वारा समर्थित डेटाबेस) के साथ, आप वास्तव में एक प्रदर्शन हिट लेंगे क्योंकि जब आप SQLite से पढ़ते हैं तो डेटा को स्मृति में कॉपी किया जाएगा। यदि यह बड़ी मात्रा में डेटा है, तो यह पूरी तरह से अस्वीकार्य है।

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

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

यदि आवश्यक हो तो इस डिस्क स्थान को पुनः प्राप्त करने के लिए मैन्युअल रूप से एक ऑपरेशन करना संभव है, लेकिन आमतौर पर अनुशंसित दृष्टिकोण यह है कि इसे पहले स्थान पर होने से कम करने के लिए अपने कोड को अनुकूलित करें।

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

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