2019 च्या शरद ऋतूमध्ये, Mail.ru क्लाउड iOS टीममध्ये एक बहुप्रतिक्षित घटना घडली. ऍप्लिकेशन स्टेटच्या पर्सिस्टंट स्टोरेजचा मुख्य डेटाबेस मोबाईल जगतासाठी अतिशय विलक्षण बनला आहे लाइटनिंग मेमरी-मॅप केलेला डेटाबेस (एलएमडीबी). कट खाली आम्ही तुम्हाला चार भागांमध्ये त्याचे तपशीलवार पुनरावलोकन ऑफर करतो. प्रथम, अशा गैर-क्षुल्लक आणि कठीण निवडीच्या कारणांबद्दल बोलूया. त्यानंतर आपण LMDB आर्किटेक्चरच्या केंद्रस्थानी असलेल्या तीन स्तंभांचा विचार करू: मेमरी-मॅप केलेल्या फाइल्स, B+-ट्री, व्यवहार आणि मल्टीव्हर्शन लागू करण्यासाठी कॉपी-ऑन-राइट दृष्टिकोन. शेवटी, मिष्टान्न साठी - व्यावहारिक भाग. त्यामध्ये आम्ही निम्न-स्तरीय की-व्हॅल्यू API च्या शीर्षस्थानी एका निर्देशांकासह अनेक सारण्यांसह डेटाबेस स्कीमा कसा डिझाइन आणि अंमलात आणायचा ते पाहू.

सामग्री

1. अंमलबजावणीसाठी प्रेरणा
2. LMDB पोझिशनिंग
3. LMDB चे तीन खांब
   3.1. व्हेल #1. मेमरी-मॅप केलेल्या फायली
   3.2. व्हेल #2. B+ झाड
   3.3. व्हेल #3. कॉपी-ऑन-राइट
4. की-व्हॅल्यू API च्या शीर्षस्थानी डेटा स्कीमा डिझाइन करणे
   4.1. मूलभूत अमूर्तता
   4.2. टेबल मॉडेलिंग
   4.3. टेबल दरम्यान मॉडेलिंग संबंध

1. अंमलबजावणीसाठी प्रेरणा

2015 मध्ये एक वर्ष, आम्ही आमच्या ऍप्लिकेशनचा इंटरफेस किती वेळा मागे पडतो हे मोजण्यासाठी त्रास घेतला. आम्ही हे एका कारणासाठी केले. आम्हाला वारंवार तक्रारी प्राप्त झाल्या आहेत की काहीवेळा अनुप्रयोग वापरकर्त्याच्या क्रियांना प्रतिसाद देणे थांबवतो: बटणे दाबली जाऊ शकत नाहीत, सूची स्क्रोल करत नाहीत इ. मोजमापांच्या यांत्रिकीबद्दल सांगितले AvitoTech वर, म्हणून मी येथे फक्त संख्यांचा क्रम देतो.

मापन परिणाम आमच्यासाठी थंड शॉवर बनले. असे दिसून आले की फ्रीझमुळे इतर कोणत्याही समस्यांपेक्षा जास्त समस्या आहेत. जर ही वस्तुस्थिती लक्षात घेण्यापूर्वी गुणवत्तेचे मुख्य तांत्रिक निर्देशक क्रॅश मुक्त होते, नंतर फोकस केल्यानंतर स्थलांतरित फ्रीज फ्री वर.

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

सिस्टम ऑर्गनायझेशनचे अभिनेता मॉडेल असे गृहीत धरते की मल्टीथ्रेडिंग त्याचे दुसरे सार बनते. त्यातील मॉडेल वस्तूंना प्रवाहाच्या सीमा ओलांडणे आवडते. आणि ते हे कधी-कधी आणि इकडे-तिकडे करत नाहीत, तर जवळजवळ सतत आणि सगळीकडे करतात

प्रस्तुत आकृतीमधील कोनशिला घटकांपैकी एक डेटाबेस आहे. मॅक्रोपॅटर्नची अंमलबजावणी करणे हे त्याचे मुख्य कार्य आहे शेअर केलेला डेटाबेस. जर एंटरप्राइझ जगात ते सेवांमधील डेटा सिंक्रोनाइझेशन आयोजित करण्यासाठी वापरले जाते, तर अभिनेता आर्किटेक्चरच्या बाबतीत - थ्रेड्समधील डेटा. अशाप्रकारे, आम्हाला एका डेटाबेसची आवश्यकता आहे ज्यामुळे मल्टी-थ्रेडेड वातावरणात त्याच्यासोबत काम करताना अगदी कमी अडचणी येणार नाहीत. विशेषतः, याचा अर्थ असा आहे की त्यातून मिळवलेल्या वस्तू कमीतकमी धागा-सुरक्षित आणि आदर्शपणे पूर्णपणे नॉन-म्युटेबल असणे आवश्यक आहे. आपल्याला माहिती आहे की, नंतरचे कोणत्याही लॉकिंगचा अवलंब न करता एकाच वेळी अनेक थ्रेड्समधून वापरले जाऊ शकते, ज्याचा कार्यक्षमतेवर फायदेशीर प्रभाव पडतो.

डेटाबेसच्या निवडीवर परिणाम करणारा दुसरा महत्त्वाचा घटक म्हणजे आमचा क्लाउड API. हे गिटने स्वीकारलेल्या सिंक्रोनायझेशनच्या दृष्टिकोनातून प्रेरित होते. त्याच्याप्रमाणे, आम्ही लक्ष्य केले ऑफलाइन-प्रथम API, जे क्लाउड क्लायंटसाठी योग्य पेक्षा अधिक दिसते. असे गृहीत धरले गेले होते की ते फक्त एकदाच क्लाउडची संपूर्ण स्थिती पंप करतील आणि नंतर बहुसंख्य प्रकरणांमध्ये सिंक्रोनाइझेशन रोल आउट बदलांद्वारे होईल. अरेरे, ही संधी अद्याप केवळ सैद्धांतिक झोनमध्ये आहे आणि क्लायंटने सराव मध्ये पॅचसह कसे कार्य करावे हे शिकलेले नाही. याची अनेक वस्तुनिष्ठ कारणे आहेत, जी परिचयास उशीर न करण्यासाठी, आम्ही कंस मागे ठेवू. आता, एपीआय जेव्हा “A” म्हणतो आणि त्याचा ग्राहक “B” म्हणत नाही तेव्हा काय होते याबद्दल धड्याचे बोधप्रद निष्कर्ष अधिक स्वारस्यपूर्ण आहेत.

म्हणून, जर तुम्ही git ची कल्पना केली, जी पुल कमांड कार्यान्वित करताना, स्थानिक स्नॅपशॉटवर पॅच लागू करण्याऐवजी, त्याच्या संपूर्ण स्थितीची संपूर्ण सर्व्हर स्थितीशी तुलना करते, तर तुम्हाला क्लाउडमध्ये सिंक्रोनाइझेशन कसे होते याची अगदी अचूक कल्पना येईल. ग्राहक अंदाज लावणे सोपे आहे की ते लागू करण्यासाठी, तुम्हाला सर्व सर्व्हर आणि स्थानिक फाइल्सबद्दल मेटा-माहितीसह मेमरीमध्ये दोन DOM झाडे वाटप करणे आवश्यक आहे. असे दिसून आले की जर वापरकर्त्याने क्लाउडमध्ये 500 हजार फायली संग्रहित केल्या असतील तर ते सिंक्रोनाइझ करण्यासाठी 1 दशलक्ष नोड्ससह दोन झाडे पुन्हा तयार करणे आणि नष्ट करणे आवश्यक आहे. परंतु प्रत्येक नोड हा उप-विषयांचा आलेख असलेला एकंदर असतो. या प्रकाशात, प्रोफाइलिंग परिणाम अपेक्षित होते. असे दिसून आले की विलीनीकरण अल्गोरिदम विचारात न घेता, मोठ्या संख्येने लहान वस्तू तयार करणे आणि नंतर नष्ट करणे या प्रक्रियेस एक पैसा खर्च करावा लागतो. मूलभूत सिंक्रोनाइझेशन ऑपरेशन मोठ्या संख्येने समाविष्ट केल्यामुळे परिस्थिती आणखी बिकट झाली आहे. वापरकर्ता स्क्रिप्टचे. परिणामी, आम्ही डेटाबेस निवडण्यासाठी दुसरा महत्त्वाचा निकष निश्चित करतो - ऑब्जेक्ट्सचे डायनॅमिक वाटप न करता CRUD ऑपरेशन्स अंमलात आणण्याची क्षमता.

