2019 के पतन में, Mail.ru क्लाउड iOS टीम में एक लंबे समय से प्रतीक्षित घटना घटी। एप्लिकेशन स्थिति के लगातार भंडारण के लिए मुख्य डेटाबेस मोबाइल दुनिया के लिए बहुत आकर्षक हो गया है लाइटनिंग मेमोरी-मैप्ड डेटाबेस (एलएमडीबी)। कट के नीचे हम आपको चार भागों में इसकी विस्तृत समीक्षा प्रदान करते हैं। सबसे पहले, आइए ऐसे गैर-तुच्छ और कठिन विकल्प के कारणों के बारे में बात करें। फिर हम एलएमडीबी वास्तुकला के केंद्र में तीन स्तंभों पर विचार करने के लिए आगे बढ़ेंगे: मेमोरी-मैप की गई फ़ाइलें, बी+-ट्री, लेन-देन और मल्टीवर्जन को लागू करने के लिए कॉपी-ऑन-राइट दृष्टिकोण। अंत में, मिठाई के लिए - व्यावहारिक हिस्सा। इसमें हम देखेंगे कि निम्न-स्तरीय कुंजी-मूल्य एपीआई के शीर्ष पर, एक इंडेक्स सहित कई तालिकाओं के साथ डेटाबेस स्कीमा को कैसे डिज़ाइन और कार्यान्वित किया जाए।

सामग्री

क्रियान्वयन हेतु प्रेरणा
एलएमडीबी पोजिशनिंग
एलएमडीबी के तीन स्तंभ
3.1. व्हेल #1. मेमोरी-मैप की गई फ़ाइलें
3.2. व्हेल #2. बी+-वृक्ष
3.3. व्हेल #3. लिखने पर नकल
कुंजी-मूल्य एपीआई के शीर्ष पर एक डेटा स्कीमा डिज़ाइन करना
4.1. बुनियादी सार
4.2. टेबल मॉडलिंग
4.3. तालिकाओं के बीच संबंधों की मॉडलिंग

1. कार्यान्वयन हेतु प्रेरणा

2015 में एक साल, हमने यह मापने का कष्ट उठाया कि हमारे एप्लिकेशन का इंटरफ़ेस कितनी बार पिछड़ जाता है। हमने ऐसा एक कारण से किया। हमें लगातार शिकायतें मिल रही हैं कि कभी-कभी एप्लिकेशन उपयोगकर्ता के कार्यों का जवाब देना बंद कर देता है: बटन दबाए नहीं जा सकते, सूचियां स्क्रॉल नहीं होतीं, आदि। माप की यांत्रिकी के बारे में मुझे बताया गया है एविटोटेक पर, इसलिए यहां मैं केवल संख्याओं का क्रम देता हूं।

माप परिणाम हमारे लिए ठंडी बौछार बन गए। यह पता चला कि किसी भी अन्य समस्या की तुलना में फ़्रीज़ के कारण बहुत अधिक समस्याएँ होती हैं। यदि इस तथ्य को समझने से पहले गुणवत्ता का मुख्य तकनीकी संकेतक क्रैश-फ्री था, तो फोकस के बाद स्थानांतरित कर दिया फ्रीज मुक्त पर.

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

सिस्टम संगठन का अभिनेता मॉडल मानता है कि मल्टीथ्रेडिंग इसका दूसरा सार बन जाता है। इसमें मॉडल ऑब्जेक्ट स्ट्रीम सीमाओं को पार करना पसंद करते हैं। और वे ऐसा कभी-कभी और इधर-उधर नहीं, बल्कि लगभग लगातार और हर जगह करते हैं

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

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

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

अन्य आवश्यकताएँ अधिक पारंपरिक हैं और उनकी पूरी सूची इस प्रकार है।

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

आवश्यकताओं के इस सेट के साथ, SQLite एक अच्छा विकल्प था और रहेगा। हालाँकि, विकल्पों के अध्ययन के हिस्से के रूप में, मुझे एक किताब मिली "लेवलडीबी के साथ शुरुआत करना". उनके नेतृत्व में, वास्तविक क्लाउड परिदृश्यों में विभिन्न डेटाबेस के साथ काम की गति की तुलना करते हुए एक बेंचमार्क लिखा गया था। नतीजा हमारी बेतहाशा उम्मीदों से बढ़कर रहा। सबसे लोकप्रिय मामलों में - सभी फ़ाइलों की क्रमबद्ध सूची पर कर्सर प्राप्त करना और किसी दिए गए निर्देशिका के लिए सभी फ़ाइलों की क्रमबद्ध सूची प्राप्त करना - एलएमडीबी SQLite की तुलना में 10 गुना तेज निकला। चुनाव स्पष्ट हो गया.

2. एलएमडीबी पोजिशनिंग

एलएमडीबी एक बहुत छोटी लाइब्रेरी (केवल 10K पंक्तियाँ) है जो डेटाबेस की सबसे निचली मौलिक परत - स्टोरेज को लागू करती है।

उपरोक्त आरेख से पता चलता है कि एलएमडीबी की तुलना SQLite से करना, जो उच्च स्तर को भी लागू करता है, आम तौर पर कोर डेटा के साथ SQLite से अधिक सही नहीं है। समान स्टोरेज इंजनों को समान प्रतिस्पर्धियों के रूप में उद्धृत करना अधिक उचित होगा - बर्कलेडीबी, लेवलडीबी, सोफिया, रॉक्सडीबी, आदि। ऐसे विकास भी हैं जहां एलएमडीबी SQLite के लिए स्टोरेज इंजन घटक के रूप में कार्य करता है। ऐसा पहला प्रयोग 2012 में हुआ था संचालित एलएमडीबी द्वारा हावर्ड चु. निष्कर्ष यह इतना दिलचस्प साबित हुआ कि उनकी पहल को ओएसएस उत्साही लोगों ने हाथों-हाथ लिया और व्यक्ति में इसकी निरंतरता पाई लुमोएसक्यूएल. जनवरी 2020 में इस प्रोजेक्ट के लेखक डेन शियरर थे पेश किया यह LinuxConfAu पर है।

