2019 को पतनमा, Mail.ru Cloud iOS टोलीमा लामो-प्रतीक्षित घटना भयो। एप्लिकेसन स्टेटको निरन्तर भण्डारणको लागि मुख्य डाटाबेस मोबाइल संसारको लागि धेरै विदेशी भएको छ लाइटनिङ मेमोरी म्याप गरिएको डाटाबेस (LMDB)। कट तल हामी तपाईंलाई चार भागहरूमा यसको विस्तृत समीक्षा प्रस्ताव गर्दछौं। पहिले, यस्तो गैर-तुच्छ र गाह्रो छनोटको कारणहरूको बारेमा कुरा गरौं। त्यसपछि हामी LMDB आर्किटेक्चरको मुटुमा रहेका तीनवटा स्तम्भहरूलाई विचार गर्न अगाडि बढ्नेछौं: मेमोरी-म्याप गरिएका फाइलहरू, B+-ट्री, लेनदेनशीलता र मल्टिभर्सन लागू गर्नको लागि प्रतिलिपि-अन-राइट दृष्टिकोण। अन्तमा, मिठाई लागि - व्यावहारिक भाग। यसमा हामी निम्न-स्तर कुञ्जी-मान API को शीर्षमा एक अनुक्रमणिका सहित धेरै तालिकाहरू सहित डेटाबेस स्किमा कसरी डिजाइन र कार्यान्वयन गर्ने भनेर हेर्नेछौं।

सामग्रीहरू

1. कार्यान्वयनको लागि प्रेरणा
2. LMDB स्थिति
3. LMDB को तीन स्तम्भ
   3.1। ह्वेल #1। मेमोरी म्याप गरिएका फाइलहरू
   3.2। ह्वेल #2। B+-रूख
   3.3। ह्वेल #3। प्रतिलिपि-अन-लेखन
4. कुञ्जी-मान API को शीर्षमा डेटा स्किमा डिजाइन गर्दै
   4.1। आधारभूत Abstractions
   4.2। तालिका मोडलिङ
   4.3। तालिकाहरू बीचको मोडलिङ सम्बन्ध

1. कार्यान्वयनको लागि प्रेरणा

2015 मा एक वर्ष, हामीले हाम्रो अनुप्रयोगको इन्टरफेस कति पटक ढिलो हुन्छ मापन गर्न समस्या उठायौं। हामीले यो एउटा कारणको लागि गर्‍यौं। हामीले धेरै बारम्बार गुनासोहरू प्राप्त गरेका छौं कि कहिलेकाहीँ अनुप्रयोगले प्रयोगकर्ताका कार्यहरूमा प्रतिक्रिया दिन रोक्छ: बटनहरू थिच्न सकिँदैन, सूचीहरू स्क्रोल गर्दैन, आदि। मापन को मेकानिक्स को बारे मा बताए AvitoTech मा, त्यसैले यहाँ म संख्याहरूको क्रम मात्र दिन्छु।

मापन परिणामहरू हाम्रो लागि चिसो स्नान भयो। यो बाहिर निस्कियो कि अन्य कुनै पनि भन्दा फ्रिजको कारण धेरै समस्याहरू छन्। यदि यो तथ्यलाई महसुस गर्नु अघि गुणस्तरको मुख्य प्राविधिक सूचक दुर्घटना मुक्त थियो, त्यसपछि फोकस पछि सारियो फ्रीज फ्री मा।

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

प्रणाली संगठनको अभिनेता मोडेलले मान्दछ कि मल्टिथ्रेडिङ यसको दोस्रो सार बन्छ। यसमा मोडेल वस्तुहरू स्ट्रिम सीमाहरू पार गर्न मन पराउँछन्। र तिनीहरू यो कहिलेकाहीं र यहाँ र त्यहाँ होइन, तर लगभग लगातार र जताततै गर्छन्

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

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

त्यसोभए, यदि तपाइँ git को कल्पना गर्नुहुन्छ, जुन पुल कमाण्ड कार्यान्वयन गर्दा, स्थानीय स्न्यापसटमा प्याचहरू लागू गर्नुको सट्टा, यसको पूर्ण स्थितिलाई पूर्ण सर्भर राज्यसँग तुलना गर्दछ, तब तपाइँसँग क्लाउडमा कसरी सिङ्क्रोनाइजेसन हुन्छ भन्ने बारे एकदम सही विचार हुनेछ। ग्राहकहरु। यो अनुमान गर्न सजिलो छ कि यसलाई कार्यान्वयन गर्न, तपाईंले सबै सर्भर र स्थानीय फाइलहरूको बारेमा मेटा-जानकारीको साथ मेमोरीमा दुई DOM रूखहरू आवंटित गर्न आवश्यक छ। यो बाहिर जान्छ कि यदि प्रयोगकर्ताले क्लाउडमा 500 हजार फाइलहरू भण्डारण गर्दछ, त्यसपछि यसलाई सिङ्क्रोनाइज गर्न 1 मिलियन नोडहरूसँग दुई रूखहरू पुन: सिर्जना र नष्ट गर्न आवश्यक छ। तर प्रत्येक नोड सबवजेक्टहरूको ग्राफ भएको समग्र हो। यस प्रकाशमा, प्रोफाइलिङ परिणामहरू अपेक्षित थिए। यो पत्ता लाग्यो कि मर्ज गर्ने एल्गोरिदमलाई ध्यानमा नलिई पनि, धेरै संख्यामा साना वस्तुहरू सिर्जना गर्ने र पछि नष्ट गर्ने प्रक्रियामा एक धेरै पैसा खर्च हुन्छ। आधारभूत सिंक्रोनाइजेसन अपरेशन ठूलो संख्यामा समावेश भएको तथ्यले अवस्था बिग्रिएको छ। प्रयोगकर्ता लिपिहरूको। नतिजाको रूपमा, हामीले डाटाबेस छनौट गर्न दोस्रो महत्त्वपूर्ण मापदण्ड ठीक गर्छौं - वस्तुहरूको गतिशील आवंटन बिना CRUD अपरेशनहरू कार्यान्वयन गर्ने क्षमता।