इतर आवश्यकता अधिक पारंपारिक आहेत आणि त्यांची संपूर्ण यादी खालीलप्रमाणे आहे.

1. धाग्याची सुरक्षा.
2. मल्टीप्रोसेसिंग. केवळ थ्रेड्समध्येच नव्हे तर मुख्य ऍप्लिकेशन आणि iOS विस्तारांमध्ये देखील स्थिती सिंक्रोनाइझ करण्यासाठी समान डेटाबेस उदाहरण वापरण्याच्या इच्छेद्वारे निर्देशित केले जाते.
3. संग्रहित संस्थांना नॉन-म्युटेबल ऑब्जेक्ट्स म्हणून प्रस्तुत करण्याची क्षमता
4. CRUD ऑपरेशन्समध्ये कोणतेही डायनॅमिक वाटप नाहीत.
5. मूलभूत गुणधर्मांसाठी व्यवहार समर्थन आम्ल: अणु, सुसंगतता, अलगाव आणि विश्वासार्हता.
6. सर्वात लोकप्रिय प्रकरणांवर गती.

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

2. LMDB पोझिशनिंग

LMDB ही एक अतिशय लहान लायब्ररी आहे (फक्त 10K पंक्ती) जी डेटाबेसचा सर्वात कमी मूलभूत स्तर - स्टोरेज लागू करते.

वरील आकृती दर्शविते की SQLite सह LMDB ची तुलना करणे, जे उच्च स्तर देखील लागू करते, सामान्यतः कोर डेटासह SQLite पेक्षा अधिक योग्य नाही. समान स्पर्धक - BerkeleyDB, LevelDB, Sophia, RocksDB, इ. सारख्याच स्टोरेज इंजिनांना उद्धृत करणे अधिक योग्य ठरेल. LMDB हे SQLite साठी स्टोरेज इंजिन घटक म्हणून काम करते अशाही काही घडामोडी आहेत. असा पहिला प्रयोग 2012 मध्ये झाला होता खर्च केला LMDB द्वारे हॉवर्ड चू. निकाल तो इतका वेधक ठरला की त्याचा उपक्रम OSS उत्साही लोकांनी उचलून धरला आणि त्या व्यक्तीमध्ये त्याचे सातत्य दिसून आले LumoSQL. जानेवारी 2020 मध्ये, या प्रकल्पाचे लेखक डेन शिअरर होते सादर केले LinuxConfAu वर.

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

LMDB अनेकदा जसा आहे तसा स्टोरेज म्हणून वापरला जातो. उदाहरणार्थ, Mozilla Firefox ब्राउझर निवडले ते अनेक गरजांसाठी आणि, आवृत्ती 9, Xcode पासून सुरू होते प्राधान्य दिले अनुक्रमणिका संचयित करण्यासाठी त्याचे SQLite.

मोबाईल डेव्हलपमेंटच्या जगातही इंजिनने आपला ठसा उमटवला आहे. त्याच्या वापराचे ट्रेस असू शकतात शोधण्यासाठी टेलीग्रामसाठी iOS क्लायंटमध्ये. लिंक्डइन आणखी पुढे गेले आणि त्याच्या होमग्रोन डेटा कॅशिंग फ्रेमवर्क रॉकेट डेटासाठी डीफॉल्ट स्टोरेज म्हणून एलएमडीबी निवडले, ज्याबद्दल सांगितले 2016 मध्ये त्याच्या लेखात.

एलएमडीबी ओरॅकलच्या नियंत्रणाखाली आल्यानंतर बर्कलेडीबीने सोडलेल्या कोनाड्यात सूर्यप्रकाशात जागा मिळवण्यासाठी यशस्वीपणे लढा देत आहे. लायब्ररी त्याच्या समवयस्कांच्या तुलनेत वेग आणि विश्वासार्हतेसाठी प्रिय आहे. तुम्हाला माहिती आहेच की, कोणतेही मोफत लंच नाहीत आणि LMDB आणि SQLite मधील निवड करताना तुम्हाला कोणत्या ट्रेड-ऑफचा सामना करावा लागेल यावर मी जोर देऊ इच्छितो. वरील आकृती स्पष्टपणे दर्शवते की वाढीव वेग कसा मिळवला जातो. प्रथम, आम्ही डिस्क स्टोरेजच्या शीर्षस्थानी अॅब्स्ट्रॅक्शनच्या अतिरिक्त स्तरांसाठी पैसे देत नाही. हे स्पष्ट आहे की एक चांगली आर्किटेक्चर अद्याप त्यांच्याशिवाय करू शकत नाही आणि ते अपरिहार्यपणे अनुप्रयोग कोडमध्ये दिसून येतील, परंतु ते अधिक सूक्ष्म असतील. त्यामध्ये विशिष्ट अनुप्रयोगासाठी आवश्यक नसलेली वैशिष्ट्ये नसतील, उदाहरणार्थ, SQL भाषेतील प्रश्नांसाठी समर्थन. दुसरे म्हणजे, डिस्क स्टोरेजच्या विनंतीवर ऍप्लिकेशन ऑपरेशन्सचे मॅपिंग इष्टतमपणे लागू करणे शक्य होते. SQLite असल्यास माझ्या कामात सरासरी ऍप्लिकेशनच्या सरासरी सांख्यिकीय गरजांवर आधारित आहे, तर तुम्हाला, ऍप्लिकेशन डेव्हलपर म्हणून, मुख्य वर्कलोड परिस्थितींबद्दल चांगली माहिती आहे. अधिक उत्पादक समाधानासाठी, तुम्हाला प्रारंभिक सोल्यूशनच्या विकासासाठी आणि त्यानंतरच्या समर्थनासाठी वाढीव किंमत द्यावी लागेल.

3. LMDB चे तीन खांब

पक्ष्यांच्या नजरेतून LMDB कडे पाहिल्यानंतर, खोलवर जाण्याची वेळ आली. पुढील तीन विभाग मुख्य स्तंभांच्या विश्लेषणासाठी समर्पित केले जातील ज्यावर स्टोरेज आर्किटेक्चर आहे:

1. डिस्कसह कार्य करण्यासाठी आणि अंतर्गत डेटा संरचना समक्रमित करण्यासाठी मेमरी-मॅप केलेल्या फायली.
2. संग्रहित डेटाच्या संरचनेची संस्था म्हणून B+-ट्री.
3. ACID व्यवहार गुणधर्म आणि मल्टीव्हर्शन प्रदान करण्यासाठी एक दृष्टिकोन म्हणून कॉपी-ऑन-राइट.

३.१. व्हेल #3.1. मेमरी-मॅप केलेल्या फायली

मेमरी-मॅप केलेल्या फायली हे इतके महत्त्वाचे आर्किटेक्चरल घटक आहेत की ते रेपॉजिटरीच्या नावावर देखील दिसतात. संचयित माहितीच्या प्रवेशाच्या कॅशिंग आणि सिंक्रोनाइझेशनच्या समस्या पूर्णपणे ऑपरेटिंग सिस्टमवर सोडल्या जातात. LMDB मध्ये स्वतःमध्ये कोणतेही कॅशे नसतात. हा लेखकाचा जाणीवपूर्वक निर्णय आहे, कारण थेट मॅप केलेल्या फायलींमधून डेटा वाचणे आपल्याला इंजिन अंमलबजावणीमध्ये बरेच कोपरे कापण्याची परवानगी देते. खाली त्यापैकी काहींची संपूर्ण यादी नाही.