एलएमडीबी का उपयोग मुख्य रूप से एप्लिकेशन डेटाबेस के लिए एक इंजन के रूप में किया जाता है। लाइब्रेरी का स्वरूप डेवलपर्स के कारण है OpenLDAP, जो अपने प्रोजेक्ट के आधार के रूप में बर्कलेडीबी से अत्यधिक असंतुष्ट थे। एक साधारण पुस्तकालय से शुरुआत बीट्री, हॉवर्ड चू हमारे समय के सबसे लोकप्रिय विकल्पों में से एक बनाने में सक्षम था। उन्होंने अपनी बहुत अच्छी रिपोर्ट इस कहानी के साथ-साथ एलएमडीबी की आंतरिक संरचना को भी समर्पित की। "द लाइटनिंग मेमोरी-मैप्ड डेटाबेस". भंडारण सुविधा पर विजय प्राप्त करने का एक अच्छा उदाहरण लियोनिद यूरीव (उर्फ) द्वारा साझा किया गया था येलो) हाईलोड 2015 में अपनी रिपोर्ट में पॉजिटिव टेक्नोलॉजीज से "LMDB इंजन एक विशेष चैंपियन है". इसमें, वह ReOpenLDAP को लागू करने के समान कार्य के संदर्भ में एलएमडीबी के बारे में बात करता है, और लेवलडीबी पहले से ही तुलनात्मक आलोचना का विषय रहा है। कार्यान्वयन के परिणामस्वरूप, पॉजिटिव टेक्नोलॉजीज के पास सक्रिय रूप से विकासशील कांटा भी था एमडीबीएक्स बहुत स्वादिष्ट सुविधाओं, अनुकूलन और के साथ कंप्यूटर प्रोग्राम या प्रणाली में बग को दूर करना.

एलएमडीबी का उपयोग अक्सर यथा-भंडार के रूप में किया जाता है। उदाहरण के लिए, मोज़िला फ़ायरफ़ॉक्स ब्राउज़र चुना यह कई आवश्यकताओं के लिए है, और, संस्करण 9, Xcode से शुरू होता है पसंदीदा अनुक्रमणिका संग्रहीत करने के लिए यह SQLite है।

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

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

3. एलएमडीबी के तीन स्तंभ

एलएमडीबी को विहंगम दृष्टि से देखने के बाद, गहराई में जाने का समय आ गया है। अगले तीन खंड उन मुख्य स्तंभों के विश्लेषण के लिए समर्पित होंगे जिन पर भंडारण वास्तुकला टिकी हुई है:

डिस्क के साथ काम करने और आंतरिक डेटा संरचनाओं को सिंक्रनाइज़ करने के लिए एक तंत्र के रूप में मेमोरी-मैप की गई फ़ाइलें।
B+-ट्री संग्रहीत डेटा की संरचना के एक संगठन के रूप में।
ACID लेनदेन गुण और बहुसंस्करण प्रदान करने के दृष्टिकोण के रूप में कॉपी-ऑन-राइट।

3.1. व्हेल #1. मेमोरी-मैप की गई फ़ाइलें

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

कई प्रक्रियाओं से डेटा के साथ काम करते समय स्टोरेज में डेटा की स्थिरता बनाए रखना ऑपरेटिंग सिस्टम की जिम्मेदारी बन जाती है। अगले भाग में, इस यांत्रिकी पर विस्तार से और चित्रों के साथ चर्चा की गई है।
कैश की अनुपस्थिति गतिशील आवंटन से जुड़े ओवरहेड से एलएमडीबी को पूरी तरह से समाप्त कर देती है। व्यवहार में डेटा पढ़ने का अर्थ है वर्चुअल मेमोरी में सही पते पर पॉइंटर सेट करना और इससे अधिक कुछ नहीं। यह विज्ञान कथा की तरह लगता है, लेकिन स्टोरेज सोर्स कोड में कॉलोक की सभी कॉल स्टोरेज कॉन्फ़िगरेशन फ़ंक्शन में केंद्रित होती हैं।
कैश की अनुपस्थिति का अर्थ उनकी पहुंच के सिंक्रनाइज़ेशन से जुड़े ताले की अनुपस्थिति भी है। पाठक, जिनमें से एक ही समय में पाठकों की मनमानी संख्या हो सकती है, डेटा के रास्ते में एक भी म्यूटेक्स का सामना नहीं करते हैं। इसके कारण, पढ़ने की गति में सीपीयू की संख्या के आधार पर आदर्श रैखिक मापनीयता होती है। एलएमडीबी में, केवल संशोधित संचालन सिंक्रनाइज़ किए जाते हैं। एक समय में केवल एक ही लेखक हो सकता है।
न्यूनतम कैशिंग और सिंक्रनाइज़ेशन तर्क बहु-थ्रेडेड वातावरण में काम करने से जुड़ी अत्यंत जटिल प्रकार की त्रुटियों को समाप्त करता है। यूसेनिक्स ओएसडीआई 2014 सम्मेलन में दो दिलचस्प डेटाबेस अध्ययन थे: "सभी फ़ाइल सिस्टम समान नहीं बनाए गए हैं: क्रैश-संगत अनुप्रयोगों को तैयार करने की जटिलता पर" и "मौज-मस्ती और लाभ के लिए डेटाबेस पर अत्याचार करना". उनसे आप LMDB की अभूतपूर्व विश्वसनीयता और ACID लेनदेन गुणों के लगभग दोषरहित कार्यान्वयन, जो SQLite से बेहतर है, दोनों के बारे में जानकारी प्राप्त कर सकते हैं।
एलएमडीबी का अतिसूक्ष्मवाद मशीन को अपने कोड के प्रतिनिधित्व को आगामी गति विशेषताओं के साथ प्रोसेसर के एल1 कैश में पूरी तरह से स्थित करने की अनुमति देता है।

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