अन्य आवश्यकताहरू अधिक परम्परागत छन् र तिनीहरूको सम्पूर्ण सूची निम्नानुसार छ।

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

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

2. LMDB स्थिति निर्धारण

LMDB एक धेरै सानो पुस्तकालय हो (केवल 10K पङ्क्तिहरू) जसले डाटाबेसको सबैभन्दा तल्लो आधारभूत तह - भण्डारणलाई लागू गर्दछ।

माथिको रेखाचित्रले देखाउँछ कि LMDB को SQLite सँग तुलना गर्ने, जसले उच्च स्तरहरू पनि लागू गर्दछ, सामान्यतया कोर डाटाको साथ SQLite भन्दा बढी सही छैन। समान प्रतियोगीहरू - BerkeleyDB, LevelDB, Sophia, RocksDB, इत्यादिको रूपमा समान भण्डारण इन्जिनहरू उद्धृत गर्न अझ उचित हुनेछ। LMDB ले SQLite को लागि भण्डारण इन्जिन घटकको रूपमा काम गर्ने विकासहरू पनि छन्। पहिलो पटक यस्तो प्रयोग सन् २०१२ मा भएको थियो खर्च भयो LMDB द्वारा हावर्ड चु. Результаты यति चाखलाग्दो भयो कि उनको पहल OSS उत्साहीहरूले उठाए, र व्यक्तिमा यसको निरन्तरता पाए। LumoSQL। जनवरी २०२० मा, यस परियोजनाका लेखक डेन शियरर थिए प्रस्तुत LinuxConfAu मा।