1. अनेक प्रक्रियांमधून काम करताना स्टोरेजमधील डेटाची सातत्य राखणे ही ऑपरेटिंग सिस्टमची जबाबदारी बनते. पुढील भागात, या यांत्रिकीबद्दल तपशीलवार आणि चित्रांसह चर्चा केली आहे.
2. कॅशेची अनुपस्थिती डायनॅमिक ऍलोकेशनशी संबंधित ओव्हरहेडमधून LMDB पूर्णपणे काढून टाकते. सराव मध्ये डेटा वाचणे म्हणजे व्हर्च्युअल मेमरीमध्ये योग्य पत्त्यावर पॉइंटर सेट करणे आणि आणखी काही नाही. हे सायन्स फिक्शन सारखे वाटते, परंतु स्टोरेज सोर्स कोडमध्ये कॉलॉकला सर्व कॉल स्टोरेज कॉन्फिगरेशन फंक्शनमध्ये केंद्रित आहेत.
3. कॅशेच्या अनुपस्थितीचा अर्थ त्यांच्या प्रवेशाच्या सिंक्रोनाइझेशनशी संबंधित लॉकची अनुपस्थिती देखील आहे. वाचक, ज्यापैकी एकाच वेळी वाचकांची अनियंत्रित संख्या असू शकते, डेटाकडे जाताना त्यांना एकच म्यूटेक्स आढळत नाही. यामुळे, CPU च्या संख्येवर आधारित रीडिंग स्पीडमध्ये आदर्श रेखीय स्केलेबिलिटी असते. LMDB मध्ये, फक्त सुधारित ऑपरेशन्स सिंक्रोनाइझ केल्या जातात. एका वेळी एकच लेखक असू शकतो.
4. किमान कॅशिंग आणि सिंक्रोनाइझेशन लॉजिक मल्टी-थ्रेडेड वातावरणात काम करण्याशी संबंधित अत्यंत जटिल प्रकारच्या त्रुटी दूर करते. Usenix OSDI 2014 परिषदेत दोन मनोरंजक डेटाबेस अभ्यास होते: "सर्व फाइल सिस्टीम समान बनवल्या जात नाहीत: क्रॅश-सुसंगत अनुप्रयोग तयार करण्याच्या जटिलतेवर" и "मजा आणि फायद्यासाठी डेटाबेसचा छळ". त्यांच्याकडून तुम्ही LMDB ची अभूतपूर्व विश्वासार्हता आणि ACID व्यवहार गुणधर्मांची जवळजवळ निर्दोष अंमलबजावणी या दोन्हींबद्दल माहिती मिळवू शकता, जे SQLite पेक्षा श्रेष्ठ आहे.
5. LMDB चे मिनिमलिझम त्याच्या कोडचे मशीन प्रतिनिधित्व पूर्णतः प्रोसेसरच्या L1 कॅशेमध्ये पुढील गती वैशिष्ट्यांसह स्थित करण्याची परवानगी देते.

दुर्दैवाने, iOS मध्ये, मेमरी-मॅप केलेल्या फायलींसह, सर्वकाही आम्हाला हवे तसे क्लाउडलेस नाही. त्यांच्याशी संबंधित कमतरतांबद्दल अधिक जाणीवपूर्वक बोलण्यासाठी, ऑपरेटिंग सिस्टममध्ये ही यंत्रणा लागू करण्याची सामान्य तत्त्वे लक्षात ठेवणे आवश्यक आहे.

मेमरी-मॅप केलेल्या फाइल्सबद्दल सामान्य माहिती

चालणार्‍या प्रत्येक ऍप्लिकेशनसह, ऑपरेटिंग सिस्टम प्रक्रिया नावाची संस्था संबद्ध करते. प्रत्येक प्रक्रियेला पत्त्यांची एक संलग्न श्रेणी वाटप केली जाते ज्यामध्ये ती ऑपरेट करण्यासाठी आवश्यक असलेली प्रत्येक गोष्ट ठेवते. सर्वात कमी पत्त्यांवर कोड आणि हार्ड-कोडेड डेटा आणि संसाधने असलेले विभाग आहेत. पुढे डायनॅमिक अॅड्रेस स्पेसचा एक वाढता ब्लॉक येतो, जो आपल्याला हीप नावाने परिचित आहे. त्यात प्रोग्रामच्या ऑपरेशन दरम्यान दिसणार्‍या घटकांचे पत्ते असतात. शीर्षस्थानी ऍप्लिकेशन स्टॅकद्वारे वापरलेले मेमरी क्षेत्र आहे. ते एकतर वाढते किंवा आकुंचन पावते; दुसऱ्या शब्दांत, त्याच्या आकारात गतिशील स्वरूप देखील आहे. स्टॅक आणि ढीग एकमेकांना ढकलण्यापासून आणि हस्तक्षेप करण्यापासून रोखण्यासाठी, ते अॅड्रेस स्पेसच्या वेगवेगळ्या टोकांवर स्थित आहेत. वरील आणि तळाशी दोन डायनॅमिक विभागांमध्ये एक छिद्र आहे. कार्यप्रणाली विविध घटकांना प्रक्रियेशी जोडण्यासाठी या मध्यम विभागातील पत्ते वापरते. विशेषतः, ते डिस्कवरील फाईलसह पत्त्यांचा विशिष्ट सतत संच संबद्ध करू शकते. अशा फाइलला मेमरी मॅप म्हणतात

प्रक्रियेसाठी वाटप केलेल्या पत्त्याची जागा मोठी आहे. सैद्धांतिकदृष्ट्या, पत्त्यांची संख्या केवळ पॉइंटरच्या आकाराद्वारे मर्यादित आहे, जी सिस्टमच्या बिट क्षमतेद्वारे निर्धारित केली जाते. जर भौतिक मेमरी 1-ते-1 वर मॅप केली गेली असेल, तर पहिलीच प्रक्रिया संपूर्ण RAM वर जाईल आणि कोणत्याही मल्टीटास्किंगची चर्चा होणार नाही.

तथापि, आमच्या अनुभवावरून आम्हाला माहित आहे की आधुनिक कार्यप्रणाली एकाच वेळी पाहिजे तितक्या प्रक्रिया करू शकतात. हे शक्य आहे कारण ते फक्त कागदावर प्रक्रिया करण्यासाठी भरपूर मेमरी वाटप करतात, परंतु प्रत्यक्षात ते मुख्य भौतिक मेमरीमध्ये फक्त तो भाग लोड करतात ज्याला येथे आणि आता मागणी आहे. म्हणून, प्रक्रियेशी संबंधित मेमरीला आभासी म्हणतात.

ऑपरेटिंग सिस्टम आभासी आणि भौतिक मेमरी एका विशिष्ट आकाराच्या पृष्ठांमध्ये आयोजित करते. व्हर्च्युअल मेमरीच्या विशिष्ट पृष्ठाची मागणी होताच, ऑपरेटिंग सिस्टम ती भौतिक मेमरीमध्ये लोड करते आणि त्यांना एका विशेष टेबलमध्ये जुळवते. कोणतेही विनामूल्य स्लॉट नसल्यास, पूर्वी लोड केलेल्या पृष्ठांपैकी एक डिस्कवर कॉपी केले जाते आणि मागणी असलेले एक त्याचे स्थान घेते. ही प्रक्रिया, ज्यावर आपण लवकरच परत येऊ, त्याला स्वॅपिंग म्हणतात. खालील आकृती वर्णन केलेल्या प्रक्रियेचे वर्णन करते. त्यावर, पत्ता 0 असलेले पृष्ठ A लोड केले गेले आणि पत्त्या 4 सह मुख्य मेमरी पृष्ठावर ठेवले गेले. ही वस्तुस्थिती सेल क्रमांक 0 मधील पत्रव्यवहार सारणीमध्ये दिसून आली.

मेमरीमध्ये मॅप केलेल्या फाइल्सची कथा अगदी सारखीच आहे. तार्किकदृष्ट्या, ते कथितपणे सतत आणि संपूर्णपणे व्हर्च्युअल अॅड्रेस स्पेसमध्ये स्थित असतात. तथापि, ते पृष्ठानुसार आणि फक्त विनंती केल्यावर भौतिक मेमरी पृष्ठ प्रविष्ट करतात. अशा पृष्ठांचे बदल डिस्कवरील फाइलसह समक्रमित केले जातात. अशा प्रकारे, तुम्ही फक्त मेमरीमधील बाइट्ससह कार्य करून फाइल I/O करू शकता - सर्व बदल ऑपरेटिंग सिस्टम कर्नलद्वारे स्वयंचलितपणे स्त्रोत फाइलमध्ये हस्तांतरित केले जातील.
​
खालील प्रतिमा विविध प्रक्रियांमधून डेटाबेससह कार्य करताना LMDB त्याची स्थिती कशी समक्रमित करते हे दर्शवते. एकाच फाइलवर वेगवेगळ्या प्रक्रियांची आभासी मेमरी मॅप करून, आम्ही ऑपरेटिंग सिस्टमला त्यांच्या अॅड्रेस स्पेसचे ठराविक ब्लॉक्स एकमेकांशी संक्रमणात्मकपणे सिंक्रोनाइझ करण्यास बाध्य करतो, जिथे LMDB दिसते.
​