मेमोरी-मैप की गई फ़ाइलों के बारे में सामान्य जानकारी

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

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

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

ऑपरेटिंग सिस्टम वर्चुअल और फिजिकल मेमोरी को एक निश्चित आकार के पेजों में व्यवस्थित करता है। जैसे ही वर्चुअल मेमोरी का एक निश्चित पृष्ठ मांग में होता है, ऑपरेटिंग सिस्टम इसे भौतिक मेमोरी में लोड करता है और एक विशेष तालिका में उनका मिलान करता है। यदि कोई मुफ्त स्लॉट नहीं हैं, तो पहले से लोड किए गए पृष्ठों में से एक को डिस्क पर कॉपी किया जाता है, और जो मांग में है वह उसकी जगह ले लेता है। यह प्रक्रिया, जिस पर हम शीघ्र ही लौटेंगे, स्वैपिंग कहलाती है। नीचे दिया गया चित्र वर्णित प्रक्रिया को दर्शाता है। उस पर, पता 0 वाला पेज ए लोड किया गया था और पता 4 के साथ मुख्य मेमोरी पेज पर रखा गया था। यह तथ्य सेल नंबर 0 में पत्राचार तालिका में परिलक्षित होता था।

मेमोरी में मैप की गई फ़ाइलों के साथ भी कहानी बिल्कुल वैसी ही है। तार्किक रूप से, वे कथित रूप से लगातार और पूरी तरह से वर्चुअल एड्रेस स्पेस में स्थित हैं। हालाँकि, वे केवल अनुरोध पर ही भौतिक मेमोरी पेज दर पेज दर्ज करते हैं। ऐसे पृष्ठों का संशोधन डिस्क पर फ़ाइल के साथ सिंक्रनाइज़ किया जाता है। इस तरह, आप केवल मेमोरी में बाइट्स के साथ काम करके फ़ाइल I/O निष्पादित कर सकते हैं - सभी परिवर्तन स्वचालित रूप से ऑपरेटिंग सिस्टम कर्नेल द्वारा स्रोत फ़ाइल में स्थानांतरित कर दिए जाएंगे।
Στρατός Assault - Παίξτε Funny Games
नीचे दी गई छवि दर्शाती है कि विभिन्न प्रक्रियाओं से डेटाबेस के साथ काम करते समय एलएमडीबी अपनी स्थिति को कैसे सिंक्रनाइज़ करता है। विभिन्न प्रक्रियाओं की वर्चुअल मेमोरी को एक ही फ़ाइल में मैप करके, हम वास्तव में ऑपरेटिंग सिस्टम को उनके एड्रेस स्पेस के कुछ ब्लॉकों को एक-दूसरे के साथ ट्रांज़िटिव रूप से सिंक्रनाइज़ करने के लिए बाध्य करते हैं, जहां एलएमडीबी दिखता है।
Στρατός Assault - Παίξτε Funny Games

एक महत्वपूर्ण बारीकियां यह है कि एलएमडीबी, डिफ़ॉल्ट रूप से, राइट सिस्टम कॉल तंत्र के माध्यम से डेटा फ़ाइल को संशोधित करता है, और फ़ाइल को केवल-पढ़ने के लिए मोड में प्रदर्शित करता है। इस दृष्टिकोण के दो महत्वपूर्ण परिणाम हैं।

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

दूसरा परिणाम पहले से ही iOS के लिए विशिष्ट है। न तो लेखक और न ही किसी अन्य स्रोत ने स्पष्ट रूप से इसका उल्लेख किया है, लेकिन इसके बिना एलएमडीबी इस मोबाइल ऑपरेटिंग सिस्टम पर चलने के लिए उपयुक्त नहीं होगा। अगला भाग इसके विचार के लिए समर्पित है।

iOS में मेमोरी-मैप की गई फ़ाइलों की विशिष्टताएँ

2018 में WWDC में एक अद्भुत रिपोर्ट आई थी "आईओएस मेमोरी डीप डाइव". यह हमें बताता है कि iOS में, भौतिक मेमोरी में स्थित सभी पेज 3 प्रकारों में से एक हैं: गंदा, संपीड़ित और साफ़।

क्लीन मेमोरी पृष्ठों का एक संग्रह है जिसे भौतिक मेमोरी से दर्द रहित तरीके से अनलोड किया जा सकता है। उनमें मौजूद डेटा को उसके मूल स्रोतों से आवश्यकतानुसार पुनः लोड किया जा सकता है। केवल पढ़ने योग्य मेमोरी-मैप्ड फ़ाइलें इस श्रेणी में आती हैं। iOS किसी भी समय मेमोरी से फ़ाइल में मैप किए गए पृष्ठों को अनलोड करने से डरता नहीं है, क्योंकि उन्हें डिस्क पर फ़ाइल के साथ सिंक्रनाइज़ होने की गारंटी होती है।
Στρατός Assault - Παίξτε Funny Games
सभी संशोधित पृष्ठ गंदी स्मृति में चले जाते हैं, चाहे वे मूल रूप से कहीं भी स्थित हों। विशेष रूप से, उनसे जुड़ी वर्चुअल मेमोरी में लिखकर संशोधित मेमोरी-मैप की गई फ़ाइलों को इस तरह से वर्गीकृत किया जाएगा। झंडे के साथ एलएमडीबी खोलना MDB_WRITEMAP, इसमें परिवर्तन करने के बाद, आप इसे व्यक्तिगत रूप से सत्यापित कर सकते हैं

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