LMDB मुख्यतया अनुप्रयोग डाटाबेसहरूको लागि इन्जिनको रूपमा प्रयोग गरिन्छ। पुस्तकालय यसको उपस्थिति विकासकर्ताहरूको लागि ऋणी छ ओपनएलडीएप, जो आफ्नो परियोजनाको आधारको रूपमा BerkeleyDB सँग अत्यधिक असन्तुष्ट थिए। एउटा सामान्य पुस्तकालयबाट सुरु गर्दै btree, हावर्ड चुले हाम्रो समयको सबैभन्दा लोकप्रिय विकल्पहरू मध्ये एक सिर्जना गर्न सक्षम थिए। उनले आफ्नो धेरै राम्रो रिपोर्ट यस कथामा, साथै LMDB को आन्तरिक संरचनामा समर्पित गरे। "बिजुली मेमोरी म्याप गरिएको डाटाबेस"। भण्डारण सुविधा जित्ने राम्रो उदाहरण लियोनिद युरिएभ (उर्फ yleoहाइलोड 2015 मा उनको रिपोर्टमा सकारात्मक टेक्नोलोजीबाट "LMDB इन्जिन एक विशेष च्याम्पियन हो"। यसमा, उहाँले ReOpenLDAP कार्यान्वयन गर्ने समान कार्यको सन्दर्भमा LMDB को बारेमा कुरा गर्नुहुन्छ, र LevelDB पहिले नै तुलनात्मक आलोचनाको विषय बनेको छ। कार्यान्वयनको नतिजाको रूपमा, सकारात्मक टेक्नोलोजीहरूमा सक्रिय रूपमा विकासशील फोर्क पनि थियो MDBX धेरै स्वादिष्ट सुविधाहरू, अनुकूलन र बग फिक्सहरू.

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

इन्जिनले मोबाइल विकासको संसारमा पनि आफ्नो छाप छोडेको छ। यसको प्रयोग को निशान हुन सक्छ найти टेलिग्रामको लागि iOS ग्राहकमा। LinkedIn अझ अगाडि बढ्यो र LMDB लाई यसको होमग्राउन डाटा क्यासिङ फ्रेमवर्क रकेट डाटाको लागि पूर्वनिर्धारित भण्डारणको रूपमा रोज्यो, जसको बारेमा बताए 2016 मा उनको लेखमा।

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

3. LMDB को तीन स्तम्भ

LMDB लाई चराको आँखाबाट हेरेपछि, यो गहिराइमा जाने समय थियो। अर्को तीन खण्डहरू मुख्य स्तम्भहरूको विश्लेषणमा समर्पित हुनेछन् जसमा भण्डारण वास्तुकला टिक्छ:

1. मेमोरी-म्याप गरिएको फाइलहरू डिस्कसँग काम गर्न र आन्तरिक डाटा संरचनाहरू सिङ्क्रोनाइज गर्नको लागि एक संयन्त्रको रूपमा।
2. भण्डार गरिएको डाटाको संरचनाको संगठनको रूपमा B+-ट्री।
3. ACID लेनदेन गुणहरू र बहुसंस्करण प्रदान गर्ने दृष्टिकोणको रूपमा प्रतिलिपि-अन-लेखन।

३.१। ह्वेल #3.1। मेमोरी म्याप गरिएका फाइलहरू

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

1. धेरै प्रक्रियाहरूबाट काम गर्दा भण्डारणमा डाटाको स्थिरता कायम राख्नु अपरेटिङ सिस्टमको जिम्मेवारी हुन्छ। अर्को खण्डमा, यो मेकानिक्सलाई विस्तृत रूपमा र चित्रहरू सहित छलफल गरिएको छ।
2. क्यासहरूको अनुपस्थितिले गतिशील आवंटनसँग सम्बन्धित ओभरहेडबाट LMDB लाई पूर्ण रूपमा हटाउँछ। अभ्यासमा डेटा पढ्नु भनेको भर्चुअल मेमोरीमा सही ठेगानामा पोइन्टर सेट गर्नु हो र अरू केही छैन। यो विज्ञान कथा जस्तो देखिन्छ, तर भण्डारण स्रोत कोडमा calloc मा सबै कलहरू भण्डारण कन्फिगरेसन प्रकार्यमा केन्द्रित छन्।
3. क्यासहरूको अनुपस्थिति भनेको तिनीहरूको पहुँचको सिंक्रोनाइजेसनसँग सम्बन्धित लकहरूको अनुपस्थिति हो। पाठकहरू, जसमध्ये एकै समयमा पाठकहरूको स्वेच्छाचारी संख्या हुन सक्छ, डेटामा जाने बाटोमा एकल म्युटेक्सको सामना गर्दैन। यस कारणले गर्दा, CPU को संख्यामा आधारित पठन गतिमा आदर्श रैखिक स्केलेबिलिटी हुन्छ। LMDB मा, परिमार्जन कार्यहरू मात्र सिङ्क्रोनाइज हुन्छन्। त्यहाँ एक पटकमा एक मात्र लेखक हुन सक्छ।
4. न्यूनतम क्यासिङ र सिङ्क्रोनाइजेसन तर्कले बहु-थ्रेड गरिएको वातावरणमा काम गर्नेसँग सम्बन्धित अत्यन्त जटिल प्रकारका त्रुटिहरूलाई हटाउँछ। Usenix OSDI 2014 सम्मेलनमा दुईवटा रोचक डाटाबेस अध्ययनहरू थिए: "सबै फाइल प्रणालीहरू समान रूपमा सिर्जना गरिएका छैनन्: क्र्यास-संगत अनुप्रयोगहरू क्राफ्टिङको जटिलतामा" и "रमाइलो र नाफाको लागि डाटाबेसहरूलाई यातना दिने"। तिनीहरूबाट तपाईले LMDB को अभूतपूर्व विश्वसनीयता र ACID लेनदेन गुणहरूको लगभग निर्दोष कार्यान्वयनको बारेमा जानकारी बटुल्न सक्नुहुन्छ, जुन SQLite भन्दा उच्च छ।
5. LMDB को minimalism ले यसको कोडको मेसिन प्रतिनिधित्वलाई आगामी गति विशेषताहरूसँग प्रोसेसरको L1 क्यासमा पूर्ण रूपमा अवस्थित हुन अनुमति दिन्छ।

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

मेमोरी म्याप गरिएका फाइलहरूको बारेमा सामान्य जानकारी

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

प्रक्रियामा आवंटित ठेगाना ठाउँ ठूलो छ। सैद्धान्तिक रूपमा, ठेगानाहरूको संख्या केवल सूचकको आकार द्वारा सीमित छ, जुन प्रणालीको बिट क्षमता द्वारा निर्धारण गरिन्छ। यदि भौतिक मेमोरीलाई 1-to-1 मा म्याप गरिएको थियो भने, त्यसपछि पहिलो प्रक्रियाले सम्पूर्ण RAM माथि जान्छ, र त्यहाँ कुनै पनि मल्टिटास्किङको कुरा हुँदैन।

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

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

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

एउटा महत्त्वपूर्ण nuance यो हो कि LMDB, पूर्वनिर्धारित रूपमा, लेखन प्रणाली कल संयन्त्र मार्फत डाटा फाइल परिमार्जन गर्दछ, र फाइललाई पढ्न-मात्र मोडमा प्रदर्शन गर्दछ। यस दृष्टिकोणले दुई महत्त्वपूर्ण परिणामहरू छन्।

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

दोस्रो परिणाम आईओएसको लागि पहिले नै विशिष्ट छ। न त लेखक वा अन्य कुनै स्रोतहरूले यसलाई स्पष्ट रूपमा उल्लेख गरेका छन्, तर यो बिना LMDB यस मोबाइल अपरेटिङ सिस्टममा चल्नको लागि उपयुक्त हुनेछैन। अर्को खण्ड यसको विचारमा समर्पित छ।

iOS मा मेमोरी म्याप गरिएका फाइलहरूको विशिष्टता

2018 मा WWDC मा एक अद्भुत रिपोर्ट थियो "iOS मेमोरी गहिरो डाइभ"। यसले हामीलाई बताउँछ कि iOS मा, भौतिक मेमोरीमा अवस्थित सबै पृष्ठहरू 3 प्रकारका हुन्छन्: फोहोर, संकुचित र सफा।

सफा मेमोरी पृष्ठहरूको संग्रह हो जुन भौतिक मेमोरीबाट पीडारहित रूपमा अनलोड गर्न सकिन्छ। तिनीहरूमा समावेश डाटा यसको मूल स्रोतहरूबाट आवश्यकता अनुसार पुन: लोड गर्न सकिन्छ। पढ्ने-मात्र मेमोरी-म्याप गरिएका फाइलहरू यस श्रेणीमा पर्छन्। iOS कुनै पनि समयमा मेमोरीबाट फाइलमा म्याप गरिएका पृष्ठहरू अनलोड गर्न डराउँदैन, किनकि तिनीहरू डिस्कमा रहेको फाइलसँग सिङ्क्रोनाइज हुने ग्यारेन्टी छन्।
​
सबै परिमार्जित पृष्ठहरू फोहोर मेमोरीमा समाप्त हुन्छन्, चाहे तिनीहरू मूल रूपमा अवस्थित थिए। विशेष गरी, तिनीहरूसँग सम्बन्धित भर्चुअल मेमोरीमा लेखेर परिमार्जन गरिएका मेमोरी-म्याप गरिएका फाइलहरूलाई यसरी वर्गीकृत गरिनेछ। झण्डा सहित LMDB खोल्दै MDB_WRITEMAP, यसमा परिवर्तन गरेपछि, तपाइँ यसलाई व्यक्तिगत रूपमा प्रमाणित गर्न सक्नुहुन्छ

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

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

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

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

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

३.२। ह्वेल #3.2। B+-रूख

कुञ्जी-मान भण्डारणको शीर्षमा तालिकाहरू अनुकरण गर्न, निम्न कार्यहरू यसको API मा उपस्थित हुनुपर्छ:

1. नयाँ तत्व सम्मिलित गर्दै।
2. दिइएको कुञ्जीको साथ एक तत्व खोज्नुहोस्।
3. तत्व हटाउँदै।
4. कुञ्जीहरू क्रमबद्ध गरिएको क्रममा अन्तरालहरूमा दोहोर्याउनुहोस्।

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

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

बी-ट्रीहरू, बाइनरी रूखहरूको विकासको रूपमा, अघिल्लो अनुच्छेदमा पहिचान गरिएका समस्याहरू समाधान गर्नुहोस्। पहिलो, तिनीहरू आत्म-संतुलित छन्। दोस्रो, तिनीहरूको प्रत्येक नोडले चाइल्ड कुञ्जीहरूको सेटलाई 2 मा होइन, तर M अर्डर गरिएका सबसेटहरूमा विभाजन गर्दछ, र संख्या M धेरै ठूलो हुन सक्छ, धेरै सय वा हजारौंको क्रममा।

यसरी:

1. प्रत्येक नोडले पहिले नै अर्डर गरिएका कुञ्जीहरूको ठूलो संख्या समावेश गर्दछ र रूखहरू धेरै छोटो छन्।
2. रूखले मेमोरीमा स्थानको स्थानीयताको गुण प्राप्त गर्दछ, किनकि मूल्यमा नजिक भएका कुञ्जीहरू स्वाभाविक रूपमा समान वा छिमेकी नोडहरूमा एकअर्काको छेउमा अवस्थित हुन्छन्।
3. खोजी कार्यको क्रममा रूख ओर्लँदा ट्रान्जिट नोडहरूको संख्या घटाइएको छ।
4. दायरा प्रश्नहरूको समयमा पढ्ने लक्ष्य नोडहरूको संख्या घटाइएको छ, किनकि तिनीहरूमध्ये प्रत्येकमा पहिले नै अर्डर गरिएका कुञ्जीहरूको ठूलो संख्या समावेश छ।

LMDB ले डाटा भण्डारण गर्न B+ ट्री भनिने B-ट्रीको भिन्नता प्रयोग गर्दछ। माथिको रेखाचित्रले यसमा अवस्थित तीन प्रकारका नोडहरू देखाउँछ:

1. शीर्षमा जरा छ। यसले गोदाम भित्रको डेटाबेसको अवधारणा बाहेक अरू केहि गर्दैन। एक LMDB उदाहरण भित्र, तपाईले धेरै डाटाबेसहरू सिर्जना गर्न सक्नुहुन्छ जुन म्याप गरिएको भर्चुअल ठेगाना स्थान साझा गर्दछ। तिनीहरूमध्ये प्रत्येक आफ्नै जराबाट सुरु हुन्छ।
2. तल्लो तहमा पातहरू छन्। तिनीहरू र केवल तिनीहरूले डाटाबेसमा भण्डारण गरिएका कुञ्जी-मान जोडीहरू समावेश गर्दछ। खैर, यो B+-रूखहरूको विशेषता हो। यदि नियमित B-ट्रीले सबै तहका नोडहरूमा मूल्यका भागहरू भण्डारण गर्छ भने, B+ भिन्नता सबैभन्दा कम मात्र हुन्छ। यस तथ्यलाई निश्चित गरिसकेपछि, हामी LMDB मा प्रयोग गरिएको रूखको उपप्रकारलाई केवल एक B-ट्री भन्नेछौं।
3. जरा र पातहरू बीच नेभिगेसनल (शाखा) नोडहरूसँग ० वा बढी प्राविधिक स्तरहरू छन्। तिनीहरूको कार्य पातहरू बीच कुञ्जीहरूको क्रमबद्ध सेट विभाजन गर्न हो।

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

पृष्ठ नोडहरूको आन्तरिक सामग्रीसँग व्यवहार गरिसकेपछि, हामी निम्न फारममा LMDB B-tree लाई सरल रूपमा प्रस्तुत गर्नेछौं।

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

अब, तथ्याङ्क संगठनको तार्किक र भौतिक संरचनाको एक विचार लिएर, हामी LMDB को तेस्रो स्तम्भलाई विचार गर्न अगाडि बढ्न सक्छौं। यो यसको मद्दतले सबै भण्डारण परिमार्जनहरू लेनदेन र एकअर्काबाट अलगावमा हुन्छन्, डाटाबेसलाई समग्र रूपमा बहुसंस्करणको सम्पत्ति प्रदान गर्दै।

३.३। ह्वेल #3.3। प्रतिलिपि-अन-लेखन

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

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

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

अर्को, अद्यावधिक गरिएको डाटा उपलब्ध हुनको लागि, यो नोडको लिङ्क परिवर्तन गर्न आवश्यक छ जुन यसको अभिभावक नोडमा हालको भएको छ। यसका लागि पनि परिमार्जन गर्नुपर्ने भएकाले त्यसको नक्कल पनि पहिल्यै गर्नुपर्छ । प्रक्रिया जरा सम्म पुनरावृत्ति जारी रहन्छ। परिवर्तन गर्न अन्तिम कुरा मेटा पृष्ठमा डाटा हो

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

नतिजा डिजाइन, append-only B-tree भनिन्छ, स्वाभाविक रूपमा लेनदेन अलगाव र बहु-संस्करण प्रदान गर्दछ। LMDB मा, प्रत्येक खुला लेनदेन हालको सान्दर्भिक रूख रूटसँग सम्बन्धित छ। लेनदेन पूरा नभएसम्म, यससँग सम्बन्धित रूखका पृष्ठहरू डेटाको नयाँ संस्करणहरूको लागि कहिल्यै परिवर्तन वा पुन: प्रयोग गरिने छैन। यसरी, तपाईंले त्यतिबेला सान्दर्भिक डेटाको सेटसँग आफूले चाहेको लामो समयसम्म काम गर्न सक्नुहुन्छ। यस समयमा भण्डारण सक्रिय रूपमा अद्यावधिक हुन जारी राखे पनि कारोबार खोलिएको थियो। यो बहुसंस्करणको सार हो, LMDB लाई हाम्रा प्रियजनहरूको लागि एक आदर्श डेटा स्रोत बनाउँदै UICollectionView। लेनदेन खोलिसकेपछि, केहि पनि बाँकी नहोस् भन्ने डरले हतारमा हालको डाटालाई केही इन-मेमोरी संरचनामा पम्प गरेर एप्लिकेसनको मेमोरी फुटप्रिन्ट बढाउन आवश्यक छैन। यो सुविधाले LMDB लाई समान SQLite बाट अलग गर्छ, जसले यस्तो कुल अलगावको घमण्ड गर्न सक्दैन। पछिल्लोमा दुईवटा कारोबार खोलेर ती मध्ये एउटा भित्रको निश्चित अभिलेख मेटाएपछि, बाँकी रहेको दोस्रोमा सोही अभिलेख प्राप्त गर्न सम्भव हुने छैन।

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

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

4. कुञ्जी-मान API को शीर्षमा डेटा स्किमा डिजाइन गर्दै

LMDB द्वारा प्रदान गरिएको आधारभूत एब्स्ट्र्याक्सनहरू हेरेर हाम्रो API विश्लेषण सुरु गरौं: वातावरण र डाटाबेसहरू, कुञ्जीहरू र मानहरू, लेनदेनहरू र कर्सरहरू।

कोड सूची बारे एक नोट

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

IOS वा macOS को लागि LMDB लाई प्रोजेक्टमा जडान गर्ने सबैभन्दा छिटो तरिकाको रूपमा, म मेरो CocoaPod सुझाव दिन्छु POSLMDB.

4.1. आधारभूत अमूर्तहरू

वातावरण

संरचना MDB_env LMDB को आन्तरिक अवस्थाको भण्डार हो। उपसर्ग समारोह परिवार 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 क्लाउड अनुप्रयोगमा, हामीले केवल दुई प्यारामिटरहरूको पूर्वनिर्धारित मानहरू परिवर्तन गर्यौं।

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

दोस्रो प्यारामिटर, जसको पूर्वनिर्धारित मानले हामीलाई उपयुक्त गर्दैन, थ्रेड सुरक्षा सुनिश्चित गर्ने मेकानिक्सलाई विनियमित गर्दछ। दुर्भाग्यवश, कम्तिमा iOS 10 मा थ्रेड स्थानीय भण्डारणको लागि समर्थनको साथ समस्याहरू छन्। यस कारणको लागि, माथिको उदाहरणमा, भण्डार झण्डाको साथ खोलिएको छ MDB_NOTLS। यसका अतिरिक्त यो आवश्यक पनि थियो काँटा C++ र्यापर 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);

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