एक महत्त्वाची बाब म्हणजे LMDB, मुलभूतरित्या, राईट सिस्टम कॉल मेकॅनिझमद्वारे डेटा फाईल सुधारित करते आणि फाइल केवळ-वाचनीय मोडमध्ये प्रदर्शित करते. या दृष्टिकोनाचे दोन महत्त्वाचे परिणाम आहेत.

पहिला परिणाम सर्व ऑपरेटिंग सिस्टमसाठी सामान्य आहे. चुकीच्या कोडद्वारे डेटाबेसला अनावधानाने झालेल्या नुकसानापासून संरक्षण जोडणे हे त्याचे सार आहे. तुम्हाला माहिती आहेच की, एखाद्या प्रक्रियेच्या एक्झिक्यूटेबल सूचना त्याच्या अॅड्रेस स्पेसमधील कोठूनही डेटा ऍक्सेस करण्यासाठी विनामूल्य आहेत. त्याच वेळी, आम्‍हाला आत्ताच आठवल्‍याप्रमाणे, रीड-राइट मोडमध्‍ये फाइल प्रदर्शित करण्‍याचा अर्थ असा आहे की कोणतीही सूचना त्यात बदल करू शकते. जर तिने चुकून असे केले, उदाहरणार्थ, अस्तित्वात नसलेल्या निर्देशांकावर अॅरे घटक ओव्हरराइट करण्याचा प्रयत्न केला, तर ती चुकून या पत्त्यावर मॅप केलेली फाइल बदलू शकते, ज्यामुळे डेटाबेस खराब होईल. जर फाइल केवळ-वाचनीय मोडमध्ये प्रदर्शित केली गेली असेल, तर संबंधित पत्त्याची जागा बदलण्याचा प्रयत्न केल्यास सिग्नलसह प्रोग्राम आपत्कालीन समाप्त होईल. SIGSEGV, आणि फाइल अखंड राहील.

दुसरा परिणाम आधीच iOS साठी विशिष्ट आहे. लेखक किंवा इतर कोणत्याही स्त्रोतांनी याचा स्पष्टपणे उल्लेख केलेला नाही, परंतु त्याशिवाय LMDB या मोबाइल ऑपरेटिंग सिस्टमवर चालण्यासाठी योग्य होणार नाही. पुढील भाग त्याच्या विचारासाठी समर्पित आहे.

iOS मधील मेमरी-मॅप केलेल्या फाइल्सची विशिष्टता

2018 मध्ये WWDC मध्ये एक अद्भुत अहवाल आला होता "iOS मेमरी डीप डायव्ह". हे आम्हाला सांगते की iOS मध्ये, भौतिक मेमरीमध्ये असलेली सर्व पृष्ठे 3 प्रकारांपैकी एक आहेत: गलिच्छ, संकुचित आणि स्वच्छ.

क्लीन मेमरी हा पृष्ठांचा संग्रह आहे जो भौतिक मेमरीमधून वेदनारहितपणे अनलोड केला जाऊ शकतो. त्यात असलेला डेटा त्याच्या मूळ स्त्रोतांकडून आवश्यकतेनुसार रीलोड केला जाऊ शकतो. केवळ-वाचनीय मेमरी-मॅप केलेल्या फायली या वर्गात मोडतात. मेमरीमधून फाईलमध्ये मॅप केलेली पृष्ठे कधीही अनलोड करण्यास iOS घाबरत नाही, कारण ते डिस्कवरील फाइलसह समक्रमित केले जाण्याची हमी दिली जाते.
​
सर्व सुधारित पृष्ठे घाणेरड्या मेमरीमध्ये संपतात, ते मूळ कुठेही असले तरीही. विशेषतः, मेमरी-मॅप केलेल्या फाइल्स त्यांच्याशी संबंधित आभासी मेमरीवर लिहून सुधारित केल्या जातील अशा प्रकारे वर्गीकृत केल्या जातील. ध्वजासह LMDB उघडत आहे MDB_WRITEMAP, त्यात बदल केल्यानंतर, तुम्ही हे वैयक्तिकरित्या सत्यापित करू शकता

एखादे अॅप्लिकेशन खूप जास्त भौतिक मेमरी घेण्यास सुरुवात करतेच, iOS त्यास गलिच्छ पृष्ठ कॉम्प्रेशनच्या अधीन करते. गलिच्छ आणि संकुचित पृष्ठांनी व्यापलेली एकूण मेमरी ही ऍप्लिकेशनच्या तथाकथित मेमरी फूटप्रिंट बनवते. एकदा ते एका ठराविक थ्रेशोल्ड मूल्यापर्यंत पोहोचले की, OOM किलर सिस्टम डिमन प्रक्रियेनंतर येतो आणि बळजबरीने बंद करतो. डेस्कटॉप ऑपरेटिंग सिस्टीमच्या तुलनेत ही iOS ची खासियत आहे. याउलट, फिजिकल मेमरीवरून डिस्कवर पृष्ठे बदलून मेमरी फूटप्रिंट कमी करणे iOS मध्ये प्रदान केलेले नाही. कारणे फक्त अंदाज लावता येतात. कदाचित पृष्ठे डिस्कवर आणि मागे हलविण्याची प्रक्रिया मोबाइल डिव्हाइससाठी खूप ऊर्जा घेणारी आहे किंवा iOS एसएसडी ड्राइव्हवर पुनर्लेखन सेलचे संसाधन वाचवते किंवा कदाचित डिझाइनर सिस्टमच्या एकूण कार्यक्षमतेवर समाधानी नसतील, जिथे सर्वकाही आहे. सतत अदलाबदल. ते काहीही असो, वस्तुस्थिती एक वस्तुस्थिती राहते.

आधीच नमूद केलेली चांगली बातमी म्हणजे LMDB बाय डीफॉल्ट फाइल्स अपडेट करण्यासाठी mmap यंत्रणा वापरत नाही. याचा अर्थ असा की प्रदर्शित केलेला डेटा iOS द्वारे क्लीन मेमरी म्हणून वर्गीकृत केला जातो आणि मेमरी फूटप्रिंटमध्ये योगदान देत नाही. तुम्ही VM ट्रॅकर नावाचे Xcode टूल वापरून याची पडताळणी करू शकता. खालील स्क्रीनशॉट ऑपरेशन दरम्यान क्लाउड ऍप्लिकेशनच्या iOS व्हर्च्युअल मेमरीची स्थिती दर्शवितो. सुरुवातीस, त्यात 2 LMDB उदाहरणे सुरू करण्यात आली. पहिल्याला त्याची फाइल व्हर्च्युअल मेमरीच्या 1GiB वर प्रदर्शित करण्याची परवानगी होती, दुसरी - 512MiB. दोन्ही स्टोरेजमध्ये ठराविक प्रमाणात रहिवासी मेमरी व्यापलेली असूनही, त्यापैकी एकही गलिच्छ आकारात योगदान देत नाही.