अच्छी खबर, जिसका उल्लेख पहले ही किया जा चुका है, यह है कि एलएमडीबी डिफ़ॉल्ट रूप से फ़ाइलों को अपडेट करने के लिए एमएमएपी तंत्र का उपयोग नहीं करता है। इसका मतलब यह है कि प्रदर्शित डेटा को iOS द्वारा स्वच्छ मेमोरी के रूप में वर्गीकृत किया गया है और यह मेमोरी फ़ुटप्रिंट में योगदान नहीं देता है। आप इसे VM ट्रैकर नामक Xcode टूल का उपयोग करके सत्यापित कर सकते हैं। नीचे दिया गया स्क्रीनशॉट ऑपरेशन के दौरान क्लाउड एप्लिकेशन की iOS वर्चुअल मेमोरी की स्थिति दिखाता है। शुरुआत में इसमें 2 LMDB इंस्टेंसेस को इनिशियलाइज़ किया गया था। पहले को अपनी फ़ाइल को 1GiB वर्चुअल मेमोरी पर प्रदर्शित करने की अनुमति दी गई थी, दूसरे को - 512MiB पर। इस तथ्य के बावजूद कि दोनों स्टोरेज एक निश्चित मात्रा में निवासी मेमोरी पर कब्जा करते हैं, उनमें से कोई भी गंदे आकार में योगदान नहीं देता है।

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

क्लाउड में प्रयोगों के परिणामों के आधार पर, हम एलएमडीबी द्वारा आवंटित मेमोरी के लिए निम्नलिखित समझौता मूल्यों पर आए: 384-बिट उपकरणों के लिए 32 मेगाबाइट और 768-बिट उपकरणों के लिए 64। इस वॉल्यूम का उपयोग हो जाने के बाद, कोई भी संशोधित कार्य कोड के साथ समाप्त होना शुरू हो जाता है MDB_MAP_FULL. हम अपनी निगरानी में ऐसी त्रुटियाँ देखते हैं, लेकिन वे इतनी छोटी होती हैं कि इस स्तर पर उन्हें नज़रअंदाज किया जा सकता है।

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

3.2. व्हेल #2. बी+-वृक्ष

कुंजी-मूल्य भंडारण के शीर्ष पर तालिकाओं का अनुकरण करने के लिए, निम्नलिखित ऑपरेशन इसके एपीआई में मौजूद होने चाहिए:

एक नया तत्व सम्मिलित करना.
दी गई कुंजी के साथ एक तत्व खोजें।
किसी तत्व को हटाना.
कुंजियों को क्रमबद्ध करने के क्रम में उनके अंतरालों पर पुनरावृति करें।

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

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

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

जिसके चलते:

प्रत्येक नोड में पहले से ऑर्डर की गई बड़ी संख्या में कुंजियाँ होती हैं और पेड़ बहुत छोटे होते हैं।
पेड़ स्मृति में स्थानीयता का गुण प्राप्त कर लेता है, क्योंकि जो कुंजियाँ मूल्य के करीब होती हैं वे स्वाभाविक रूप से समान या पड़ोसी नोड्स पर एक दूसरे के बगल में स्थित होती हैं।
खोज अभियान के दौरान पेड़ से नीचे उतरते समय पारगमन नोड्स की संख्या कम हो जाती है।
श्रेणी क्वेरी के दौरान पढ़े जाने वाले लक्ष्य नोड्स की संख्या कम हो जाती है, क्योंकि उनमें से प्रत्येक में पहले से ही बड़ी संख्या में ऑर्डर की गई कुंजियाँ होती हैं।

एलएमडीबी डेटा संग्रहीत करने के लिए बी-ट्री की एक भिन्नता का उपयोग करता है जिसे बी+ ट्री कहा जाता है। ऊपर दिया गया चित्र इसमें मौजूद तीन प्रकार के नोड्स को दर्शाता है:

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

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

पेज नोड्स की आंतरिक सामग्री से निपटने के बाद, हम एलएमडीबी बी-ट्री को निम्नलिखित रूप में सरल तरीके से प्रस्तुत करेंगे।

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

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

3.3. व्हेल #3. लिखने पर नकल

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

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

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

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

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

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

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

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

4. कुंजी-मूल्य एपीआई के शीर्ष पर एक डेटा स्कीमा डिजाइन करना

आइए एलएमडीबी द्वारा प्रदान किए गए बुनियादी सार को देखकर अपना एपीआई विश्लेषण शुरू करें: पर्यावरण और डेटाबेस, कुंजी और मूल्य, लेनदेन और कर्सर।

कोड लिस्टिंग के बारे में एक नोट

सार्वजनिक एलएमडीबी एपीआई में सभी फ़ंक्शन त्रुटि कोड के रूप में अपने काम का परिणाम लौटाते हैं, लेकिन बाद की सभी सूचियों में संक्षिप्तता के लिए इसका सत्यापन छोड़ दिया जाता है। व्यवहार में, हमने रिपॉजिटरी के साथ बातचीत करने के लिए अपने स्वयं का भी उपयोग किया है काँटा सी++ रैपर lmdbxx, जिसमें त्रुटियाँ C++ अपवाद के रूप में सामने आती हैं।

iOS या macOS के लिए किसी प्रोजेक्ट से LMDB को कनेक्ट करने के सबसे तेज़ तरीके के रूप में, मैं अपने CocoaPod का सुझाव देता हूँ POSLMDB.

4.1. बुनियादी सार

पर्यावरण

संरचना MDB_env एलएमडीबी की आंतरिक स्थिति का भंडार है। उपसर्ग फ़ंक्शन परिवार mdb_env आपको इसके कुछ गुणों को कॉन्फ़िगर करने की अनुमति देता है। सबसे सरल मामले में, इंजन आरंभीकरण इस तरह दिखता है।

mdb_env_create(env);
mdb_env_set_map_size(*env, 1024 * 1024 * 512)
mdb_env_open(*env, path.UTF8String, MDB_NOTLS, 0664);

Mail.ru क्लाउड एप्लिकेशन में, हमने केवल दो मापदंडों के डिफ़ॉल्ट मान बदले हैं।