कुञ्जी र मानहरू

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

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

तुलनाकर्ता प्रयोग गरेर, स्टोरले कुञ्जीहरूलाई बढ्दो क्रममा क्रमबद्ध गर्दछ। यदि तपाइँ यसलाई तपाइँको आफ्नै संग प्रतिस्थापन गर्नुहुन्न भने, पूर्वनिर्धारित एक प्रयोग गरिनेछ, जसले तिनीहरूलाई लेक्सोग्राफिक क्रममा बाइट-द्वारा-बाइट क्रमबद्ध गर्दछ।

लेनदेन

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

1. सबै आधारभूत गुणहरूलाई समर्थन गर्दछ एसिड: परमाणु, स्थिरता, अलगाव र विश्वसनीयता। म मद्दत गर्न सक्दिन तर नोट गर्नुहोस् कि macOS र iOS मा स्थायित्वको सर्तमा बग छ जुन MDBX मा फिक्स गरिएको थियो। तपाईं तिनीहरूमा थप पढ्न सक्नुहुन्छ पढ्नुहोस्.
2. मल्टिथ्रेडिङको दृष्टिकोण "एकल लेखक / बहु पाठक" योजना द्वारा वर्णन गरिएको छ। लेखकहरूले एकअर्कालाई रोक्छन्, तर पाठकहरूलाई रोक्दैनन्। पाठकहरूले लेखक वा एक अर्कालाई रोक्दैनन्।
3. नेस्टेड लेनदेनको लागि समर्थन।
4. Multiversion समर्थन।

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