आणि आता वाईट बातमीची वेळ आली आहे. 64-बिट डेस्कटॉप ऑपरेटिंग सिस्टीममधील स्वॅप यंत्रणेबद्दल धन्यवाद, प्रत्येक प्रक्रिया त्याच्या संभाव्य स्वॅपसाठी विनामूल्य हार्ड डिस्क जागेइतकी आभासी पत्ता जागा व्यापू शकते. आयओएसमध्ये स्वॅपला कॉम्प्रेशनने बदलल्याने सैद्धांतिक कमाल कमी होते. आता सर्व सजीव प्रक्रिया मुख्य (रॅम वाचा) मेमरीमध्ये बसल्या पाहिजेत आणि ज्या फिट होत नाहीत त्या सर्व समाप्त करण्यास भाग पाडल्या पाहिजेत. हे वर नमूद केल्याप्रमाणे नमूद केले आहे अहवाल, आणि मध्ये अधिकृत दस्तऐवजीकरण. परिणामी, iOS mmap द्वारे वाटपासाठी उपलब्ध मेमरीच्या प्रमाणात कठोरपणे मर्यादा घालते. येथे येथे तुम्ही या सिस्टीम कॉलचा वापर करून वेगवेगळ्या उपकरणांवर वाटप केलेल्या मेमरीच्या प्रमाणाची अनुभवजन्य मर्यादा पाहू शकता. सर्वात आधुनिक स्मार्टफोन मॉडेल्सवर, iOS 2 गीगाबाइट्सने उदार झाले आहे, आणि iPad च्या शीर्ष आवृत्त्यांवर - 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+ फरक फक्त सर्वात कमी आहे. ही वस्तुस्थिती निश्चित केल्यावर, आम्ही पुढे LMDB मध्ये वापरल्या जाणार्‍या झाडाच्या उपप्रकाराला फक्त बी-ट्री म्हणू.
3. रूट आणि पानांच्या दरम्यान नेव्हिगेशनल (शाखा) नोड्ससह 0 किंवा अधिक तांत्रिक स्तर असतात. त्यांचे कार्य पानांमध्ये क्रमवारी लावलेल्या कळांचे विभाजन करणे आहे.

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

पृष्‍ठ नोडस्च्‍या अंतर्गत आशयाचा सामना केल्‍यानंतर, आम्‍ही पुढील फॉर्ममध्‍ये LMDB B-ट्रीचे सरलीकृत रीतीने प्रतिनिधित्व करू.

नोड्स असलेली पृष्ठे डिस्कवर अनुक्रमे स्थित आहेत. उच्च क्रमांकाची पृष्ठे फाईलच्या शेवटी स्थित आहेत. तथाकथित मेटा पृष्ठामध्ये ऑफसेटची माहिती असते ज्याद्वारे सर्व झाडांची मुळे शोधली जाऊ शकतात. फाइल उघडताना, वैध मेटा पृष्ठ शोधण्यासाठी LMDB फाइल पृष्ठास पृष्ठानुसार स्कॅन करते आणि त्याद्वारे विद्यमान डेटाबेस शोधते.

आता, डेटा संस्थेच्या तार्किक आणि भौतिक रचनेची कल्पना आल्यावर, आपण LMDB च्या तिसऱ्या स्तंभाचा विचार करू शकतो. त्याच्या मदतीने सर्व स्टोरेज फेरबदल व्यवहारात आणि एकमेकांपासून अलिप्तपणे होतात, ज्यामुळे डेटाबेसला संपूर्णपणे मल्टीव्हर्शनची मालमत्ता मिळते.

३.३. व्हेल #3.3. कॉपी-ऑन-राइट

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

डेटाबेस फॉल्ट-टॉलरंट बनवण्यासाठी एक पारंपारिक उपाय म्हणजे बी-ट्रीच्या शेजारी अतिरिक्त ऑन-डिस्क डेटा स्ट्रक्चर जोडणे - एक व्यवहार लॉग, ज्याला राइट-अहेड लॉग (WAL) असेही म्हणतात. ही एक फाईल आहे ज्याच्या शेवटी बी-ट्रीमध्ये बदल करण्यापूर्वी इच्छित ऑपरेशन कठोरपणे लिहिलेले आहे. अशाप्रकारे, स्व-निदान दरम्यान डेटा भ्रष्टाचार आढळल्यास, डेटाबेस स्वतःला व्यवस्थित ठेवण्यासाठी लॉगचा सल्ला घेतो.

LMDB ने फॉल्ट टॉलरन्स मेकॅनिझम म्हणून वेगळी पद्धत निवडली आहे, ज्याला कॉपी-ऑन-राईट म्हणतात. त्याचे सार हे आहे की विद्यमान पृष्ठावरील डेटा अद्यतनित करण्याऐवजी, ते प्रथम त्याची संपूर्ण कॉपी करते आणि कॉपीमध्ये सर्व बदल करते.

पुढे, अद्ययावत डेटा उपलब्ध होण्यासाठी, त्याच्या मूळ नोडमध्ये चालू झालेल्या नोडची लिंक बदलणे आवश्यक आहे. त्यासाठी त्यातही बदल करावा लागणार असल्याने त्याचीही नक्कल अगोदरच केली जाते. प्रक्रिया मुळापर्यंत वारंवार चालू राहते. बदलण्याची शेवटची गोष्ट म्हणजे मेटा पृष्ठावरील डेटा

अपडेट प्रक्रियेदरम्यान अचानक प्रक्रिया क्रॅश झाल्यास, एकतर नवीन मेटा पृष्ठ तयार केले जाणार नाही, किंवा ते पूर्णपणे डिस्कवर लिहिले जाणार नाही आणि त्याचे चेकसम चुकीचे असेल. या दोन्हीपैकी कोणत्याही परिस्थितीत, नवीन पृष्ठे पोहोचू शकत नाहीत, परंतु जुन्या पृष्ठांवर परिणाम होणार नाही. हे डेटा सातत्य राखण्यासाठी LMDB ला पुढे लॉग लिहिण्याची गरज दूर करते. वास्तविकपणे, वर वर्णन केलेल्या डिस्कवरील डेटा स्टोरेजची रचना एकाच वेळी त्याचे कार्य करते. स्पष्ट ट्रान्झॅक्शन लॉगची अनुपस्थिती हे LMDB च्या वैशिष्ट्यांपैकी एक आहे जे उच्च डेटा वाचन गती प्रदान करते.

परिणामी डिझाईन, ज्याला अपेंड-ओन्ली बी-ट्री म्हणतात, नैसर्गिकरित्या व्यवहार अलगाव आणि बहु-आवृत्ती प्रदान करते. LMDB मध्ये, प्रत्येक खुला व्यवहार सध्या संबंधित वृक्षाच्या मुळाशी संबंधित आहे. जोपर्यंत व्यवहार पूर्ण होत नाही तोपर्यंत, त्याच्याशी संबंधित झाडाची पृष्ठे कधीही बदलली जाणार नाहीत किंवा डेटाच्या नवीन आवृत्त्यांसाठी पुन्हा वापरली जाणार नाहीत. अशा प्रकारे, त्यावेळेस संबंधित असलेल्या डेटाच्या संचासह तुम्ही तुम्हाला आवडेल तोपर्यंत काम करू शकता. या वेळी संचयन सक्रियपणे अद्यतनित केले जात असले तरीही व्यवहार उघडला गेला. हे मल्टीव्हर्शनचे सार आहे, जे LMDB ला आमच्या प्रियकरांसाठी एक आदर्श डेटा स्रोत बनवते UICollectionView. व्यवहार उघडल्यानंतर, काहीही शिल्लक राहण्याच्या भीतीने, वर्तमान डेटा घाईघाईने काही इन-मेमरी स्ट्रक्चरमध्ये पंप करून ऍप्लिकेशनचा मेमरी फूटप्रिंट वाढवण्याची गरज नाही. हे वैशिष्ट्य LMDB ला समान SQLite पासून वेगळे करते, जे अशा एकूण अलगावचा अभिमान बाळगू शकत नाही. नंतरचे दोन व्यवहार उघडल्यानंतर आणि त्यातील एकामधील विशिष्ट रेकॉर्ड हटविल्यानंतर, उर्वरित दुसऱ्यामध्ये समान रेकॉर्ड मिळवणे यापुढे शक्य होणार नाही.

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

येथे मेमरी-मॅप केलेल्या फायलींवरील विभाग लक्षात घेणे उपयुक्त ठरेल. असे दिसते की व्हर्च्युअल मेमरीचा अतिरिक्त वापर आपल्याला जास्त काळजी करू नये कारण ते अनुप्रयोगाच्या मेमरी फूटप्रिंटमध्ये योगदान देत नाही. तथापि, त्याच वेळी, हे लक्षात आले की iOS हे वाटप करण्यात खूप कंजूष आहे आणि आम्ही सर्व्हर किंवा डेस्कटॉपप्रमाणे, 1 टेराबाइटचा LMDB प्रदेश प्रदान करू शकत नाही आणि या वैशिष्ट्याबद्दल अजिबात विचार करू शकत नाही. शक्य असल्यास, व्यवहारांचे आयुष्य शक्य तितके कमी करण्याचा प्रयत्न करा.