पहला वर्चुअल एड्रेस स्पेस का आकार है जिस पर स्टोरेज फ़ाइल को मैप किया गया है। दुर्भाग्य से, एक ही डिवाइस पर भी, विशिष्ट मान रन दर रन में काफी भिन्न हो सकता है। iOS की इस सुविधा को ध्यान में रखने के लिए, अधिकतम स्टोरेज वॉल्यूम को गतिशील रूप से चुना जाता है। एक निश्चित मान से शुरू करके, फ़ंक्शन तक इसे क्रमिक रूप से आधा कर दिया जाता है mdb_env_open से भिन्न कोई परिणाम नहीं लौटाएगा ENOMEM. सिद्धांत रूप में, इसका विपरीत तरीका भी है - पहले इंजन को न्यूनतम मेमोरी आवंटित करें, और फिर, जब त्रुटियाँ प्राप्त हों, MDB_MAP_FULL, इसे बढ़ाओ। हालाँकि, यह बहुत अधिक कांटेदार है। इसका कारण यह है कि फ़ंक्शन का उपयोग करके मेमोरी को पुनः आवंटित करने की प्रक्रिया (रीमैप)। mdb_env_set_map_size इंजन से पहले प्राप्त सभी संस्थाओं (कर्सर, लेनदेन, कुंजियाँ और मान) को अमान्य कर देता है। कोड में घटनाओं के इस मोड़ को ध्यान में रखने से इसकी महत्वपूर्ण जटिलता पैदा हो जाएगी। हालाँकि, यदि वर्चुअल मेमोरी आपके लिए बहुत महत्वपूर्ण है, तो यह उस कांटे पर करीब से नज़र डालने का एक कारण हो सकता है जो बहुत आगे निकल चुका है एमडीबीएक्स, जहां घोषित सुविधाओं में से "स्वचालित ऑन-द-फ्लाई डेटाबेस आकार समायोजन" है।

दूसरा पैरामीटर, जिसका डिफ़ॉल्ट मान हमारे अनुरूप नहीं है, थ्रेड सुरक्षा सुनिश्चित करने के यांत्रिकी को नियंत्रित करता है। दुर्भाग्य से, कम से कम iOS 10 में थ्रेड लोकल स्टोरेज के समर्थन में समस्याएँ हैं। इस कारण से, उपरोक्त उदाहरण में, रिपॉजिटरी को ध्वज के साथ खोला गया है MDB_NOTLS. इसके अलावा ये जरूरी भी था काँटा सी++ रैपर lmdbxxइस विशेषता और इसमें मौजूद वेरिएबल्स को काटने के लिए।

डेटाबेस

डेटाबेस एक अलग बी-ट्री उदाहरण है, जिसकी हमने ऊपर चर्चा की है। इसका उद्घाटन एक लेनदेन के अंदर होता है, जो पहली बार में थोड़ा अजीब लग सकता है।

MDB_txn *txn;
MDB_dbi dbi;
mdb_txn_begin(env, NULL, MDB_RDONLY, &txn);
mdb_dbi_open(txn, NULL, MDB_CREATE, &dbi);
mdb_txn_abort(txn);

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

कुंजी और मूल्य

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

typedef struct MDB_val {
    size_t mv_size;
    void *mv_data;
} MDB_val;

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

लेन-देन

लेन-देन संरचना का विस्तार से वर्णन किया गया है पिछला अध्याय, इसलिए यहां मैं संक्षेप में उनके मुख्य गुणों को दोहराऊंगा:

सभी बुनियादी गुणों का समर्थन करता है एसिड: परमाणुता, स्थिरता, अलगाव और विश्वसनीयता। मैं मदद नहीं कर सकता लेकिन ध्यान दें कि macOS और iOS पर स्थायित्व के संदर्भ में एक बग है जिसे MDBX में ठीक किया गया था। आप उनमें और अधिक पढ़ सकते हैं README.
मल्टीथ्रेडिंग के दृष्टिकोण को "एकल लेखक/एकाधिक पाठक" योजना द्वारा वर्णित किया गया है। लेखक एक-दूसरे को रोकते हैं, लेकिन पाठकों को नहीं रोकते। पाठक लेखकों या एक-दूसरे को ब्लॉक नहीं करते।
नेस्टेड लेनदेन के लिए समर्थन.
बहुसंस्करण समर्थन.

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

एक परीक्षण प्रविष्टि जोड़ा जा रहा है

MDB_env *env;
MDB_dbi dbi;
MDB_txn *txn;

mdb_env_create(&env);
mdb_env_open(env, "./testdb", MDB_NOTLS, 0664);

mdb_txn_begin(env, NULL, 0, &txn);
mdb_dbi_open(txn, NULL, 0, &dbi);
mdb_txn_abort(txn);

char k = 'k';
MDB_val key;
key.mv_size = sizeof(k);
key.mv_data = (void *)&k;

int v = 997;
MDB_val value;
value.mv_size = sizeof(v);
value.mv_data = (void *)&v;

mdb_txn_begin(env, NULL, 0, &txn);
mdb_put(txn, dbi, &key, &value, MDB_NOOVERWRITE);
mdb_txn_commit(txn);

MDB_txn *txn1, *txn2, *txn3;
MDB_val val;

// Открываем 2 транзакции, каждая из которых смотрит
// на версию базы данных с одной записью.
mdb_txn_begin(env, NULL, 0, &txn1); // read-write
mdb_txn_begin(env, NULL, MDB_RDONLY, &txn2); // read-only

// В рамках первой транзакции удаляем из базы данных существующую в ней запись.
mdb_del(txn1, dbi, &key, NULL);
// Фиксируем удаление.
mdb_txn_commit(txn1);

// Открываем третью транзакцию, которая смотрит на
// актуальную версию базы данных, где записи уже нет.
mdb_txn_begin(env, NULL, MDB_RDONLY, &txn3);
// Убеждаемся, что запись по искомому ключу уже не существует.
assert(mdb_get(txn3, dbi, &key, &val) == MDB_NOTFOUND);
// Завершаем транзакцию.
mdb_txn_abort(txn3);