परीक्षण प्रविष्टि थप्दै

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 को साथ उही चाल कोसिस गर्नुहोस् र हेर्नुहोस् के हुन्छ।

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

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

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

कर्सरहरू

कर्सरहरूले B-tree traversal मार्फत कुञ्जी-मान जोडीहरूमा क्रमबद्ध रूपमा पुनरावृत्तिको लागि एक संयन्त्र प्रदान गर्दछ। तिनीहरू बिना, डाटाबेसमा तालिकाहरू प्रभावकारी रूपमा मोडेल गर्न असम्भव हुनेछ, जुन हामी अब फर्कन्छौं।

४.२। तालिका मोडलिङ

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

तालिका योजना

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

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

क्रमबद्ध कुञ्जी र मानहरू

संसारमा वस्तुहरू क्रमबद्ध गर्ने धेरै विधिहरू आविष्कार गरिएका छन्। हामीसँग गति बाहेक अरू कुनै आवश्यकता नभएकोले, हामीले आफ्नो लागि सबैभन्दा छिटो छनोट गर्यौं - C भाषा संरचनाको उदाहरणले ओगटेको मेमोरीको डम्प। यसरी, डाइरेक्टरी तत्वको कुञ्जीलाई निम्न संरचनासँग मोडेल गर्न सकिन्छ। 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
    };
}

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