4. की-व्हॅल्यू API च्या शीर्षस्थानी डेटा स्कीमा डिझाइन करणे

LMDB द्वारे प्रदान केलेल्या मूलभूत अ‍ॅबस्ट्रॅक्शन्स: पर्यावरण आणि डेटाबेस, की आणि मूल्ये, व्यवहार आणि कर्सर पाहून आमचे API विश्लेषण सुरू करूया.

कोड सूचीबद्दल एक टीप

सार्वजनिक LMDB API मधील सर्व फंक्शन्स त्यांच्या कार्याचा परिणाम एरर कोडच्या स्वरूपात देतात, परंतु त्यानंतरच्या सर्व सूचींमध्ये त्याचे सत्यापन संक्षिप्ततेसाठी वगळण्यात आले आहे. व्यवहारात, आम्ही रिपॉझिटरीशी संवाद साधण्यासाठी आमच्या स्वतःचा वापर केला आहे. काटा C++ रॅपर्स lmdbxx, ज्यामध्ये C++ अपवाद म्हणून त्रुटी साकारल्या जातात.

IOS किंवा macOS साठी LMDB ला प्रोजेक्टशी कनेक्ट करण्याचा सर्वात जलद मार्ग म्हणून, मी माझा CocoaPod सुचवतो POSLMDB.

४.१. मूलभूत अमूर्तता

पर्यावरण

रचना 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 क्लाउड ऍप्लिकेशनमध्ये, आम्ही फक्त दोन पॅरामीटर्सची डीफॉल्ट मूल्ये बदलली आहेत.

पहिले म्हणजे व्हर्च्युअल अॅड्रेस स्पेसचा आकार ज्यावर स्टोरेज फाइल मॅप केली आहे. दुर्दैवाने, अगदी त्याच डिव्हाइसवर, विशिष्ट मूल्य रन ते रन पर्यंत लक्षणीयरीत्या बदलू शकते. iOS चे हे वैशिष्ट्य विचारात घेण्यासाठी, कमाल स्टोरेज व्हॉल्यूम डायनॅमिकपणे निवडले आहे. एका विशिष्ट मूल्यापासून प्रारंभ करून, ते फंक्शनपर्यंत क्रमशः अर्धवट केले जाते 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. सर्व मूलभूत गुणधर्मांना समर्थन देते आम्ल: अणु, सुसंगतता, अलगाव आणि विश्वासार्हता. मी मदत करू शकत नाही परंतु लक्षात ठेवा की मॅकओएस आणि iOS वर टिकाऊपणाच्या बाबतीत एक बग आहे जो MDBX मध्ये निश्चित केला होता. आपण त्यांच्यामध्ये अधिक वाचू शकता मला वाचा.
2. मल्टीथ्रेडिंगचा दृष्टीकोन "एकल लेखक / एकाधिक वाचक" योजनेद्वारे वर्णन केला जातो. लेखक एकमेकांना ब्लॉक करतात, पण वाचकांना ब्लॉक करत नाहीत. वाचक लेखकांना किंवा एकमेकांना ब्लॉक करत नाहीत.
3. नेस्टेड व्यवहारांसाठी समर्थन.
4. मल्टीव्हर्शन समर्थन.

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 सह तीच युक्ती वापरून पहा आणि काय होते ते पहा.

मल्टीव्हर्शन iOS डेव्हलपरच्या आयुष्यात खूप छान फायदे आणते. या मालमत्तेचा वापर करून, तुम्ही वापरकर्त्याच्या अनुभवाच्या विचारांवर आधारित, स्क्रीन फॉर्मसाठी डेटा स्रोताचा अपडेट दर सहज आणि नैसर्गिकरित्या समायोजित करू शकता. उदाहरणार्थ, Mail.ru क्लाउड ऍप्लिकेशनचे वैशिष्ट्य घेऊ जसे की सिस्टम मीडिया गॅलरीमधून सामग्री ऑटोलोड करणे. चांगल्या कनेक्शनसह, क्लायंट सर्व्हरवर प्रति सेकंद अनेक फोटो जोडण्यास सक्षम आहे. आपण प्रत्येक डाउनलोड नंतर अद्यतनित केल्यास UICollectionView वापरकर्त्याच्या क्लाउडमधील मीडिया सामग्रीसह, तुम्ही या प्रक्रियेदरम्यान सुमारे 60 fps आणि गुळगुळीत स्क्रोलिंग विसरू शकता. वारंवार स्क्रीन अपडेट्स टाळण्यासाठी, तुम्हाला अंतर्निहित डेटामध्ये बदल होणारा दर कसा तरी मर्यादित करणे आवश्यक आहे UICollectionViewDataSource.

जर डेटाबेस मल्टीव्हर्शनला सपोर्ट करत नसेल आणि तुम्हाला फक्त सद्यस्थितीत काम करण्याची परवानगी देत ​​असेल, तर डेटाचा टाइम-स्टेबल स्नॅपशॉट तयार करण्यासाठी तुम्हाला तो काही इन-मेमरी डेटा स्ट्रक्चरवर किंवा तात्पुरत्या टेबलवर कॉपी करणे आवश्यक आहे. यापैकी कोणतीही पद्धत खूप महाग आहे. इन-मेमरी स्टोरेजच्या बाबतीत, आम्हाला मेमरीमध्ये, बांधलेल्या वस्तू संचयित केल्यामुळे आणि वेळेत, अनावश्यक ORM परिवर्तनांशी संबंधित दोन्ही खर्च मिळतात. तात्पुरत्या टेबलसाठी, हा आणखी महाग आनंद आहे, केवळ क्षुल्लक प्रकरणांमध्येच अर्थ प्राप्त होतो.

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

कर्सर

कर्सर बी-ट्री ट्रॅव्हर्सलद्वारे की-व्हॅल्यू जोड्यांवर व्यवस्थित पुनरावृत्ती करण्यासाठी एक यंत्रणा प्रदान करतात. त्यांच्याशिवाय, डेटाबेसमधील सारण्या प्रभावीपणे मॉडेल करणे अशक्य होईल, ज्याकडे आम्ही आता वळतो.

४.२. टेबल मॉडेलिंग

की ऑर्डरिंगचा गुणधर्म तुम्हाला उच्च-स्तरीय अॅब्स्ट्रॅक्शन तयार करण्यास अनुमती देतो जसे की मूलभूत अ‍ॅबस्ट्रॅक्शनच्या शीर्षस्थानी टेबल. क्लाउड क्लायंटच्या मुख्य सारणीचे उदाहरण वापरून या प्रक्रियेचा विचार करूया, जे वापरकर्त्याच्या सर्व फायली आणि फोल्डर्सची माहिती कॅश करते.

टेबल स्कीमा

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

खाली दिलेले चित्र दाखवते की, हातातील कार्याच्या आधारावर, बाइट अॅरेच्या स्वरूपात कीजचे प्रतिनिधित्व कसे दिसू शकते. मूळ डिरेक्टरी (लाल) च्या आयडेंटिफायरसह बाइट्स प्रथम, नंतर प्रकार (हिरव्या) आणि शेपटीत नाव (निळा) ठेवलेले आहेत. डीफॉल्ट एलएमडीबी तुलनिकाद्वारे शब्दकोशाच्या क्रमाने क्रमवारी लावले जातात. आवश्यक पद्धत. समान लाल प्रीफिक्ससह अनुक्रमे ट्रॅव्हर्सिंग की आम्हाला त्यांची संबंधित मूल्ये देतात ज्या क्रमाने ती वापरकर्ता इंटरफेसमध्ये (उजवीकडे) प्रदर्शित केली जावीत, कोणत्याही अतिरिक्त पोस्ट-प्रोसेसिंगची आवश्यकता न घेता.

की आणि मूल्ये क्रमवारी लावणे

वस्तूंचे क्रमिकीकरण करण्याच्या अनेक पद्धती जगात शोधल्या गेल्या आहेत. आम्हाला वेगाशिवाय इतर कोणतीही आवश्यकता नसल्यामुळे, आम्ही स्वतःसाठी शक्य तितके जलद निवडले - सी भाषेच्या संरचनेच्या उदाहरणाने व्यापलेला मेमरीचा डंप. अशा प्रकारे, निर्देशिकेच्या घटकाची की खालील संरचनेसह तयार केली जाऊ शकते. 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 मानकांनुसार तुम्हाला एक विलक्षण परिस्थिती मिळू शकते - नेटवर्कपासून डिस्कपर्यंतच्या संपूर्ण मार्गावर डेटासह कार्य करण्यासाठी फक्त स्टॅक मेमरी वापरा!