// Убеждаемся, что в рамках второй транзакции, открытой на момент
// существования записи в базе данных, её всё ещё можно найти по ключу.
assert(mdb_get(txn2, dbi, &key, &val) == MDB_SUCCESS);
// Проверяем, что по ключу получен не абы какой мусор, а валидные данные.
assert(*(int *)val.mv_data == 997);
// Завершаем транзакцию, работающей хоть и с устаревшей, но консистентной базой данных.
mdb_txn_abort(txn2);

मेरा सुझाव है कि आप SQLite के साथ भी यही ट्रिक आज़माएँ और देखें कि क्या होता है।

मल्टीवर्जन एक iOS डेवलपर के जीवन में बहुत अच्छे लाभ लाता है। इस संपत्ति का उपयोग करके, आप उपयोगकर्ता अनुभव के आधार पर स्क्रीन फॉर्म के लिए डेटा स्रोत की अद्यतन दर को आसानी से और स्वाभाविक रूप से समायोजित कर सकते हैं। उदाहरण के लिए, आइए Mail.ru क्लाउड एप्लिकेशन की एक सुविधा लें जैसे सिस्टम मीडिया गैलरी से सामग्री को ऑटोलोड करना। अच्छे कनेक्शन के साथ, क्लाइंट सर्वर पर प्रति सेकंड कई तस्वीरें जोड़ने में सक्षम है। यदि आप प्रत्येक डाउनलोड के बाद अपडेट करते हैं UICollectionView उपयोगकर्ता के क्लाउड में मीडिया सामग्री के साथ, आप इस प्रक्रिया के दौरान 60 एफपीएस और सुचारू स्क्रॉलिंग के बारे में भूल सकते हैं। बार-बार स्क्रीन अपडेट को रोकने के लिए, आपको किसी तरह अंतर्निहित में डेटा परिवर्तन की दर को सीमित करने की आवश्यकता है UICollectionViewDataSource.

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

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

कर्सर

कर्सर बी-ट्री ट्रैवर्सल के माध्यम से कुंजी-मूल्य जोड़े पर व्यवस्थित रूप से पुनरावृत्ति के लिए एक तंत्र प्रदान करते हैं। उनके बिना, डेटाबेस में तालिकाओं को प्रभावी ढंग से मॉडल करना असंभव होगा, जिस पर अब हम विचार कर रहे हैं।

4.2. टेबल मॉडलिंग

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

टेबल स्कीमा

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

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

कुंजियाँ और मानों को क्रमबद्ध करना

दुनिया में वस्तुओं को क्रमबद्ध करने की कई विधियों का आविष्कार किया गया है। चूँकि हमें गति के अलावा कोई अन्य आवश्यकता नहीं थी, इसलिए हमने अपने लिए सबसे तेज़ संभव विकल्प चुना - सी भाषा संरचना के एक उदाहरण द्वारा कब्जा की गई मेमोरी का एक डंप। इस प्रकार, एक निर्देशिका तत्व की कुंजी को निम्नलिखित संरचना के साथ मॉडल किया जा सकता है NodeKey.

typedef struct NodeKey {
    EntityId parentId;
    uint8_t type;
    uint8_t nameBuffer[256];
} NodeKey;

बचाने के लिए NodeKey वस्तु में भंडारण की आवश्यकता है MDB_val डेटा पॉइंटर को संरचना की शुरुआत के पते पर रखें, और फ़ंक्शन के साथ उनके आकार की गणना करें sizeof.

MDB_val serialize(NodeKey * const key) {
    return MDB_val {
        .mv_size = sizeof(NodeKey),
        .mv_data = (void *)key
    };
}

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

बाइनरी तुलनित्र के साथ कुंजियाँ ऑर्डर करना

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

याद रखने वाली पहली बात आदिम डेटा प्रकारों की स्मृति प्रतिनिधित्व है। इस प्रकार, सभी Apple उपकरणों पर, पूर्णांक चर प्रारूप में संग्रहीत होते हैं छोटा एंडियन. इसका मतलब यह है कि सबसे कम महत्वपूर्ण बाइट बाईं ओर होगी, और बाइट-दर-बाइट तुलना का उपयोग करके पूर्णांकों को क्रमबद्ध करना संभव नहीं होगा। उदाहरण के लिए, 0 से 511 तक की संख्याओं के सेट के साथ ऐसा करने का प्रयास करने से निम्नलिखित परिणाम प्राप्त होंगे।

// value (hex dump)
000 (0000)
256 (0001)
001 (0100)
257 (0101)
...
254 (fe00)
510 (fe01)
255 (ff00)
511 (ff01)

इस समस्या को हल करने के लिए, पूर्णांकों को बाइट-बाइट तुलनित्र के लिए उपयुक्त प्रारूप में कुंजी में संग्रहीत किया जाना चाहिए। परिवार के कार्य आपको आवश्यक परिवर्तन करने में मदद करेंगे hton* (विशेष रूप से htons उदाहरण से डबल-बाइट संख्याओं के लिए)।

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

दूसरी बात ध्यान रखने वाली है संरेखण सिद्धांत संरचना क्षेत्र संकलक। उनकी वजह से, फ़ील्ड के बीच मेमोरी में कचरा मान वाले बाइट्स बन सकते हैं, जो निश्चित रूप से, बाइट-बाइट सॉर्टिंग को तोड़ देता है। कचरे को खत्म करने के लिए, आपको या तो फ़ील्ड को कड़ाई से परिभाषित क्रम में घोषित करना होगा, संरेखण नियमों को ध्यान में रखना होगा, या संरचना घोषणा में विशेषता का उपयोग करना होगा packed.

बाहरी तुलनित्र के साथ कुंजियाँ ऑर्डर करना