बाइनरी तुलनाकर्तासँग कुञ्जीहरू क्रमबद्ध गर्दै

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

याद गर्न को लागी पहिलो कुरा आदिम डेटा प्रकार को मेमोरी प्रतिनिधित्व हो। यसरी, सबै एप्पल उपकरणहरूमा, पूर्णांक चरहरू ढाँचामा भण्डारण गरिन्छ सानो Endian। यसको मतलब कम्तिमा महत्त्वपूर्ण बाइट बायाँमा हुनेछ, र बाइट-द्वारा-बाइट तुलना प्रयोग गरेर पूर्णांकहरू क्रमबद्ध गर्न सम्भव छैन। उदाहरण को लागी, 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 बाइटहरू लिन्छ, यद्यपि औसत फाइल र फोल्डर नामहरू विरलै २०-३० क्यारेक्टरहरू भन्दा बढी हुन्छन्।

रेकर्डको साइज अप्टिमाइज गर्ने एक मानक प्रविधि भनेको यसलाई वास्तविक साइजमा "ट्रिम" गर्नु हो। यसको सार यो हो कि सबै चर-लम्बाइ क्षेत्रहरूको सामग्रीहरू संरचनाको अन्त्यमा बफरमा भण्डार गरिएको छ, र तिनीहरूको लम्बाइहरू अलग-अलग चरहरूमा भण्डार गरिएको छ। यो दृष्टिकोण अनुसार, कुञ्जी 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, पूर्वनिर्धारित बाइनरी तुलनाकर्ता अब कुञ्जी तुलनाको लागि उपयुक्त छैन। यदि हामीले यसलाई आफ्नै संग प्रतिस्थापन गर्दैनौं भने, नामको लम्बाइ नाम भन्दा क्रमबद्ध गर्न उच्च प्राथमिकता कारक हुनेछ।

LMDB ले प्रत्येक डाटाबेसको आफ्नै मुख्य तुलना प्रकार्य हुन अनुमति दिन्छ। यो प्रकार्य प्रयोग गरेर गरिन्छ mdb_set_compare खोल्नु अघि कडाईका साथ। स्पष्ट कारणहरूका लागि, यो डाटाबेसको जीवनभर परिवर्तन गर्न सकिँदैन। तुलनाकर्ताले इनपुटको रूपमा बाइनरी ढाँचामा दुई कुञ्जीहरू प्राप्त गर्दछ, र आउटपुटमा यसले तुलना परिणाम फर्काउँछ: (-१) भन्दा कम, (१) भन्दा ठूलो वा (०) बराबर। का लागि स्यूडोकोड 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 // ...
}​

जबसम्म डाटाबेसका सबै कुञ्जीहरू एउटै प्रकारका हुन्छन्, बिना शर्त तिनीहरूको बाइट प्रतिनिधित्वलाई एप्लिकेसन कुञ्जी संरचनाको प्रकारमा कास्ट गर्नु कानूनी हुन्छ। यहाँ एउटा सूक्ष्मता छ, तर यसलाई तल "रीडिङ रेकर्डहरू" उपखण्डमा छलफल गरिनेछ।

क्रमबद्ध मानहरू