बायनरी कंपॅरेटरसह की ऑर्डर करणे

की ऑर्डर रिलेशनशिप एका विशेष फंक्शनद्वारे निर्दिष्ट केली जाते ज्याला कंपॅरेटर म्हणतात. इंजिनला त्यांच्यामध्ये असलेल्या बाइट्सच्या शब्दार्थाविषयी काहीही माहिती नसल्यामुळे, डीफॉल्ट तुलनाकर्त्याला बाइट-बाय-बाइट तुलनाचा अवलंब करून, लेक्सिकोग्राफिक क्रमाने की व्यवस्थित करण्याशिवाय पर्याय नाही. स्ट्रक्चर्स व्यवस्थित करण्यासाठी त्याचा वापर करणे हे कापलेल्या कुर्हाडीने मुंडण करण्यासारखे आहे. तथापि, साध्या प्रकरणांमध्ये मला ही पद्धत स्वीकार्य वाटते. पर्यायाचे खाली वर्णन केले आहे, परंतु येथे मी या मार्गावर विखुरलेले दोन रेक लक्षात घेईन.

लक्षात ठेवण्याची पहिली गोष्ट म्हणजे आदिम डेटा प्रकारांचे मेमरी प्रतिनिधित्व. अशा प्रकारे, सर्व ऍपल उपकरणांवर, पूर्णांक व्हेरिएबल्स फॉरमॅटमध्ये संग्रहित केले जातात लहान एंडियन. याचा अर्थ सर्वात कमी महत्त्वाचा बाइट डावीकडे असेल आणि बाइट-बाय-बाइट तुलना वापरून पूर्णांकांची क्रमवारी लावणे शक्य होणार नाही. उदाहरणार्थ, 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, डीफॉल्ट बायनरी तुलनाकर्ता यापुढे की तुलनासाठी योग्य नाही. जर आम्ही ते आमच्या स्वतःच्या बरोबर बदलले नाही, तर नावाची लांबी नावापेक्षा क्रमवारीत उच्च प्राधान्य घटक असेल.

LMDB प्रत्येक डेटाबेसला त्याचे स्वतःचे मुख्य तुलना कार्य करण्यास अनुमती देते. हे फंक्शन वापरून केले जाते 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 // ...
}​

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

अनुक्रमांक मूल्ये

LMDB संचयित नोंदींच्या की सह अत्यंत तीव्रतेने कार्य करते. त्यांची एकमेकांशी तुलना कोणत्याही लागू केलेल्या ऑपरेशनच्या चौकटीत होते आणि संपूर्ण सोल्यूशनची कार्यक्षमता तुलनाकर्त्याच्या गतीवर अवलंबून असते. आदर्श जगात, की ची तुलना करण्यासाठी डीफॉल्ट बायनरी तुलनाकर्ता पुरेसा असला पाहिजे, परंतु जर तुम्हाला तुमची स्वतःची वापरायची असेल, तर त्यामधील की डीसीरियलाइज करण्याची प्रक्रिया शक्य तितक्या जलद असावी.

डेटाबेसला रेकॉर्डच्या मूल्याच्या भागामध्ये (मूल्य) विशेषतः स्वारस्य नाही. बाइटच्या प्रतिनिधित्वावरून ऑब्जेक्टमध्ये त्याचे रूपांतरण तेव्हाच घडते जेव्हा ते आधीपासूनच ऍप्लिकेशन कोडद्वारे आवश्यक असते, उदाहरणार्थ, ते स्क्रीनवर प्रदर्शित करण्यासाठी. हे तुलनेने क्वचितच घडत असल्याने, या प्रक्रियेसाठी गतीची आवश्यकता तितकी गंभीर नाही, आणि त्याच्या अंमलबजावणीमध्ये आम्ही सोयींवर लक्ष केंद्रित करण्यास अधिक मोकळे आहोत. उदाहरणार्थ, अद्याप डाउनलोड न केलेल्या फायलींबद्दल मेटाडेटा अनुक्रमित करण्यासाठी, आम्ही वापरतो 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.

नोंदी वाचत आहे

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. केवळ वाचनीय व्यवहारासाठी, मूल्य संरचनेचे पॉइंटर व्यवहार बंद होईपर्यंत वैध राहण्याची हमी दिली जाते. आधी नमूद केल्याप्रमाणे, बी-ट्री पृष्ठे ज्यावर ऑब्जेक्ट स्थित आहे, कॉपी-ऑन-राइट तत्त्वामुळे धन्यवाद, जोपर्यंत ते कमीतकमी एका व्यवहाराद्वारे संदर्भित केले जातात तोपर्यंत अपरिवर्तित राहतात. त्याच वेळी, त्यांच्याशी संबंधित शेवटचा व्यवहार पूर्ण होताच, पृष्ठे नवीन डेटासाठी पुन्हा वापरली जाऊ शकतात. वस्तूंनी व्युत्पन्न केलेल्या व्यवहारात टिकून राहणे आवश्यक असल्यास, त्यांना अद्याप कॉपी करणे आवश्यक आहे.
2. रीडराईट व्यवहारासाठी, परिणामी मूल्य संरचनेचा पॉइंटर केवळ प्रथम सुधारित प्रक्रिया (डेटा लिहिणे किंवा हटवणे) होईपर्यंत वैध असेल.
3. रचना असली तरी NodeValue पूर्ण वाढलेले नाही, परंतु ट्रिम केलेले ("बाह्य तुलनाकर्ता वापरून की ऑर्डर करणे" उपविभाग पहा), तुम्ही पॉइंटरद्वारे सुरक्षितपणे त्याच्या फील्डमध्ये प्रवेश करू शकता. मुख्य गोष्ट म्हणजे त्याचा आदर करणे नाही!
4. प्राप्त झालेल्या पॉइंटरद्वारे कोणत्याही परिस्थितीत रचना बदलू नये. सर्व बदल पद्धतीद्वारेच केले पाहिजेत mdb_put. तथापि, आपण हे कितीही कठीण करू इच्छित असले तरी, हे शक्य होणार नाही, कारण मेमरी क्षेत्र जेथे ही रचना स्थित आहे ते केवळ वाचनीय मोडमध्ये मॅप केलेले आहे.
5. फंक्शन वापरून जास्तीत जास्त स्टोरेज आकार वाढवण्याच्या उद्देशाने फाइलला प्रोसेस अॅड्रेस स्पेसवर रीमॅप करा mdb_env_set_map_size सर्वसाधारणपणे सर्व व्यवहार आणि संबंधित संस्था पूर्णपणे अवैध करते आणि विशिष्ट वस्तूंकडे निर्देश करते.

शेवटी, आणखी एक वैशिष्ट्य इतके कपटी आहे की त्याचे सार प्रकट करणे केवळ दुसर्या परिच्छेदात बसत नाही. बी-ट्री बद्दलच्या प्रकरणात, मी त्याची पृष्ठे स्मृतीमध्ये कशी व्यवस्थित केली आहेत याचा एक आकृती दिला आहे. यावरून असे दिसून येते की अनुक्रमित डेटासह बफरच्या सुरुवातीचा पत्ता पूर्णपणे अनियंत्रित असू शकतो. यामुळे, संरचनेत त्यांना सूचक प्राप्त झाला MDB_val आणि संरचनेच्या पॉईंटरवर कमी केले, ते सामान्य प्रकरणात असंरेखित असल्याचे दिसून येते. त्याच वेळी, काही चिप्सच्या आर्किटेक्चरसाठी (iOS च्या बाबतीत हे 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). एआरएमवर तुमचा समान परिणाम होऊ शकतो साध्य करणे आणि पॅक केलेले गुणधर्म वापरणे. संरचनेने व्यापलेली जागा ऑप्टिमाइझ करण्यास देखील मदत करते हे लक्षात घेता, ही पद्धत मला श्रेयस्कर वाटते, जरी कृती डेटा ऍक्सेस ऑपरेशन्सच्या खर्चात वाढ.

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

श्रेणी क्वेरी