बाइनरी तुलनित्र के लिए मुख्य तुलना तर्क बहुत जटिल हो सकता है। कई कारणों में से एक संरचनाओं के भीतर तकनीकी क्षेत्रों की उपस्थिति है। मैं एक निर्देशिका तत्व के लिए एक कुंजी के उदाहरण का उपयोग करके उनकी घटना का वर्णन करूंगा जो पहले से ही हमारे लिए परिचित है।

typedef struct NodeKey {
    EntityId parentId;
    uint8_t type;
    uint8_t nameBuffer[256];
} NodeKey;

अपनी सरलता के बावजूद, अधिकांश मामलों में यह बहुत अधिक मेमोरी की खपत करता है। नाम के लिए बफ़र 256 बाइट्स लेता है, हालाँकि औसत फ़ाइल और फ़ोल्डर नाम शायद ही कभी 20-30 वर्णों से अधिक होते हैं।

रिकॉर्ड के आकार को अनुकूलित करने की मानक तकनीकों में से एक इसे वास्तविक आकार में "ट्रिम" करना है। इसका सार यह है कि सभी चर-लंबाई फ़ील्ड की सामग्री संरचना के अंत में एक बफर में संग्रहीत की जाती है, और उनकी लंबाई अलग-अलग चर में संग्रहीत की जाती है। इस दृष्टिकोण के अनुसार, कुंजी NodeKey निम्नानुसार रूपांतरित किया गया है।

typedef struct NodeKey {
    EntityId parentId;
    uint8_t type;
    uint8_t nameLength;
    uint8_t nameBuffer[256];
} NodeKey;

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

MDB_val serialize(NodeKey * const key) {
    return MDB_val {
        .mv_size = offsetof(NodeKey, nameBuffer) + key->nameLength,
        .mv_data = (void *)key
    };
}

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

एलएमडीबी प्रत्येक डेटाबेस को अपना स्वयं का कुंजी तुलना फ़ंक्शन रखने की अनुमति देता है। यह फ़ंक्शन का उपयोग करके किया जाता है mdb_set_compare खोलने से पहले सख्ती से. स्पष्ट कारणों से, इसे डेटाबेस के पूरे जीवनकाल में नहीं बदला जा सकता है। तुलनित्र को इनपुट के रूप में बाइनरी प्रारूप में दो कुंजी प्राप्त होती है, और आउटपुट पर यह तुलना परिणाम लौटाता है: (-1) से कम, (1) से अधिक या (0) के बराबर। के लिए स्यूडोकोड NodeKey वैसा ही दिखता है.

int compare(MDB_val * const a, MDB_val * const b) {
    NodeKey * const aKey = (NodeKey * const)a->mv_data;
    NodeKey * const bKey = (NodeKey * const)b->mv_data;
    return // ...
}

जब तक डेटाबेस में सभी कुंजियाँ एक ही प्रकार की हैं, तब तक बिना शर्त उनके बाइट प्रतिनिधित्व को एप्लिकेशन कुंजी संरचना के प्रकार में डालना कानूनी है। यहां एक बारीकियां है, लेकिन इसकी चर्चा नीचे "रीडिंग रिकॉर्ड्स" उपधारा में की जाएगी।

मूल्यों को क्रमबद्ध करना

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

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

NSData *data = serialize(object);
MDB_val value = {
    .mv_size = data.length,
    .mv_data = (void *)data.bytes
};

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

सी भाषा में इसे लागू करने के लिए, उत्तराधिकारियों के विशिष्ट क्षेत्रों को अलग-अलग संरचनाओं में रखा जाता है, और आधार के साथ उनका संबंध प्रकार संघ के क्षेत्र के माध्यम से निर्दिष्ट किया जाता है। संघ की वास्तविक सामग्री तकनीकी विशेषता प्रकार के माध्यम से निर्दिष्ट की जाती है।

typedef struct NodeValue {
    EntityId localId;
    EntityType type;
    union {
        FileInfo file;
        DirectoryInfo directory;
    } info;
    uint8_t nameLength;
    uint8_t nameBuffer[256];
} NodeValue;

रिकार्ड जोड़ना एवं अद्यतन करना

क्रमबद्ध कुंजी और मूल्य को स्टोर में जोड़ा जा सकता है। ऐसा करने के लिए, फ़ंक्शन का उपयोग करें mdb_put.

// key и value имеют тип MDB_val
mdb_put(..., &key, &value, MDB_NOOVERWRITE);

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

प्रविष्टियाँ पढ़ना

एलएमडीबी में रिकॉर्ड पढ़ने के लिए, फ़ंक्शन का उपयोग करें mdb_get. यदि कुंजी-मूल्य जोड़ी को पहले डंप की गई संरचनाओं द्वारा दर्शाया जाता है, तो यह प्रक्रिया इस तरह दिखती है।

NodeValue * const readNode(..., NodeKey * const key) {
    MDB_val rawKey = serialize(key);
    MDB_val rawValue;
    mdb_get(..., &rawKey, &rawValue);
    return (NodeValue * const)rawValue.mv_data;
}

प्रस्तुत सूची से पता चलता है कि संरचना डंप के माध्यम से क्रमबद्धता आपको न केवल लिखते समय, बल्कि डेटा पढ़ते समय गतिशील आवंटन से छुटकारा पाने की अनुमति देती है। फ़ंक्शन से व्युत्पन्न mdb_get पॉइंटर बिल्कुल वर्चुअल मेमोरी एड्रेस को देखता है जहां डेटाबेस ऑब्जेक्ट के बाइट प्रतिनिधित्व को संग्रहीत करता है। वास्तव में, हमें एक प्रकार का ORM मिलता है जो बहुत अधिक डेटा पढ़ने की गति लगभग निःशुल्क प्रदान करता है। दृष्टिकोण की सारी सुंदरता के बावजूद, इससे जुड़ी कई विशेषताओं को याद रखना आवश्यक है।

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