LMDB ले भण्डारण गरिएका रेकर्डहरूको कुञ्जीहरूसँग अत्यन्त गहन रूपमा काम गर्दछ। एकअर्कासँग तिनीहरूको तुलना कुनै पनि लागू अपरेशनको ढाँचा भित्र हुन्छ, र सम्पूर्ण समाधानको प्रदर्शन तुलनाकर्ताको गतिमा निर्भर गर्दछ। एक आदर्श संसारमा, पूर्वनिर्धारित बाइनरी तुलनाकर्ता कुञ्जीहरू तुलना गर्न पर्याप्त हुनुपर्छ, तर यदि तपाईंले आफ्नै प्रयोग गर्नुपर्‍यो भने, त्यसमा कुञ्जीहरूलाई डिसेरियलाइज गर्ने प्रक्रिया सकेसम्म छिटो हुनुपर्छ।

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

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

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

यसलाई C भाषामा लागू गर्न, उत्तराधिकारीहरूको विशिष्ट क्षेत्रहरू अलग संरचनाहरूमा राखिएको छ, र आधार एकसँग तिनीहरूको जडान प्रकार संघको क्षेत्र मार्फत निर्दिष्ट गरिएको छ। संघको वास्तविक सामग्री प्राविधिक विशेषता प्रकार मार्फत निर्दिष्ट गरिएको छ।

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।

प्रविष्टिहरू पढ्दै

LMDB मा रेकर्डहरू पढ्न, प्रकार्य प्रयोग गर्नुहोस् 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 पाउँछौं जसले धेरै उच्च डाटा पढ्ने गति लगभग निःशुल्क प्रदान गर्दछ। दृष्टिकोण को सबै सुन्दरता को बावजूद, यो संग सम्बन्धित धेरै सुविधाहरू सम्झना आवश्यक छ।

1. केवल पढ्ने लेनदेनको लागि, मूल्य संरचनाको सूचक लेनदेन बन्द नभएसम्म मात्र मान्य रहने ग्यारेन्टी गरिन्छ। पहिले उल्लेख गरिएझैं, B-ट्री पृष्ठहरू जसमा वस्तु अवस्थित छ, प्रतिलिपि-अन-राइट सिद्धान्तको लागि धन्यवाद, कम्तिमा एउटा लेनदेनद्वारा सन्दर्भित भएसम्म अपरिवर्तित रहन्छ। एकै समयमा, तिनीहरूसँग सम्बन्धित अन्तिम लेनदेन पूरा हुने बित्तिकै, पृष्ठहरू नयाँ डेटाको लागि पुन: प्रयोग गर्न सकिन्छ। यदि वस्तुहरू लेनदेन बाँच्नको लागि आवश्यक छ जसले तिनीहरूलाई उत्पन्न गरेको छ, त्यसपछि तिनीहरू अझै पनि प्रतिलिपि गर्नुपर्छ।
2. रिडराईट लेनदेनको लागि, नतिजा मान संरचनामा सूचक पहिलो परिमार्जन प्रक्रिया (डेटा लेख्ने वा मेटाउने) सम्म मात्र मान्य हुनेछ।
3. यद्यपि संरचना NodeValue पूर्ण रूपमा होइन, तर ट्रिम गरिएको (उपखण्ड "बाह्य तुलनाकर्ता प्रयोग गरेर कुञ्जीहरू अर्डर गर्ने" हेर्नुहोस्), तपाईंले सूचक मार्फत सुरक्षित रूपमा यसको क्षेत्रहरू पहुँच गर्न सक्नुहुन्छ। मुख्य कुरा यो dereference छैन!
4. कुनै पनि परिस्थितिमा प्राप्त सूचक मार्फत संरचना परिमार्जन गर्नु हुँदैन। सबै परिवर्तन विधि मार्फत मात्र गर्नुपर्छ mdb_put। यद्यपि, तपाईले यो गर्न चाहेको जतिसुकै कठिन भएता पनि, यो सम्भव हुने छैन, किनकि मेमोरी क्षेत्र जहाँ यो संरचना अवस्थित छ पढ्न मात्र मोडमा म्याप गरिएको छ।
5. फाइललाई प्रक्रिया ठेगाना स्पेसमा पुन: म्याप गर्नुहोस्, उदाहरणका लागि, प्रकार्य प्रयोग गरेर अधिकतम भण्डारण आकार बढाउनुहोस् mdb_env_set_map_size सामान्य रूपमा सबै लेनदेन र सम्बन्धित निकायहरूलाई पूर्ण रूपमा अमान्य बनाउँछ र विशेष रूपमा निश्चित वस्तुहरूमा संकेत गर्दछ।

अन्तमा, अर्को विशेषता यति कपटी छ कि यसको सार प्रकट गर्नु अर्को अनुच्छेदमा फिट हुँदैन। बी-ट्रीको बारेमा अध्यायमा, मैले यसको पृष्ठहरू मेमोरीमा कसरी व्यवस्थित छन् भनेर चित्रण दिएँ। यो क्रमबद्ध डाटा संग बफर को शुरुवात को ठेगाना बिल्कुल मनमाना हुन सक्छ कि यसबाट पछ्याउँछ। यस कारण, संरचनामा तिनीहरूलाई सूचक प्राप्त भयो MDB_val र संरचनाको लागि सूचकमा घटाइयो, यो सामान्य अवस्थामा असंरेखित हुन्छ। एकै समयमा, केहि चिप्स को आर्किटेक्चर (आईओएस को मामला मा यो armv7 हो) को आवश्यकता छ कि कुनै पनि डाटा को ठेगाना मेसिन शब्द को आकार को एक गुणन हो वा, अन्य शब्दहरुमा, प्रणाली को बिट आकार (। 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)। ARM मा तपाइँले समान प्रभाव पार्न सक्नुहुन्छ हासिल गर्ने र प्याक गरिएको विशेषता प्रयोग गर्दै। यसले संरचनाले ओगटेको ठाउँलाई अनुकूलन गर्न पनि मद्दत गर्दछ भन्ने कुरालाई ध्यानमा राख्दै, यो विधि मलाई उपयुक्त देखिन्छ, यद्यपि приводит डाटा पहुँच सञ्चालनको लागतमा वृद्धि गर्न।

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