रेकॉर्ड्सच्या समूहावर पुनरावृत्ती करण्यासाठी, LMDB कर्सर अॅब्स्ट्रॅक्शन प्रदान करते. आम्हाला आधीच परिचित असलेल्या वापरकर्त्याच्या क्लाउड मेटाडेटासह टेबलचे उदाहरण वापरून त्यासह कसे कार्य करायचे ते पाहू या.

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

अनुक्रमिक शोधाद्वारे थेट वरची सीमा शोधली जाऊ शकते. हे करण्यासाठी, कर्सर डेटाबेसमधील कीजच्या संपूर्ण सूचीच्या सुरूवातीस ठेवला जातो आणि त्याच्या खाली पॅरेंट डिरेक्टरीच्या आयडेंटिफायरसह एक की दिसेपर्यंत तो वाढविला जातो. या पद्धतीचे 2 स्पष्ट तोटे आहेत:

1. रेखीय शोध जटिलता, जरी ज्ञात आहे, सर्वसाधारणपणे झाडांमध्ये आणि विशेषतः बी-ट्रीमध्ये ते लॉगरिदमिक वेळेत केले जाऊ शकते.
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 वापरून पुनरावृत्तीचा भाग म्हणून, आम्हाला केवळ की नाही तर मूल्य देखील मिळते. जर, सॅम्पलिंग अटी पूर्ण करण्यासाठी, तुम्हाला इतर गोष्टींबरोबरच, रेकॉर्डच्या मूल्याच्या भागातील फील्ड तपासण्याची आवश्यकता असेल, तर ते अतिरिक्त जेश्चरशिवाय अगदी प्रवेशयोग्य आहेत.

४.३. टेबल दरम्यान मॉडेलिंग संबंध

आतापर्यंत, आम्ही एकल-टेबल डेटाबेससह डिझाइन आणि कार्य करण्याच्या सर्व पैलूंवर विचार करण्यास व्यवस्थापित केले आहे. आम्ही असे म्हणू शकतो की सारणी म्हणजे एकाच प्रकारच्या की-व्हॅल्यू जोड्यांचा समावेश असलेल्या क्रमवारी केलेल्या रेकॉर्डचा संच. तुम्ही आयत म्हणून की दाखवल्यास आणि संबंधित मूल्य समांतर पाईप म्हणून दाखवल्यास, तुम्हाला डेटाबेसचा व्हिज्युअल आकृती मिळेल.

​

तथापि, वास्तविक जीवनात इतके कमी रक्तपात करणे क्वचितच शक्य आहे. बर्‍याचदा डेटाबेसमध्ये, प्रथम, अनेक टेबल्स असणे आवश्यक असते आणि दुसरे म्हणजे, प्राथमिक कीपेक्षा वेगळ्या क्रमाने निवड करणे. हा शेवटचा विभाग त्यांच्या निर्मिती आणि परस्परसंबंधांच्या मुद्द्यांसाठी समर्पित आहे.

अनुक्रमणिका सारण्या

क्लाउड ऍप्लिकेशनमध्ये "गॅलरी" विभाग आहे. ते तारखेनुसार क्रमवारी लावलेल्या संपूर्ण क्लाउडमधील मीडिया सामग्री प्रदर्शित करते. अशी निवड चांगल्या प्रकारे अंमलात आणण्यासाठी, मुख्य सारणीच्या पुढे तुम्हाला नवीन प्रकारच्या कीसह आणखी एक तयार करणे आवश्यक आहे. त्यामध्ये फाइल तयार केल्याच्या तारखेसह फील्ड असेल, जे प्राथमिक क्रमवारी निकष म्हणून काम करेल. नवीन की मुख्य सारणीतील की सारख्याच डेटाचा संदर्भ देत असल्यामुळे त्यांना इंडेक्स की म्हणतात. खालील चित्रात ते नारिंगी रंगात हायलाइट केले आहेत.

एकाच डेटाबेसमध्ये वेगवेगळ्या टेबल्सच्या कळा एकमेकांपासून विभक्त करण्यासाठी, त्या सर्वांमध्ये एक अतिरिक्त तांत्रिक फील्ड टेबल आयडी जोडला गेला. वर्गीकरणासाठी सर्वोच्च प्राधान्य देऊन, आम्ही आमच्या स्वतःच्या नियमांनुसार - प्रथम सारण्यांनुसार आणि सारण्यांमध्ये कीचे गटबद्धीकरण साध्य करू.

इंडेक्स की प्राथमिक की सारख्याच डेटाचा संदर्भ देते. या मालमत्तेची प्राथमिक कीच्या मूल्य भागाची प्रत त्याच्याशी संलग्न करून त्याची सरळ अंमलबजावणी अनेक दृष्टिकोनातून इष्टतम नाही:

1. घेतलेल्या जागेच्या बाबतीत, मेटाडेटा खूप समृद्ध असू शकतो.
2. कार्यक्षमतेच्या दृष्टिकोनातून, नोडचा मेटाडेटा अद्यतनित करताना, तुम्हाला दोन की वापरून ते पुन्हा लिहावे लागेल.
3. कोड सपोर्टच्या दृष्टिकोनातून, आम्ही एका कीसाठी डेटा अपडेट करायला विसरलो तर, आम्हाला स्टोरेजमध्ये डेटा विसंगतीचा एक मायावी बग मिळेल.

पुढे, आपण या कमतरता कशा दूर करायच्या यावर विचार करू.

टेबल दरम्यान संबंध आयोजित करणे

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

टेबलांमधील संबंधांचे आयोजन करण्याचा आणखी एक नमुना आहे "अनावश्यक की". किल्लीमध्ये अतिरिक्त गुणधर्म जोडणे हे त्याचे सार आहे, जे क्रमवारी लावण्यासाठी नव्हे तर संबंधित की पुन्हा तयार करण्यासाठी आवश्यक आहे. Mail.ru क्लाउड ऍप्लिकेशनमध्ये त्याच्या वापराची वास्तविक उदाहरणे आहेत, तथापि, खोलवर जाणे टाळण्यासाठी विशिष्ट iOS फ्रेमवर्कचा संदर्भ, मी एक काल्पनिक, परंतु एक स्पष्ट उदाहरण देईन

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

सर्व अद्वितीय मेटाडेटा, नवीन सारणी तयार केलेल्या संग्रहित करण्यासाठी, रेकॉर्डच्या मूल्याच्या भागामध्ये ठेवली जाते. त्याच वेळी, आपण मुख्य सारणीमध्ये आधीपासून संग्रहित केलेल्या फायली आणि फोल्डर्सबद्दलचा डेटा डुप्लिकेट करू इच्छित नाही. त्याऐवजी, रिडंडंट डेटा “P” की मध्ये “नोड आयडी” आणि “टाइमस्टॅम्प” फील्डच्या स्वरूपात जोडला जातो. त्यांना धन्यवाद, तुम्ही इंडेक्स की तयार करू शकता, ज्यामधून तुम्ही प्राथमिक की मिळवू शकता, ज्यामधून, शेवटी, तुम्ही नोड मेटाडेटा मिळवू शकता.

निष्कर्ष

आम्ही LMDB च्या अंमलबजावणीच्या परिणामांचे सकारात्मक मूल्यांकन करतो. त्यानंतर, अर्ज गोठविण्याची संख्या 30% कमी झाली.

केलेल्या कामाचे परिणाम iOS संघाच्या पलीकडे प्रतिध्वनित झाले. सध्या, Android ऍप्लिकेशनमधील मुख्य "फाईल्स" विभागांपैकी एकाने LMDB वापरण्यास स्विच केले आहे आणि इतर भाग मार्गावर आहेत. C भाषा, ज्यामध्ये की-व्हॅल्यू स्टोअर कार्यान्वित केले जाते, सुरुवातीला C++ मध्ये क्रॉस-प्लॅटफॉर्मभोवती अनुप्रयोग फ्रेमवर्क तयार करण्यात चांगली मदत होती. परिणामी C++ लायब्ररीला ऑब्जेक्टिव्ह-सी आणि कोटलिन मधील प्लॅटफॉर्म कोडसह अखंडपणे जोडण्यासाठी कोड जनरेटर वापरला गेला. जिन्नी ड्रॉपबॉक्स वरून, पण ती पूर्णपणे वेगळी कथा आहे.

स्त्रोत: www.habr.com