अंत में, एक और विशेषता इतनी कपटपूर्ण है कि इसके सार को प्रकट करना किसी अन्य पैराग्राफ में फिट नहीं बैठता है। बी-ट्री के बारे में अध्याय में, मैंने एक आरेख दिया है कि इसके पृष्ठ स्मृति में कैसे व्यवस्थित हैं। इससे यह निष्कर्ष निकलता है कि क्रमबद्ध डेटा के साथ बफर की शुरुआत का पता बिल्कुल मनमाना हो सकता है। इस वजह से, उन्हें संरचना में सूचक प्राप्त हुआ MDB_val और एक संरचना के लिए एक सूचक तक कम हो जाने पर, यह सामान्य स्थिति में असंरेखित हो जाता है। उसी समय, कुछ चिप्स के आर्किटेक्चर (आईओएस के मामले में यह एआरएमवी7 है) के लिए आवश्यक है कि किसी भी डेटा का पता मशीन शब्द के आकार का एक गुणक हो या, दूसरे शब्दों में, सिस्टम का बिट आकार ( Armv7 के लिए यह 32 बिट है)। दूसरे शब्दों में, एक ऑपरेशन जैसा *(int *foo)0x800002 उन पर भागने के बराबर है और फैसले के साथ फांसी की सजा होती है EXC_ARM_DA_ALIGN. ऐसे दुखद भाग्य से बचने के दो तरीके हैं।

पहला स्पष्ट रूप से संरेखित संरचना में डेटा की प्रारंभिक प्रतिलिपि बनाने पर केंद्रित है। उदाहरण के लिए, एक कस्टम तुलनित्र पर यह इस प्रकार दिखाई देगा।

int compare(MDB_val * const a, MDB_val * const b) {
    NodeKey aKey, bKey;
    memcpy(&aKey, a->mv_data, a->mv_size);
    memcpy(&bKey, b->mv_data, b->mv_size);
    return // ...
}

एक वैकल्पिक तरीका यह है कि कंपाइलर को पहले से सूचित किया जाए कि कुंजी-मूल्य संरचनाएं विशेषता-संरेखित नहीं हो सकती हैं aligned(1). एआरएम पर आप समान प्रभाव डाल सकते हैं प्राप्त करना और पैक्ड विशेषता का उपयोग करना। हालाँकि, यह ध्यान में रखते हुए कि यह संरचना द्वारा घेरे गए स्थान को अनुकूलित करने में भी मदद करता है, यह विधि मुझे बेहतर लगती है приводит डेटा एक्सेस संचालन की लागत में वृद्धि।

typedef struct __attribute__((packed)) NodeKey {
    uint8_t parentId;
    uint8_t type;
    uint8_t nameLength;
    uint8_t nameBuffer[256];
} NodeKey;

श्रेणी प्रश्न

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

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

ऊपरी सीमा को अनुक्रमिक खोज द्वारा सीधे पाया जा सकता है। ऐसा करने के लिए, कर्सर को डेटाबेस में कुंजियों की पूरी सूची की शुरुआत में रखा जाता है और तब तक बढ़ाया जाता है जब तक कि मूल निर्देशिका के पहचानकर्ता के साथ एक कुंजी उसके नीचे दिखाई न दे। इस दृष्टिकोण के 2 स्पष्ट नुकसान हैं:

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

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

NodeKey upperBoundSearchKey = {
    .parentId = 2,
    .type = 0,
    .nameLength = 0
};
MDB_val value, key = serialize(upperBoundSearchKey);
MDB_cursor *cursor;
mdb_cursor_open(..., &cursor);
mdb_cursor_get(cursor, &key, &value, MDB_SET_RANGE);

यदि कुंजियों के समूह की ऊपरी सीमा मिल जाती है, तो हम उस पर तब तक दोहराते रहते हैं जब तक कि या तो हम नहीं मिल जाते या कुंजी किसी अन्य से नहीं मिल जाती parentId, या चाबियाँ बिल्कुल खत्म नहीं होंगी।

do {
    rc = mdb_cursor_get(cursor, &key, &value, MDB_NEXT);
    // processing...
} while (MDB_NOTFOUND != rc && // check end of table
         IsTargetKey(key));    // check end of keys group

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

4.3. तालिकाओं के बीच संबंधों की मॉडलिंग

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

Στρατός Assault - Παίξτε Funny Games

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

सूचकांक तालिकाएँ

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

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

सूचकांक कुंजी प्राथमिक कुंजी के समान डेटा को संदर्भित करती है। प्राथमिक कुंजी के मूल्य भाग की एक प्रति को इसके साथ जोड़कर इस संपत्ति का सीधा कार्यान्वयन कई दृष्टिकोणों से इष्टतम नहीं है:

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

आगे हम विचार करेंगे कि इन कमियों को कैसे दूर किया जाए।

तालिकाओं के बीच संबंधों को व्यवस्थित करना

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

तालिकाओं के बीच संबंधों को व्यवस्थित करने का एक अन्य पैटर्न है "अनावश्यक कुंजी". इसका सार कुंजी में अतिरिक्त विशेषताएँ जोड़ना है, जिनकी आवश्यकता सॉर्टिंग के लिए नहीं, बल्कि संबंधित कुंजी को फिर से बनाने के लिए है। Mail.ru क्लाउड एप्लिकेशन में इसके उपयोग के वास्तविक उदाहरण हैं, हालांकि, गहराई से जाने से बचने के लिए विशिष्ट आईओएस फ्रेमवर्क के संदर्भ में, मैं एक काल्पनिक, लेकिन एक स्पष्ट उदाहरण दूंगा

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

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

निष्कर्ष

हम एलएमडीबी के कार्यान्वयन के परिणामों का सकारात्मक मूल्यांकन करते हैं। इसके बाद एप्लिकेशन फ़्रीज़ होने की संख्या में 30% की कमी आई।

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

स्रोत: www.habr.com

आईओएस अनुप्रयोगों में कुंजी-मूल्य डेटाबेस एलएमडीबी की प्रतिभा और गरीबी