दायरा प्रश्नहरू

रेकर्डहरूको समूहमा पुनरावृत्ति गर्न, LMDB ले कर्सर अमूर्तता प्रदान गर्दछ। हामीलाई पहिले नै परिचित प्रयोगकर्ता क्लाउड मेटाडाटाको साथ तालिकाको उदाहरण प्रयोग गरेर यसको साथ कसरी काम गर्ने भनेर हेरौं।

डाइरेक्टरीमा फाइलहरूको सूची प्रदर्शन गर्ने भागको रूपमा, यसको चाइल्ड फाइलहरू र फोल्डरहरू सम्बन्धित सबै कुञ्जीहरू फेला पार्न आवश्यक छ। अघिल्लो उपखण्डहरूमा हामीले कुञ्जीहरू क्रमबद्ध गर्यौं NodeKey जस्तै कि तिनीहरू मुख्य रूपमा अभिभावक डाइरेक्टरीको ID द्वारा अर्डर गरिएका छन्। यसरी, प्राविधिक रूपमा, फोल्डरको सामग्रीहरू पुन: प्राप्त गर्ने कार्य दिइएको उपसर्गको साथ कुञ्जीहरूको समूहको माथिल्लो सिमानामा कर्सर राख्ने र त्यसपछि तल्लो सीमामा दोहोर्याउन तल आउँछ।

माथिल्लो सीमा सीधा अनुक्रमिक खोज द्वारा फेला पार्न सकिन्छ। यो गर्नको लागि, कर्सर डाटाबेसमा कुञ्जीहरूको सम्पूर्ण सूचीको सुरुमा राखिएको छ र यसको तल मूल डाइरेक्टरीको पहिचानकर्ताको साथ कुञ्जी नदेख्दासम्म थप वृद्धि हुन्छ। यस दृष्टिकोणमा 2 स्पष्ट हानिहरू छन्:

1. रैखिक खोज जटिलता, यद्यपि, सामान्य रूपमा रूखहरूमा र विशेष रूपमा B-ट्रीमा यो लगरिदमिक समयमा गर्न सकिन्छ।
2. व्यर्थमा, खोजिएको भन्दा अघिका सबै पृष्ठहरू फाइलबाट मुख्य मेमोरीमा उठाइन्छ, जुन अत्यन्त महँगो छ।

सौभाग्यवश, LMDB API ले कर्सरलाई प्रारम्भिक रूपमा राख्नको लागि प्रभावकारी तरिका प्रदान गर्दछ। यो गर्नको लागि, तपाईंले एउटा कुञ्जी उत्पन्न गर्न आवश्यक छ जसको मान स्पष्ट रूपमा अन्तरालको माथिल्लो सीमामा रहेको कुञ्जीभन्दा कम वा बराबर छ। उदाहरणका लागि, माथिको चित्रमा सूचीको सम्बन्धमा, हामी कुञ्जी बनाउन सक्छौं जसमा फिल्ड 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 प्रयोग गरेर पुनरावृत्तिको भागको रूपमा, हामीले कुञ्जी मात्र होइन, मान पनि पाउँछौं। यदि, नमूना सर्तहरू पूरा गर्नको लागि, तपाईंले अन्य चीजहरू बीच, रेकर्डको मान भागबाट क्षेत्रहरू जाँच गर्न आवश्यक छ, त्यसपछि तिनीहरू अतिरिक्त इशाराहरू बिना नै पहुँचयोग्य छन्।

४.३। तालिकाहरू बीचको मोडलिङ सम्बन्ध

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

​

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

अनुक्रमणिका तालिकाहरू

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

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

अनुक्रमणिका कुञ्जीले प्राथमिक कुञ्जीको रूपमा समान डेटालाई सन्दर्भ गर्दछ। प्राथमिक कुञ्जीको मान अंशको प्रतिलिपिसँग सम्बद्ध गरेर यस गुणको सीधा कार्यान्वयन धेरै दृष्टिकोणबाट इष्टतम छैन:

1. लिइएको ठाउँको सन्दर्भमा, मेटाडेटा धेरै धनी हुन सक्छ।
2. कार्यसम्पादन दृष्टिकोणबाट, नोडको मेटाडेटा अद्यावधिक गर्दा, तपाईंले दुई कुञ्जीहरू प्रयोग गरेर यसलाई पुन: लेख्नुपर्नेछ।
3. कोड समर्थनको दृष्टिकोणबाट, यदि हामीले एउटा कुञ्जीको लागि डाटा अपडेट गर्न बिर्स्यौं भने, हामीले भण्डारणमा डाटा असंगतताको मायालु बग प्राप्त गर्नेछौं।

अर्को, हामी यी कमजोरीहरूलाई कसरी हटाउने भनेर विचार गर्नेछौं।

तालिकाहरू बीच सम्बन्धहरू व्यवस्थित गर्दै

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

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

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

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

निष्कर्ष

हामी LMDB को कार्यान्वयनको नतिजालाई सकारात्मक रूपमा मूल्याङ्कन गर्छौं। यसको पछि, अनुप्रयोग फ्रिजहरूको संख्या 30% ले घट्यो।

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

स्रोत: www.habr.com