2019 இலையுதிர்காலத்தில், Mail.ru கிளவுட் iOS குழுவில் நீண்டகாலமாக எதிர்பார்க்கப்பட்ட நிகழ்வு நிகழ்ந்தது. பயன்பாட்டு நிலையின் நிலையான சேமிப்பிற்கான முக்கிய தரவுத்தளம் மொபைல் உலகிற்கு மிகவும் கவர்ச்சியானது மின்னல் நினைவகம்-வரைபடப்பட்ட தரவுத்தளம் (எல்எம்டிபி) வெட்டுக்கு கீழே நாங்கள் உங்களுக்கு நான்கு பகுதிகளாக விரிவான மதிப்பாய்வை வழங்குகிறோம். முதலில், அத்தகைய அற்பமான மற்றும் கடினமான தேர்வுக்கான காரணங்களைப் பற்றி பேசலாம். பின்னர் LMDB கட்டமைப்பின் மையத்தில் உள்ள மூன்று தூண்களைக் கருத்தில் கொள்ளச் செல்வோம்: நினைவக-மேப் செய்யப்பட்ட கோப்புகள், B+-tree, பரிவர்த்தனை மற்றும் மல்டிவர்ஷனைச் செயல்படுத்துவதற்கான நகல்-ஆன்-ரைட் அணுகுமுறை. இறுதியாக, இனிப்புக்கு - நடைமுறை பகுதி. இதில், குறைந்த அளவிலான விசை மதிப்பு APIக்கு மேல் ஒரு குறியீட்டு ஒன்று உட்பட பல அட்டவணைகள் கொண்ட தரவுத்தள திட்டத்தை எவ்வாறு வடிவமைத்து செயல்படுத்துவது என்பதைப் பார்ப்போம்.

உள்ளடக்கம்

1. செயல்படுத்துவதற்கான உந்துதல்
2. LMDB நிலைப்படுத்தல்
3. எல்எம்டிபியின் மூன்று தூண்கள்
   3.1. திமிங்கலம் #1. நினைவக வரைபட கோப்புகள்
   3.2. திமிங்கிலம் #2. பி+-மரம்
   3.3. திமிங்கிலம் #3. நகல்-ஆன்-ரைட்
4. முக்கிய மதிப்பு APIக்கு மேல் தரவுத் திட்டத்தை வடிவமைத்தல்
   4.1. அடிப்படை சுருக்கங்கள்
   4.2. டேபிள் மாடலிங்
   4.3. அட்டவணைகளுக்கு இடையிலான மாடலிங் உறவுகள்

1. செயல்படுத்துவதற்கான உந்துதல்

2015 ஆம் ஆண்டில் ஒரு வருடம், எங்கள் பயன்பாட்டின் இடைமுகம் எவ்வளவு அடிக்கடி தாமதமாகிறது என்பதை அளவிடுவதில் சிரமம் எடுத்தோம். நாங்கள் ஒரு காரணத்திற்காக இதைச் செய்தோம். சில நேரங்களில் பயன்பாடு பயனர் செயல்களுக்கு பதிலளிப்பதை நிறுத்துகிறது என்று அடிக்கடி புகார்களைப் பெற்றுள்ளோம்: பொத்தான்களை அழுத்த முடியாது, பட்டியல்கள் உருட்டப்படாது போன்றவை. அளவீடுகளின் இயக்கவியல் பற்றி நான் சொன்னேன் AvitoTech இல், இங்கே நான் எண்களின் வரிசையை மட்டுமே தருகிறேன்.

அளவீட்டு முடிவுகள் எங்களுக்கு குளிர் மழையாக மாறியது. மற்றவற்றை விட உறைபனிகளால் ஏற்படும் பல சிக்கல்கள் உள்ளன என்று மாறியது. இந்த உண்மையை உணர்ந்து கொள்வதற்கு முன், தரத்தின் முக்கிய தொழில்நுட்பக் குறிகாட்டியானது செயலிழப்பு இல்லாததாக இருந்தால், கவனம் செலுத்திய பிறகு மாற்றப்பட்டது ஃப்ரீஸ் ஃப்ரீயில்.

கட்டியது முடக்கம் கொண்ட டாஷ்போர்டு மற்றும் செலவு செய்த பிறகு அளவு и தரம் அவர்களின் காரணங்களின் பகுப்பாய்வு, முக்கிய எதிரி தெளிவாகிவிட்டார் - கனரக வணிக தர்க்கம் பயன்பாட்டின் முக்கிய நூலில் செயல்படுத்தப்பட்டது. இந்த அவமானத்திற்கு இயற்கையான எதிர்வினை, அதை வேலை நீரோடைகளில் தள்ளுவதற்கான எரியும் ஆசை. இந்த சிக்கலை முறையாக தீர்க்க, இலகுரக நடிகர்களை அடிப்படையாகக் கொண்ட பல-திரிக்கப்பட்ட கட்டமைப்பை நாங்கள் நாடினோம். iOS உலகத்திற்கான அதன் தழுவலுக்கு நான் அதை அர்ப்பணித்தேன் இரண்டு நூல்கள் கூட்டு ட்விட்டரில் மற்றும் ஹப்ரே பற்றிய கட்டுரை. தற்போதைய கதையின் ஒரு பகுதியாக, தரவுத்தளத்தின் தேர்வில் தாக்கத்தை ஏற்படுத்திய முடிவின் அம்சங்களை நான் வலியுறுத்த விரும்புகிறேன்.

சிஸ்டம் அமைப்பின் நடிகர் மாதிரியானது மல்டித்ரெடிங் அதன் இரண்டாவது சாரமாக மாறும் என்று கருதுகிறது. அதில் உள்ள மாதிரி பொருள்கள் ஸ்ட்ரீம் எல்லைகளை கடக்க விரும்புகின்றன. அவர்கள் இதைச் செய்கிறார்கள் சில சமயங்களில் இங்கேயும் அங்கேயும் இல்லை, ஆனால் கிட்டத்தட்ட எல்லா இடங்களிலும் தொடர்ந்து செய்கிறார்கள்

தரவுத்தளமானது வழங்கப்பட்ட வரைபடத்தில் உள்ள அடிப்படைக் கூறுகளில் ஒன்றாகும். அதன் முக்கிய பணி மேக்ரோபாட்டர்னை செயல்படுத்துவதாகும் பகிரப்பட்ட தரவுத்தளம். நிறுவன உலகில் சேவைகளுக்கு இடையில் தரவு ஒத்திசைவை ஒழுங்கமைக்க இது பயன்படுத்தப்பட்டால், நடிகர் கட்டிடக்கலை விஷயத்தில் - நூல்களுக்கு இடையிலான தரவு. எனவே, பல திரிக்கப்பட்ட சூழலில் அதனுடன் பணிபுரியும் போது குறைந்தபட்ச சிரமங்களை கூட ஏற்படுத்தாத தரவுத்தளம் எங்களுக்குத் தேவைப்பட்டது. குறிப்பாக, அதிலிருந்து பெறப்படும் பொருள்கள் குறைந்தபட்சம் நூல்-பாதுகாப்பாகவும், முற்றிலும் மாறாததாகவும் இருக்க வேண்டும் என்பதே இதன் பொருள். உங்களுக்குத் தெரியும், பிந்தையது எந்தவொரு பூட்டுதலையும் நாடாமல் பல நூல்களிலிருந்து ஒரே நேரத்தில் பயன்படுத்தப்படலாம், இது செயல்திறனில் நன்மை பயக்கும்.

தரவுத்தளத்தின் தேர்வை பாதித்த இரண்டாவது குறிப்பிடத்தக்க காரணி எங்கள் கிளவுட் API ஆகும். இது git ஆல் பின்பற்றப்பட்ட ஒத்திசைவு அணுகுமுறையால் ஈர்க்கப்பட்டது. அவரைப் போலவே நாங்களும் குறி வைத்தோம் ஆஃப்லைன்-முதல் API, இது கிளவுட் கிளையண்டுகளுக்கு மிகவும் பொருத்தமானதாகத் தெரிகிறது. அவை மேகத்தின் முழு நிலையை ஒரு முறை மட்டுமே பம்ப் செய்யும் என்று கருதப்பட்டது, பின்னர் பெரும்பாலான நிகழ்வுகளில் ஒத்திசைவு மாற்றங்கள் மூலம் ஏற்படும். ஐயோ, இந்த வாய்ப்பு இன்னும் கோட்பாட்டு மண்டலத்தில் மட்டுமே உள்ளது, மேலும் வாடிக்கையாளர்கள் நடைமுறையில் இணைப்புகளுடன் எவ்வாறு வேலை செய்வது என்பதை அறியவில்லை. இதற்கு பல புறநிலை காரணங்கள் உள்ளன, அவை அறிமுகத்தை தாமதப்படுத்தாமல் இருக்க, அடைப்புக்குறிக்குள் விட்டுவிடுவோம். இப்போது, ​​ஒரு API "A" என்று கூறும்போது மற்றும் அதன் நுகர்வோர் "B" என்று கூறாதபோது என்ன நடக்கும் என்பது பற்றிய பாடத்தின் அறிவுறுத்தலான முடிவுகள் மிகவும் ஆர்வமாக உள்ளன.

எனவே, இழுக்கும் கட்டளையை இயக்கும் போது, ​​லோக்கல் ஸ்னாப்ஷாட்டில் பேட்ச்களைப் பயன்படுத்துவதற்குப் பதிலாக, அதன் முழு நிலையை முழு சர்வர் நிலையுடன் ஒப்பிட்டுப் பார்க்கும் git ஐ நீங்கள் கற்பனை செய்தால், கிளவுட்டில் ஒத்திசைவு எவ்வாறு நிகழ்கிறது என்பது பற்றிய துல்லியமான யோசனை உங்களுக்கு இருக்கும். வாடிக்கையாளர்கள். அதைச் செயல்படுத்த, அனைத்து சர்வர் மற்றும் உள்ளூர் கோப்புகளைப் பற்றிய மெட்டா தகவலுடன் இரண்டு DOM மரங்களை நினைவகத்தில் ஒதுக்க வேண்டும் என்று யூகிக்க எளிதானது. ஒரு பயனர் கிளவுட்டில் 500 ஆயிரம் கோப்புகளை சேமித்து வைத்தால், அதை ஒத்திசைக்க 1 மில்லியன் முனைகளுடன் இரண்டு மரங்களை மீண்டும் உருவாக்கி அழிக்க வேண்டியது அவசியம். ஆனால் ஒவ்வொரு முனையும் துணைப் பொருள்களின் வரைபடத்தைக் கொண்ட மொத்தமாகும். இந்த வெளிச்சத்தில், விவரக்குறிப்பு முடிவுகள் எதிர்பார்க்கப்பட்டன. ஒன்றிணைக்கும் வழிமுறையை கணக்கில் எடுத்துக் கொள்ளாமல், ஒரு பெரிய எண்ணிக்கையிலான சிறிய பொருட்களை உருவாக்கி அழிக்கும் செயல்முறைக்கு ஒரு அழகான பைசா செலவாகும். பயனர் ஸ்கிரிப்டுகள். இதன் விளைவாக, தரவுத்தளத்தைத் தேர்ந்தெடுப்பதில் இரண்டாவது முக்கியமான அளவுகோலை நாங்கள் சரிசெய்கிறோம் - பொருள்களின் மாறும் ஒதுக்கீடு இல்லாமல் CRUD செயல்பாடுகளைச் செயல்படுத்தும் திறன்.

பிற தேவைகள் மிகவும் பாரம்பரியமானவை மற்றும் அவற்றின் முழு பட்டியல் பின்வருமாறு.

1. நூல் பாதுகாப்பு.
2. பல செயலாக்கம். அதே தரவுத்தள நிகழ்வை தொடரிழைகளுக்கு இடையில் மட்டுமல்லாமல், முக்கிய பயன்பாடு மற்றும் iOS நீட்டிப்புகளுக்கு இடையில் ஒத்திசைக்க அதே தரவுத்தள நிகழ்வைப் பயன்படுத்துவதற்கான விருப்பத்தால் கட்டளையிடப்பட்டது.
3. சேமிக்கப்பட்ட நிறுவனங்களை மாற்ற முடியாத பொருள்களாகக் குறிக்கும் திறன்
4. CRUD செயல்பாடுகளுக்குள் டைனமிக் ஒதுக்கீடுகள் இல்லை.
5. அடிப்படை சொத்துக்களுக்கான பரிவர்த்தனை ஆதரவு ACID: அணு, நிலைத்தன்மை, தனிமைப்படுத்தல் மற்றும் நம்பகத்தன்மை.
6. மிகவும் பிரபலமான வழக்குகளில் வேகம்.

இந்த தேவைகளின் தொகுப்புடன், SQLite ஒரு நல்ல தேர்வாக இருந்தது. இருப்பினும், மாற்று ஆய்வுகளின் ஒரு பகுதியாக, நான் ஒரு புத்தகத்தைக் கண்டேன் "LevelDB உடன் தொடங்குதல்". அவரது தலைமையின் கீழ், உண்மையான கிளவுட் காட்சிகளில் வெவ்வேறு தரவுத்தளங்களுடன் பணியின் வேகத்தை ஒப்பிட்டு ஒரு அளவுகோல் எழுதப்பட்டது. முடிவு எங்களின் மிகப்பெரிய எதிர்பார்ப்புகளை தாண்டியது. மிகவும் பிரபலமான சந்தர்ப்பங்களில் - அனைத்து கோப்புகளின் வரிசைப்படுத்தப்பட்ட பட்டியலிலும், கொடுக்கப்பட்ட கோப்பகத்திற்கான அனைத்து கோப்புகளின் வரிசைப்படுத்தப்பட்ட பட்டியலிலும் கர்சரைப் பெறுதல் - LMDB SQLite ஐ விட 10 மடங்கு வேகமானது. தேர்வு தெளிவாகியது.

2. LMDB நிலைப்படுத்தல்

LMDB என்பது மிகவும் சிறிய நூலகமாகும் (10K வரிசைகள் மட்டுமே) இது தரவுத்தளங்களின் மிகக் குறைந்த அடிப்படை அடுக்கு - சேமிப்பகத்தை செயல்படுத்துகிறது.

மேலே உள்ள வரைபடம் SQLite உடன் LMDB ஐ ஒப்பிடுவது, உயர் நிலைகளை செயல்படுத்துகிறது, பொதுவாக SQLite உடன் கோர் டேட்டாவை விட சரியானது அல்ல. பெர்க்லிடிபி, லெவல்டிபி, சோபியா, ராக்ஸ்டிபி போன்ற அதே சேமிப்பக இயந்திரங்களை சம போட்டியாளர்களாக மேற்கோள் காட்டுவது மிகவும் நியாயமானதாக இருக்கும். SQLiteக்கான சேமிப்பக இயந்திர அங்கமாக LMDB செயல்படும் முன்னேற்றங்கள் கூட உள்ளன. இதுபோன்ற முதல் சோதனை 2012 இல் இருந்தது செலவிடப்பட்டது LMDB மூலம் ஹோவர்ட் சூ. Результаты அவரது முன்முயற்சி OSS ஆர்வலர்களால் எடுக்கப்பட்டது, மேலும் அதன் தொடர்ச்சியை அந்த நபரிடம் கண்டறிந்தது. LumoSQL. ஜனவரி 2020 இல், இந்த திட்டத்தின் ஆசிரியர் டென் ஷீரர் ஆவார் வழங்கினார் இது LinuxConfAu இல் உள்ளது.

LMDB முக்கியமாக பயன்பாட்டு தரவுத்தளங்களுக்கான இயந்திரமாகப் பயன்படுத்தப்படுகிறது. நூலகம் அதன் தோற்றத்திற்கு டெவலப்பர்களுக்கு கடன்பட்டுள்ளது OpenLDAP, பெர்க்லிடிபியை தங்கள் திட்டத்திற்கான அடிப்படையாக கொண்டு மிகுந்த அதிருப்தியில் இருந்தனர். ஒரு சாதாரண நூலகத்திலிருந்து தொடங்குதல் btree, ஹோவர்ட் சூ நம் காலத்தின் மிகவும் பிரபலமான மாற்றுகளில் ஒன்றை உருவாக்க முடிந்தது. அவர் தனது மிக அருமையான அறிக்கையை இந்தக் கதைக்கும், அதே போல் எல்எம்டிபியின் உள் அமைப்புக்கும் அர்ப்பணித்தார். "தி லைட்னிங் மெமரி-மேப்ட் டேட்டாபேஸ்". ஒரு சேமிப்பு வசதியை கைப்பற்றுவதற்கான ஒரு சிறந்த உதாரணம் லியோனிட் யூரியேவ் (aka yleo) ஹைலோட் 2015 இல் அவரது அறிக்கையில் நேர்மறை தொழில்நுட்பங்களிலிருந்து "எல்எம்டிபி இயந்திரம் ஒரு சிறப்பு சாம்பியன்". அதில், ReOpenLDAP ஐ செயல்படுத்தும் இதேபோன்ற பணியின் பின்னணியில் அவர் LMDB பற்றி பேசுகிறார், மேலும் LevelDB ஏற்கனவே ஒப்பீட்டு விமர்சனத்திற்கு உட்பட்டுள்ளது. செயல்படுத்தப்பட்டதன் விளைவாக, பாசிட்டிவ் டெக்னாலஜிஸ் தீவிரமாக வளரும் ஃபோர்க் கூட இருந்தது MDBX மிகவும் சுவையான அம்சங்கள், மேம்படுத்தல்கள் மற்றும் பிழைத்திருத்தங்கள்.

LMDB பெரும்பாலும் சேமிப்பகமாகப் பயன்படுத்தப்படுகிறது. உதாரணமாக, Mozilla Firefox உலாவி தேர்வு செய்தார் இது பல தேவைகளுக்காக, மற்றும், பதிப்பு 9, Xcode இலிருந்து தொடங்குகிறது விருப்பமான குறியீடுகளை சேமிப்பதற்கான அதன் SQLite.

மொபைல் டெவலப்மெண்ட் உலகிலும் இந்த எஞ்சின் தன் முத்திரையைப் பதித்துள்ளது. அதன் பயன்பாட்டின் தடயங்கள் இருக்கலாம் найти டெலிகிராமிற்கான iOS கிளையண்டில். லிங்க்ட்இன் இன்னும் மேலே சென்று, அதன் உள்நாட்டு தரவு கேச்சிங் கட்டமைப்பான ராக்கெட் டேட்டாவிற்கான இயல்புநிலை சேமிப்பகமாக LMDBயைத் தேர்ந்தெடுத்தது. கூறினார் 2016 இல் அவரது கட்டுரையில்.

ஆரக்கிளின் கட்டுப்பாட்டின் கீழ் வந்த பிறகு பெர்க்லிடிபி விட்டுச் சென்ற இடத்தில் வெயிலில் இடம் பெறுவதற்காக எல்எம்டிபி வெற்றிகரமாகப் போராடி வருகிறது. நூலகம் அதன் வேகம் மற்றும் நம்பகத்தன்மைக்காக விரும்பப்படுகிறது, அதன் சகாக்களுடன் ஒப்பிடும்போது கூட. உங்களுக்குத் தெரியும், இலவச மதிய உணவுகள் எதுவும் இல்லை, மேலும் LMDB மற்றும் SQLite ஆகியவற்றுக்கு இடையே தேர்ந்தெடுக்கும் போது நீங்கள் எதிர்கொள்ள வேண்டிய வர்த்தகத்தை நான் வலியுறுத்த விரும்புகிறேன். மேலே உள்ள வரைபடம், அதிகரித்த வேகம் எவ்வாறு அடையப்படுகிறது என்பதை தெளிவாகக் காட்டுகிறது. முதலில், வட்டு சேமிப்பகத்தின் மேல் சுருக்கத்தின் கூடுதல் அடுக்குகளுக்கு நாங்கள் பணம் செலுத்த மாட்டோம். அவை இல்லாமல் ஒரு நல்ல கட்டிடக்கலை இன்னும் செய்ய முடியாது என்பது தெளிவாகிறது, மேலும் அவை தவிர்க்க முடியாமல் பயன்பாட்டுக் குறியீட்டில் தோன்றும், ஆனால் அவை மிகவும் நுட்பமானதாக இருக்கும். ஒரு குறிப்பிட்ட பயன்பாட்டிற்குத் தேவைப்படாத அம்சங்களை அவை கொண்டிருக்காது, எடுத்துக்காட்டாக, SQL மொழியில் வினவல்களுக்கான ஆதரவு. இரண்டாவதாக, வட்டு சேமிப்பகத்திற்கான கோரிக்கைகளில் பயன்பாட்டு செயல்பாடுகளின் மேப்பிங்கை உகந்த முறையில் செயல்படுத்துவது சாத்தியமாகும். SQLite என்றால் என் வேலையில் சராசரி பயன்பாட்டின் சராசரி புள்ளிவிவரத் தேவைகளை அடிப்படையாகக் கொண்டது, ஒரு பயன்பாட்டு உருவாக்குநராக நீங்கள் முக்கிய பணிச்சுமை சூழ்நிலைகளை நன்கு அறிந்திருக்கிறீர்கள். அதிக உற்பத்தித் தீர்வுக்கு, ஆரம்ப தீர்வை உருவாக்குவதற்கும் அதன் பின் வரும் ஆதரவிற்கும் நீங்கள் அதிகரித்த விலைக் குறியை செலுத்த வேண்டும்.

3. எல்எம்டிபியின் மூன்று தூண்கள்

ஒரு பறவையின் பார்வையில் இருந்து LMDB ஐப் பார்த்த பிறகு, ஆழமாகச் செல்ல வேண்டிய நேரம் இது. அடுத்த மூன்று பிரிவுகள் சேமிப்பக கட்டிடக்கலை தங்கியுள்ள முக்கிய தூண்களின் பகுப்பாய்விற்கு அர்ப்பணிக்கப்படும்:

1. நினைவக-மேப் செய்யப்பட்ட கோப்புகள் வட்டுடன் வேலை செய்வதற்கும் உள் தரவு கட்டமைப்புகளை ஒத்திசைப்பதற்கும் ஒரு பொறிமுறையாக.
2. சேமிக்கப்பட்ட தரவுகளின் கட்டமைப்பின் அமைப்பாக B+-மரம்.
3. ACID பரிவர்த்தனை பண்புகள் மற்றும் மல்டிவெர்ஷனை வழங்குவதற்கான அணுகுமுறையாக நகல்-ஆன்-ரைட்.

3.1 திமிங்கலம் #1. நினைவக வரைபட கோப்புகள்

மெமரி-மேப் செய்யப்பட்ட கோப்புகள் ஒரு முக்கியமான கட்டடக்கலை உறுப்பு ஆகும், அவை களஞ்சியத்தின் பெயரில் கூட தோன்றும். சேமிக்கப்பட்ட தகவல்களுக்கான அணுகலை தேக்குதல் மற்றும் ஒத்திசைத்தல் தொடர்பான சிக்கல்கள் முற்றிலும் இயக்க முறைமைக்கு விடப்படுகின்றன. LMDB தன்னுள் எந்த தற்காலிக சேமிப்புகளையும் கொண்டிருக்கவில்லை. இது ஆசிரியரின் நனவான முடிவாகும், ஏனெனில் மேப் செய்யப்பட்ட கோப்புகளிலிருந்து தரவை நேரடியாகப் படிப்பது இயந்திர செயலாக்கத்தில் நிறைய மூலைகளை வெட்ட அனுமதிக்கிறது. அவற்றில் சிலவற்றின் முழுமையான பட்டியலிலிருந்து வெகு தொலைவில் கீழே உள்ளது.

1. பல செயல்முறைகளில் இருந்து பணிபுரியும் போது சேமிப்பகத்தில் உள்ள தரவின் நிலைத்தன்மையை பராமரிப்பது இயக்க முறைமையின் பொறுப்பாகும். அடுத்த பகுதியில், இந்த இயக்கவியல் விரிவாக மற்றும் படங்களுடன் விவாதிக்கப்படுகிறது.
2. தற்காலிக சேமிப்புகள் இல்லாதது, டைனமிக் ஒதுக்கீடுகளுடன் தொடர்புடைய மேல்நிலையிலிருந்து எல்எம்டிபியை முற்றிலுமாக நீக்குகிறது. நடைமுறையில் தரவைப் படிப்பது என்பது மெய்நிகர் நினைவகத்தில் சரியான முகவரிக்கு ஒரு சுட்டியை அமைப்பதாகும், அதற்கு மேல் எதுவும் இல்லை. இது அறிவியல் புனைகதை போல் தெரிகிறது, ஆனால் சேமிப்பக மூலக் குறியீட்டில் Calocக்கான அனைத்து அழைப்புகளும் சேமிப்பக உள்ளமைவு செயல்பாட்டில் குவிந்துள்ளன.
3. தற்காலிக சேமிப்புகள் இல்லாதது அவற்றின் அணுகலின் ஒத்திசைவுடன் தொடர்புடைய பூட்டுகள் இல்லாததையும் குறிக்கிறது. ஒரே நேரத்தில் தன்னிச்சையான எண்ணிக்கையிலான வாசகர்கள் இருக்கக்கூடிய வாசகர்கள், தரவுக்குச் செல்லும் வழியில் ஒரு மியூடெக்ஸைக் கூட சந்திப்பதில்லை. இதன் காரணமாக, CPUகளின் எண்ணிக்கையின் அடிப்படையில் வாசிப்பு வேகம் சிறந்த நேரியல் அளவிடக்கூடிய தன்மையைக் கொண்டுள்ளது. LMDB இல், மாற்றியமைக்கும் செயல்பாடுகள் மட்டுமே ஒத்திசைக்கப்படுகின்றன. ஒரு நேரத்தில் ஒரு எழுத்தாளர் மட்டுமே இருக்க முடியும்.
4. குறைந்தபட்ச கேச்சிங் மற்றும் ஒத்திசைவு தர்க்கம், பல-திரிக்கப்பட்ட சூழலில் பணிபுரிவதில் தொடர்புடைய மிகவும் சிக்கலான வகை பிழைகளை நீக்குகிறது. Usenix OSDI 2014 மாநாட்டில் இரண்டு சுவாரஸ்யமான தரவுத்தள ஆய்வுகள் இருந்தன: "அனைத்து கோப்பு முறைமைகளும் சமமாக உருவாக்கப்படவில்லை: செயலிழப்பு-நிலையான பயன்பாடுகளை உருவாக்குவதற்கான சிக்கலானது" и "வேடிக்கை மற்றும் லாபத்திற்காக சித்திரவதை தரவுத்தளங்கள்". அவற்றிலிருந்து LMDB இன் முன்னோடியில்லாத நம்பகத்தன்மை மற்றும் ACID பரிவர்த்தனை பண்புகளின் கிட்டத்தட்ட குறைபாடற்ற செயலாக்கம் ஆகிய இரண்டையும் பற்றிய தகவல்களை நீங்கள் பெறலாம், இது SQLite இல் உள்ளதை விட சிறந்தது.
5. எல்எம்டிபியின் மினிமலிசம், அதன் குறியீட்டின் இயந்திரப் பிரதிநிதித்துவத்தை, செயலியின் எல்1 தற்காலிக சேமிப்பில், அடுத்தடுத்த வேகப் பண்புகளுடன் முழுமையாக இருக்க அனுமதிக்கிறது.

துரதிர்ஷ்டவசமாக, iOS இல், நினைவக-மேப் செய்யப்பட்ட கோப்புகளுடன், எல்லாம் நாம் விரும்பும் அளவுக்கு மேகமற்றதாக இல்லை. அவற்றுடன் தொடர்புடைய குறைபாடுகளைப் பற்றி மேலும் உணர்வுடன் பேசுவதற்கு, இயக்க முறைமைகளில் இந்த பொறிமுறையை செயல்படுத்துவதற்கான பொதுவான கொள்கைகளை நினைவில் கொள்வது அவசியம்.

நினைவகம் வரையப்பட்ட கோப்புகள் பற்றிய பொதுவான தகவல்கள்

இயங்கும் ஒவ்வொரு பயன்பாட்டிலும், இயக்க முறைமை ஒரு செயல்முறை எனப்படும் ஒரு நிறுவனத்தை இணைக்கிறது. ஒவ்வொரு செயல்முறைக்கும் ஒரு தொடர்ச்சியான முகவரிகள் ஒதுக்கப்படுகின்றன, அதில் அது செயல்படத் தேவையான அனைத்தையும் வைக்கிறது. குறைந்த முகவரிகளில் குறியீடு மற்றும் கடின குறியிடப்பட்ட தரவு மற்றும் ஆதாரங்கள் கொண்ட பிரிவுகள் உள்ளன. அடுத்து, டைனமிக் அட்ரஸ் ஸ்பேஸின் வளர்ந்து வரும் தொகுதி, குவியல் என்ற பெயரில் நமக்கு நன்கு தெரியும். நிரலின் செயல்பாட்டின் போது தோன்றும் நிறுவனங்களின் முகவரிகள் இதில் உள்ளன. அப்ளிகேஷன் ஸ்டாக் பயன்படுத்தும் நினைவகப் பகுதி மேலே உள்ளது. இது வளரும் அல்லது சுருங்குகிறது; வேறுவிதமாகக் கூறினால், அதன் அளவும் ஒரு மாறும் தன்மையைக் கொண்டுள்ளது. ஸ்டாக் மற்றும் குவியல் ஒன்றுக்கொன்று தள்ளுவதையும் குறுக்கிடுவதையும் தடுக்க, அவை முகவரி இடத்தின் வெவ்வேறு முனைகளில் அமைந்துள்ளன. மேல் மற்றும் கீழ் இரண்டு டைனமிக் பிரிவுகளுக்கு இடையே ஒரு துளை உள்ளது. இயக்க முறைமையானது இந்த நடுப் பிரிவில் உள்ள முகவரிகளைப் பயன்படுத்தி பல்வேறு வகையான நிறுவனங்களை செயல்முறையுடன் இணைக்கிறது. குறிப்பாக, இது ஒரு குறிப்பிட்ட தொடர்ச்சியான முகவரிகளை வட்டில் உள்ள ஒரு கோப்புடன் இணைக்க முடியும். அத்தகைய கோப்பு நினைவகம்-வரைபடம் என்று அழைக்கப்படுகிறது

செயல்முறைக்கு ஒதுக்கப்பட்ட முகவரி இடம் மிகப்பெரியது. கோட்பாட்டளவில், முகவரிகளின் எண்ணிக்கை சுட்டியின் அளவால் மட்டுமே வரையறுக்கப்படுகிறது, இது கணினியின் பிட் திறனால் தீர்மானிக்கப்படுகிறது. இயற்பியல் நினைவகம் 1 முதல் 1 வரை வரைபடமாக்கப்பட்டால், முதல் செயல்முறை முழு ரேமையும் உறிஞ்சிவிடும், மேலும் பல்பணி பற்றிய பேச்சு எதுவும் இருக்காது.

எவ்வாறாயினும், நவீன இயக்க முறைமைகள் ஒரே நேரத்தில் விரும்பும் பல செயல்முறைகளை இயக்க முடியும் என்பதை எங்கள் அனுபவத்திலிருந்து நாங்கள் அறிவோம். அவை காகிதத்தில் உள்ள செயல்முறைகளுக்கு மட்டுமே அதிக நினைவகத்தை ஒதுக்குகின்றன என்பதன் காரணமாக இது சாத்தியமாகும், ஆனால் உண்மையில் அவை இங்கேயும் இப்போதும் தேவைப்படும் பகுதியை மட்டுமே முக்கிய இயற்பியல் நினைவகத்தில் ஏற்றுகின்றன. எனவே, ஒரு செயல்முறையுடன் தொடர்புடைய நினைவகம் மெய்நிகர் என்று அழைக்கப்படுகிறது.

இயக்க முறைமை மெய்நிகர் மற்றும் உடல் நினைவகத்தை ஒரு குறிப்பிட்ட அளவிலான பக்கங்களாக ஒழுங்கமைக்கிறது. மெய்நிகர் நினைவகத்தின் ஒரு குறிப்பிட்ட பக்கம் தேவைப்பட்டவுடன், இயக்க முறைமை அதை இயற்பியல் நினைவகத்தில் ஏற்றுகிறது மற்றும் அவற்றை ஒரு சிறப்பு அட்டவணையில் பொருத்துகிறது. இலவச ஸ்லாட்டுகள் இல்லை என்றால், முன்பு ஏற்றப்பட்ட பக்கங்களில் ஒன்று வட்டில் நகலெடுக்கப்படும், மேலும் தேவைப்படும் ஒன்று அதன் இடத்தைப் பிடிக்கும். இந்த செயல்முறை, நாம் விரைவில் திரும்புவோம், இது இடமாற்றம் என்று அழைக்கப்படுகிறது. கீழே உள்ள படம் விவரிக்கப்பட்ட செயல்முறையை விளக்குகிறது. அதில், முகவரி 0 உடன் பக்கம் A ஏற்றப்பட்டு, முதன்மை நினைவகப் பக்கத்தில் முகவரி 4 உடன் வைக்கப்பட்டது. இந்த உண்மை செல் எண் 0 இல் உள்ள கடித அட்டவணையில் பிரதிபலிக்கிறது.

நினைவகத்திற்கு வரைபடமாக்கப்பட்ட கோப்புகளுடன் கதை சரியாகவே உள்ளது. தர்க்கரீதியாக, அவை தொடர்ச்சியாகவும் முழுமையாகவும் மெய்நிகர் முகவரி இடத்தில் அமைந்துள்ளன. இருப்பினும், அவை இயற்பியல் நினைவகத்தை பக்கம் வாரியாக உள்ளிடுகின்றன மற்றும் கோரிக்கையின் பேரில் மட்டுமே. அத்தகைய பக்கங்களின் மாற்றம் வட்டில் உள்ள கோப்புடன் ஒத்திசைக்கப்படுகிறது. இந்த வழியில், நீங்கள் நினைவகத்தில் பைட்டுகளுடன் வேலை செய்வதன் மூலம் கோப்பு I/O ஐச் செய்யலாம் - அனைத்து மாற்றங்களும் இயங்குதள கர்னலால் மூலக் கோப்பிற்கு தானாகவே மாற்றப்படும்.
​
வெவ்வேறு செயல்முறைகளிலிருந்து தரவுத்தளத்துடன் பணிபுரியும் போது LMDB அதன் நிலையை எவ்வாறு ஒத்திசைக்கிறது என்பதை கீழே உள்ள படம் விளக்குகிறது. வெவ்வேறு செயல்முறைகளின் மெய்நிகர் நினைவகத்தை ஒரே கோப்பில் மேப்பிங் செய்வதன் மூலம், எல்எம்டிபி தோற்றமளிக்கும் இடத்தில் அவற்றின் முகவரி இடைவெளிகளின் சில தொகுதிகளை இடைநிலையாக ஒத்திசைக்க இயக்க முறைமையை நாங்கள் கட்டாயப்படுத்துகிறோம்.
​

ஒரு முக்கியமான நுணுக்கம் என்னவென்றால், எல்எம்டிபி, இயல்புநிலையாக, ரைட் சிஸ்டம் கால் மெக்கானிசம் மூலம் தரவுக் கோப்பை மாற்றியமைக்கிறது, மேலும் கோப்பை படிக்க மட்டும் பயன்முறையில் காண்பிக்கும். இந்த அணுகுமுறை இரண்டு முக்கியமான விளைவுகளைக் கொண்டுள்ளது.

முதல் விளைவு அனைத்து இயக்க முறைமைகளுக்கும் பொதுவானது. தவறான குறியீடு மூலம் தரவுத்தளத்திற்கு தற்செயலாக சேதம் ஏற்படுவதற்கு எதிராக பாதுகாப்பைச் சேர்ப்பதே இதன் சாராம்சம். உங்களுக்குத் தெரியும், ஒரு செயல்முறையின் இயங்கக்கூடிய வழிமுறைகள் அதன் முகவரி இடத்தில் எங்கிருந்தும் தரவை அணுக இலவசம். அதே நேரத்தில், நாம் இப்போது நினைவில் வைத்துள்ளபடி, ஒரு கோப்பை படிக்க-எழுத்து பயன்முறையில் காண்பிப்பது என்பது எந்த அறிவுறுத்தலும் அதை மாற்றியமைக்க முடியும். அவள் தவறுதலாக இதைச் செய்தால், எடுத்துக்காட்டாக, இல்லாத குறியீட்டில் ஒரு வரிசை உறுப்பை மேலெழுத முயற்சித்தால், அவள் தற்செயலாக இந்த முகவரிக்கு மேப் செய்யப்பட்ட கோப்பை மாற்றலாம், இது தரவுத்தளத்தின் சிதைவுக்கு வழிவகுக்கும். கோப்பு படிக்க-மட்டும் பயன்முறையில் காட்டப்பட்டால், தொடர்புடைய முகவரி இடத்தை மாற்றும் முயற்சியானது சிக்னலுடன் நிரலை அவசரமாக நிறுத்துவதற்கு வழிவகுக்கும். SIGSEGV, மற்றும் கோப்பு அப்படியே இருக்கும்.

இரண்டாவது விளைவு ஏற்கனவே iOS க்கு குறிப்பிட்டது. ஆசிரியரோ அல்லது வேறு எந்த ஆதாரங்களோ அதை வெளிப்படையாகக் குறிப்பிடவில்லை, ஆனால் அது இல்லாமல் LMDB இந்த மொபைல் இயக்க முறைமையில் இயங்குவதற்கு ஏற்றதாக இருக்காது. அடுத்த பகுதி அதன் பரிசீலனைக்கு அர்ப்பணிக்கப்பட்டுள்ளது.

iOS இல் நினைவக-மேப் செய்யப்பட்ட கோப்புகளின் விவரக்குறிப்புகள்

2018 இல் WWDC இல் ஒரு அற்புதமான அறிக்கை இருந்தது "iOS மெமரி டீப் டைவ்". இது iOS இல், உடல் நினைவகத்தில் அமைந்துள்ள அனைத்து பக்கங்களும் 3 வகைகளில் ஒன்றாகும்: அழுக்கு, சுருக்கப்பட்ட மற்றும் சுத்தமானது.

சுத்தமான நினைவகம் என்பது உடல் நினைவகத்திலிருந்து வலியின்றி இறக்கக்கூடிய பக்கங்களின் தொகுப்பாகும். அவை கொண்டிருக்கும் தரவு அதன் அசல் மூலங்களிலிருந்து தேவைக்கேற்ப மீண்டும் ஏற்றப்படும். படிக்க மட்டுமே நினைவகம் வரையப்பட்ட கோப்புகள் இந்த வகைக்குள் அடங்கும். எந்த நேரத்திலும் நினைவகத்திலிருந்து ஒரு கோப்பில் மேப் செய்யப்பட்ட பக்கங்களை இறக்குவதற்கு iOS பயப்படவில்லை, ஏனெனில் அவை வட்டில் உள்ள கோப்புடன் ஒத்திசைக்கப்படும் என்று உத்தரவாதம் அளிக்கப்படுகிறது.
​
அனைத்து மாற்றியமைக்கப்பட்ட பக்கங்களும் அழுக்கு நினைவகத்தில் முடிவடையும், அவை முதலில் எங்கிருந்தாலும் சரி. குறிப்பாக, அவற்றுடன் தொடர்புடைய மெய்நிகர் நினைவகத்தில் எழுதுவதன் மூலம் மாற்றியமைக்கப்பட்ட நினைவக-மேப் செய்யப்பட்ட கோப்புகள் இவ்வாறு வகைப்படுத்தப்படும். கொடியுடன் LMDBஐத் திறக்கிறது MDB_WRITEMAP, அதில் மாற்றங்களைச் செய்த பிறகு, இதை நீங்கள் தனிப்பட்ட முறையில் சரிபார்க்கலாம்

ஒரு பயன்பாடு அதிக உடல் நினைவகத்தை எடுக்கத் தொடங்கியவுடன், iOS அதை அழுக்கு பக்க சுருக்கத்திற்கு உட்படுத்துகிறது. அழுக்கு மற்றும் சுருக்கப்பட்ட பக்கங்களால் ஆக்கிரமிக்கப்பட்ட மொத்த நினைவகம் பயன்பாட்டின் நினைவக தடம் என அழைக்கப்படும். அது ஒரு குறிப்பிட்ட வரம்பு மதிப்பை அடைந்தவுடன், OOM கொலையாளி அமைப்பு டீமான் செயல்முறைக்குப் பிறகு வந்து அதை வலுக்கட்டாயமாக நிறுத்துகிறது. டெஸ்க்டாப் இயக்க முறைமைகளுடன் ஒப்பிடும்போது இது iOS இன் தனித்தன்மையாகும். மாறாக, இயற்பியல் நினைவகத்திலிருந்து வட்டுக்கு பக்கங்களை மாற்றுவதன் மூலம் நினைவக தடத்தை குறைப்பது iOS இல் வழங்கப்படவில்லை. காரணங்களை மட்டுமே யூகிக்க முடியும். பக்கங்களை வட்டுக்கும் பின்னோக்கியும் தீவிரமாக நகர்த்தும் செயல்முறை மொபைல் சாதனங்களுக்கு மிகவும் ஆற்றல் மிக்கதாக இருக்கலாம் அல்லது SSD டிரைவ்களில் செல்களை மீண்டும் எழுதும் ஆதாரத்தை iOS சேமிக்கிறது அல்லது வடிவமைப்பாளர்கள் கணினியின் ஒட்டுமொத்த செயல்திறனில் திருப்தி அடையாமல் இருக்கலாம். தொடர்ந்து மாற்றப்பட்டது. அது எப்படியிருந்தாலும், உண்மை ஒரு உண்மையாகவே உள்ளது.

ஏற்கனவே குறிப்பிட்டுள்ள நல்ல செய்தி என்னவென்றால், கோப்புகளைப் புதுப்பிக்க எல்எம்டிபி இயல்பாகவே mmap பொறிமுறையைப் பயன்படுத்தாது. இதன் பொருள் காட்டப்படும் தரவு iOS ஆல் சுத்தமான நினைவகம் என வகைப்படுத்தப்பட்டுள்ளது மற்றும் நினைவக தடயத்திற்கு பங்களிக்காது. VM Tracker எனப்படும் Xcode கருவியைப் பயன்படுத்தி இதைச் சரிபார்க்கலாம். செயல்பாட்டின் போது கிளவுட் பயன்பாட்டின் iOS மெய்நிகர் நினைவகத்தின் நிலையை கீழே உள்ள ஸ்கிரீன்ஷாட் காட்டுகிறது. தொடக்கத்தில், 2 LMDB நிகழ்வுகள் அதில் துவக்கப்பட்டன. முதலாவது அவரது கோப்பை 1GiB மெய்நிகர் நினைவகத்தில் காட்ட அனுமதிக்கப்பட்டது, இரண்டாவது - 512MiB. இரண்டு சேமிப்பகங்களும் ஒரு குறிப்பிட்ட அளவு குடியுரிமை நினைவகத்தை ஆக்கிரமித்துள்ளன என்ற உண்மை இருந்தபோதிலும், இரண்டும் அழுக்கு அளவை பங்களிக்கவில்லை.

இப்போது கெட்ட செய்திக்கான நேரம் வந்துவிட்டது. 64-பிட் டெஸ்க்டாப் இயக்க முறைமைகளில் உள்ள ஸ்வாப் பொறிமுறைக்கு நன்றி, ஒவ்வொரு செயல்முறையும் அதன் சாத்தியமான இடமாற்றத்திற்கான இலவச ஹார்ட் டிஸ்க் இடத்தை அனுமதிக்கும் அளவுக்கு மெய்நிகர் முகவரி இடத்தை ஆக்கிரமிக்க முடியும். IOS இல் ஸ்வாப்பை சுருக்கத்துடன் மாற்றுவது தத்துவார்த்த அதிகபட்சத்தை தீவிரமாக குறைக்கிறது. இப்போது அனைத்து வாழ்க்கை செயல்முறைகளும் முக்கிய (ரேம் படிக்க) நினைவகத்திற்கு பொருந்த வேண்டும், மேலும் பொருந்தாத அனைத்தும் நிறுத்தப்பட வேண்டும். இது மேலே குறிப்பிட்டுள்ளபடி கூறப்பட்டுள்ளது அறிக்கை, மற்றும் உள்ளே அதிகாரப்பூர்வ ஆவணங்கள். இதன் விளைவாக, iOS ஆனது mmap வழியாக ஒதுக்கப்படும் நினைவகத்தின் அளவைக் கடுமையாகக் கட்டுப்படுத்துகிறது. இங்கே இங்கே இந்த கணினி அழைப்பைப் பயன்படுத்தி வெவ்வேறு சாதனங்களில் ஒதுக்கக்கூடிய நினைவகத்தின் அளவின் அனுபவ வரம்புகளை நீங்கள் பார்க்கலாம். மிக நவீன ஸ்மார்ட்போன் மாடல்களில், iOS 2 ஜிகாபைட்களால் தாராளமாக மாறியுள்ளது, மேலும் ஐபாடின் மேல் பதிப்புகளில் - 4. நடைமுறையில், நிச்சயமாக, நீங்கள் மிகக் குறைந்த ஆதரவு சாதன மாதிரிகளில் கவனம் செலுத்த வேண்டும், அங்கு எல்லாம் மிகவும் வருத்தமாக இருக்கிறது. இன்னும் மோசமானது, VM டிராக்கரில் பயன்பாட்டின் நினைவக நிலையைப் பார்ப்பதன் மூலம், LMDB நினைவகம்-மேப் செய்யப்பட்டதாகக் கூறப்படுவதில் இருந்து வெகு தொலைவில் இருப்பதை நீங்கள் காண்பீர்கள். சிஸ்டம் அலோகேட்டர்கள், ரிசோர்ஸ் பைல்கள், இமேஜ் ஃப்ரேம்வொர்க்குகள் மற்றும் பிற சிறிய வேட்டையாடுபவர்களால் நல்ல துகள்கள் உண்ணப்படுகின்றன.

கிளவுட் சோதனைகளின் முடிவுகளின் அடிப்படையில், எல்எம்டிபியால் ஒதுக்கப்பட்ட நினைவகத்திற்கான பின்வரும் சமரச மதிப்புகளுக்கு வந்துள்ளோம்: 384-பிட் சாதனங்களுக்கு 32 மெகாபைட்கள் மற்றும் 768-பிட் சாதனங்களுக்கு 64. இந்த தொகுதி பயன்படுத்தப்பட்ட பிறகு, எந்த மாற்றும் செயல்பாடுகளும் குறியீட்டுடன் முடிவடையும் MDB_MAP_FULL. எங்கள் கண்காணிப்பில் இதுபோன்ற பிழைகளை நாங்கள் கவனிக்கிறோம், ஆனால் அவை சிறியதாக இருப்பதால், இந்த கட்டத்தில் அவை புறக்கணிக்கப்படலாம்.

சேமிப்பகத்தின் அதிகப்படியான நினைவக நுகர்வுக்கான வெளிப்படையான காரணம் நீண்டகால பரிவர்த்தனைகளாக இருக்கலாம். இந்த இரண்டு நிகழ்வுகளும் எவ்வாறு இணைக்கப்பட்டுள்ளன என்பதைப் புரிந்து கொள்ள, LMDB இன் மீதமுள்ள இரண்டு தூண்களைக் கருத்தில் கொண்டு நமக்கு உதவுவோம்.

3.2 திமிங்கிலம் #2. பி+-மரம்

விசை மதிப்பு சேமிப்பகத்தின் மேல் அட்டவணைகளைப் பின்பற்ற, பின்வரும் செயல்பாடுகள் அதன் API இல் இருக்க வேண்டும்:

1. புதிய உறுப்பைச் செருகுகிறது.
2. கொடுக்கப்பட்ட விசையுடன் ஒரு உறுப்பைத் தேடுங்கள்.
3. ஒரு உறுப்பு நீக்குதல்.
4. வரிசைப்படுத்தப்பட்ட வரிசையில் விசைகளின் இடைவெளியில் மீண்டும் செய்யவும்.

நான்கு செயல்பாடுகளையும் எளிதாக செயல்படுத்தக்கூடிய எளிய தரவு அமைப்பு பைனரி தேடல் மரமாகும். அதன் ஒவ்வொரு முனையும் குழந்தை விசைகளின் முழு துணைக்குழுவையும் இரண்டு துணை மரங்களாகப் பிரிக்கும் ஒரு விசையைக் குறிக்கிறது. இடதுபுறத்தில் பெற்றோரை விட சிறியவை உள்ளன, வலதுபுறத்தில் பெரியவை உள்ளன. வரிசைப்படுத்தப்பட்ட விசைகளின் தொகுப்பைப் பெறுவது உன்னதமான மரப் பயணங்களில் ஒன்றின் மூலம் அடையப்படுகிறது

பைனரி மரங்களில் இரண்டு அடிப்படை குறைபாடுகள் உள்ளன, அவை வட்டு அடிப்படையிலான தரவு கட்டமைப்பாக செயல்படுவதைத் தடுக்கின்றன. முதலாவதாக, அவற்றின் சமநிலையின் அளவு கணிக்க முடியாதது. மரங்களைப் பெறுவதில் கணிசமான ஆபத்து உள்ளது, அதில் வெவ்வேறு கிளைகளின் உயரம் பெரிதும் வேறுபடலாம், இது எதிர்பார்த்ததை விட தேடலின் வழிமுறை சிக்கலை கணிசமாக மோசமாக்குகிறது. இரண்டாவதாக, கணுக்களுக்கு இடையே உள்ள குறுக்கு இணைப்புகளின் மிகுதியானது பைனரி மரங்களின் நினைவகத்தில் உள்ள இடத்தை இழக்கிறது.மூடு முனைகள் (அவற்றுக்கு இடையேயான இணைப்புகளின் அடிப்படையில்) மெய்நிகர் நினைவகத்தில் முற்றிலும் வேறுபட்ட பக்கங்களில் அமைந்திருக்கும். இதன் விளைவாக, ஒரு மரத்தில் உள்ள பல அண்டை முனைகளின் ஒரு எளிய பயணம் கூட ஒப்பிடக்கூடிய எண்ணிக்கையிலான பக்கங்களைப் பார்வையிட வேண்டியிருக்கும். நினைவகத்தில் உள்ள தரவு கட்டமைப்பாக பைனரி மரங்களின் செயல்திறனைப் பற்றி நாம் பேசும்போது கூட இது ஒரு பிரச்சனையாகும், ஏனெனில் செயலி தற்காலிக சேமிப்பில் பக்கங்களை தொடர்ந்து சுழற்றுவது மலிவான மகிழ்ச்சி அல்ல. வட்டில் இருந்து முனைகளுடன் தொடர்புடைய பக்கங்களை அடிக்கடி மீட்டெடுக்கும் போது, ​​நிலைமை முற்றிலும் மாறும் வருந்தத்தக்கது.

B-மரங்கள், பைனரி மரங்களின் பரிணாம வளர்ச்சியாக இருப்பதால், முந்தைய பத்தியில் அடையாளம் காணப்பட்ட சிக்கல்களைத் தீர்க்கிறது. முதலாவதாக, அவர்கள் சுய சமநிலையில் உள்ளனர். இரண்டாவதாக, அவற்றின் ஒவ்வொரு முனைகளும் குழந்தை விசைகளின் தொகுப்பை 2 ஆகப் பிரிக்காமல், M வரிசைப்படுத்தப்பட்ட துணைக்குழுக்களாகப் பிரிக்கின்றன, மேலும் M எண் பல நூறு அல்லது ஆயிரக்கணக்கான வரிசையில் மிகப் பெரியதாக இருக்கலாம்.

அதன் மூலம்:

1. ஒவ்வொரு முனையிலும் ஏற்கனவே ஆர்டர் செய்யப்பட்ட விசைகள் அதிக எண்ணிக்கையில் உள்ளன மற்றும் மரங்கள் மிகவும் குறுகியதாக இருக்கும்.
2. மரம் நினைவகத்தில் இருப்பிடத்தின் இருப்பிடத்தின் சொத்தைப் பெறுகிறது, ஏனெனில் மதிப்புக்கு நெருக்கமான விசைகள் இயற்கையாகவே ஒரே அல்லது அண்டை முனைகளில் ஒருவருக்கொருவர் அடுத்ததாக அமைந்துள்ளன.
3. தேடுதல் நடவடிக்கையின் போது மரத்திலிருந்து இறங்கும் போது போக்குவரத்து முனைகளின் எண்ணிக்கை குறைக்கப்படுகிறது.
4. வரம்பு வினவல்களின் போது படிக்கப்பட்ட இலக்கு முனைகளின் எண்ணிக்கை குறைக்கப்படுகிறது, ஏனெனில் அவை ஒவ்வொன்றும் ஏற்கனவே அதிக எண்ணிக்கையிலான ஆர்டர் விசைகளைக் கொண்டுள்ளன.

தரவைச் சேமிக்க, B+ மரம் எனப்படும் B-மரத்தின் மாறுபாட்டை LMDB பயன்படுத்துகிறது. மேலே உள்ள வரைபடம் அதில் இருக்கும் மூன்று வகையான முனைகளைக் காட்டுகிறது:

1. மேலே வேர் உள்ளது. இது ஒரு கிடங்கிற்குள் ஒரு தரவுத்தளத்தின் கருத்தைத் தவிர வேறொன்றுமில்லை. ஒரு LMDB நிகழ்விற்குள், வரைபடப்படுத்தப்பட்ட மெய்நிகர் முகவரி இடத்தைப் பகிர்ந்து கொள்ளும் பல தரவுத்தளங்களை நீங்கள் உருவாக்கலாம். அவை ஒவ்வொன்றும் அதன் சொந்த மூலத்திலிருந்து தொடங்குகிறது.
2. குறைந்த மட்டத்தில் இலைகள் உள்ளன. அவை மற்றும் அவை மட்டுமே தரவுத்தளத்தில் சேமிக்கப்பட்ட முக்கிய மதிப்பு ஜோடிகளைக் கொண்டிருக்கின்றன. மூலம், இது B+-மரங்களின் தனித்தன்மை. ஒரு வழக்கமான B-மரம் மதிப்பு பகுதிகளை அனைத்து நிலைகளின் முனைகளிலும் சேமித்து வைத்தால், B+ மாறுபாடு மிகக் குறைந்த அளவில் மட்டுமே இருக்கும். இந்த உண்மையை சரிசெய்த பிறகு, எல்எம்டிபியில் பயன்படுத்தப்படும் மரத்தின் துணை வகையை பி-ட்ரீ என்று அழைப்போம்.
3. வேர் மற்றும் இலைகளுக்கு இடையில் வழிசெலுத்தல் (கிளை) முனைகளுடன் 0 அல்லது அதற்கு மேற்பட்ட தொழில்நுட்ப நிலைகள் உள்ளன. வரிசைப்படுத்தப்பட்ட விசைகளை இலைகளுக்கு இடையில் பிரிப்பதே அவர்களின் பணி.

உடல் ரீதியாக, கணுக்கள் முன்னரே தீர்மானிக்கப்பட்ட நீளத்தின் நினைவக தொகுதிகள். அவற்றின் அளவு இயக்க முறைமையில் உள்ள நினைவக பக்கங்களின் அளவின் பல மடங்கு ஆகும், நாங்கள் மேலே விவாதித்தோம். முனை அமைப்பு கீழே காட்டப்பட்டுள்ளது. தலைப்பில் மெட்டா தகவல் உள்ளது, இதில் மிகவும் வெளிப்படையானது எடுத்துக்காட்டாக செக்சம் ஆகும். அடுத்து தரவுகளுடன் கூடிய செல்கள் அமைந்துள்ள ஆஃப்செட்கள் பற்றிய தகவல் வரும். வழிசெலுத்தல் முனைகளைப் பற்றி பேசினால் தரவு விசைகளாக இருக்கலாம் அல்லது இலைகளின் விஷயத்தில் முழு விசை-மதிப்பு ஜோடிகளாக இருக்கலாம். வேலையில் உள்ள பக்கங்களின் கட்டமைப்பைப் பற்றி நீங்கள் மேலும் படிக்கலாம். "உயர் செயல்திறன் முக்கிய மதிப்பு கடைகளின் மதிப்பீடு".

பக்க முனைகளின் உள் உள்ளடக்கத்தைக் கையாள்வதன் மூலம், பின்வரும் படிவத்தில் எளிமையான முறையில் LMDB B-மரத்தைப் பிரதிநிதித்துவப்படுத்துவோம்.

முனைகள் கொண்ட பக்கங்கள் வட்டில் வரிசையாக அமைந்துள்ளன. அதிக எண்ணிக்கையிலான பக்கங்கள் கோப்பின் முடிவில் அமைந்துள்ளன. மெட்டா பக்கம் என்று அழைக்கப்படுபவை அனைத்து மரங்களின் வேர்களையும் காணக்கூடிய ஆஃப்செட் பற்றிய தகவல்களைக் கொண்டுள்ளது. ஒரு கோப்பைத் திறக்கும் போது, ​​LMDB, சரியான மெட்டா பக்கத்தைத் தேடி, கடைசியில் இருந்து ஆரம்பம் வரை கோப்பை ஸ்கேன் செய்து, அதன் மூலம் ஏற்கனவே உள்ள தரவுத்தளங்களைக் கண்டறியும்.

இப்போது, ​​தரவு அமைப்பின் தர்க்கரீதியான மற்றும் இயற்பியல் கட்டமைப்பைப் பற்றிய ஒரு யோசனை இருந்தால், நாம் LMDB இன் மூன்றாவது தூணைக் கருத்தில் கொள்ளலாம். அதன் உதவியுடன்தான் அனைத்து சேமிப்பக மாற்றங்களும் பரிவர்த்தனை மற்றும் ஒருவருக்கொருவர் தனிமைப்படுத்தப்படுகின்றன, இது தரவுத்தளத்தை ஒட்டுமொத்தமாக மல்டிவர்ஷனின் சொத்தை அளிக்கிறது.

3.3 திமிங்கிலம் #3. நகல்-ஆன்-ரைட்

சில பி-ட்ரீ செயல்பாடுகள் அதன் முனைகளில் தொடர்ச்சியான மாற்றங்களைச் செய்வதை உள்ளடக்கியது. ஒரு உதாரணம், ஏற்கனவே அதன் அதிகபட்ச திறனை எட்டிய ஒரு முனையில் புதிய விசையைச் சேர்ப்பது. இந்த வழக்கில், முதலில், முனையை இரண்டாகப் பிரிப்பது அவசியம், இரண்டாவதாக, அதன் பெற்றோரில் புதிய வளரும் குழந்தை முனைக்கு இணைப்பைச் சேர்ப்பது அவசியம். இந்த செயல்முறை மிகவும் ஆபத்தானது. சில காரணங்களால் (விபத்து, மின் தடை, முதலியன) தொடரில் இருந்து ஒரு பகுதி மட்டுமே மாற்றங்கள் ஏற்பட்டால், மரம் ஒரு சீரற்ற நிலையில் இருக்கும்.

ஒரு தரவுத்தள பிழை-சகிப்புத்தன்மையை உருவாக்குவதற்கான ஒரு பாரம்பரிய தீர்வு, B-tree-க்கு அடுத்ததாக கூடுதல் ஆன்-டிஸ்க் தரவு கட்டமைப்பைச் சேர்ப்பதாகும் - இது ஒரு பரிவர்த்தனை பதிவு, இது எழுதும் பதிவு (WAL) என்றும் அழைக்கப்படுகிறது. இது ஒரு கோப்பாகும், அதன் முடிவில் பி-ட்ரீயையே மாற்றியமைக்கும் முன் நோக்கம் கொண்ட செயல்பாடு கண்டிப்பாக எழுதப்படும். எனவே, சுய-கண்டறிதலின் போது தரவு சிதைவு கண்டறியப்பட்டால், தரவுத்தளம் தன்னை ஒழுங்கமைக்க பதிவை ஆலோசிக்கிறது.

எல்எம்டிபி, நகல்-ஆன்-ரைட் எனப்படும் தவறு சகிப்புத்தன்மை பொறிமுறையாக வேறுபட்ட முறையைத் தேர்ந்தெடுத்துள்ளது. அதன் சாராம்சம் என்னவென்றால், ஏற்கனவே உள்ள பக்கத்தில் தரவைப் புதுப்பிப்பதற்குப் பதிலாக, முதலில் அதை முழுவதுமாக நகலெடுத்து, நகலில் அனைத்து மாற்றங்களையும் செய்கிறது.

அடுத்து, புதுப்பிக்கப்பட்ட தரவு கிடைக்க, அதன் பெற்றோர் முனையில் தற்போதையதாக மாறிய முனைக்கான இணைப்பை மாற்றுவது அவசியம். இதுவும் இதற்கு மாற்றியமைக்கப்பட வேண்டும் என்பதால், அதுவும் முன்பே நகலெடுக்கப்படுகிறது. செயல்முறை ரூட் வரை மீண்டும் மீண்டும் தொடர்கிறது. கடைசியாக மாற்ற வேண்டியது மெட்டா பக்கத்தில் உள்ள தரவு.

புதுப்பிப்பு செயல்முறையின் போது திடீரென்று செயல்முறை செயலிழந்தால், ஒரு புதிய மெட்டா பக்கம் உருவாக்கப்படாது, அல்லது வட்டில் முழுமையாக எழுதப்படாது, மேலும் அதன் செக்சம் தவறாக இருக்கும். இந்த இரண்டு நிகழ்வுகளிலும், புதிய பக்கங்களை அணுக முடியாது, ஆனால் பழையவை பாதிக்கப்படாது. இது தரவு நிலைத்தன்மையை பராமரிக்க LMDBக்கு முன்னரே பதிவை எழுத வேண்டிய தேவையை நீக்குகிறது. நடைமுறையில், மேலே விவரிக்கப்பட்ட வட்டில் உள்ள தரவு சேமிப்பகத்தின் அமைப்பு அதன் செயல்பாட்டை ஒரே நேரத்தில் எடுக்கும். வெளிப்படையான பரிவர்த்தனை பதிவு இல்லாதது அதிக தரவு வாசிப்பு வேகத்தை வழங்கும் LMDB இன் அம்சங்களில் ஒன்றாகும்.

இதன் விளைவாக வரும் வடிவமைப்பு, append-only B-tree எனப்படும், இயற்கையாகவே பரிவர்த்தனை தனிமைப்படுத்தல் மற்றும் பல பதிப்புகளை வழங்குகிறது. LMDB இல், ஒவ்வொரு திறந்த பரிவர்த்தனையும் தற்போது தொடர்புடைய மர வேருடன் தொடர்புடையது. பரிவர்த்தனை முடியும் வரை, அதனுடன் தொடர்புடைய மரத்தின் பக்கங்கள் ஒருபோதும் மாற்றப்படாது அல்லது தரவுகளின் புதிய பதிப்புகளுக்கு மீண்டும் பயன்படுத்தப்படாது. எனவே, அந்த நேரத்தில் தொடர்புடைய தரவுகளின் தொகுப்புடன் நீங்கள் விரும்பும் வரை வேலை செய்யலாம். இந்த நேரத்தில் சேமிப்பகம் தொடர்ந்து புதுப்பிக்கப்பட்டாலும், பரிவர்த்தனை திறக்கப்பட்டது. இது மல்டிவெர்ஷனின் சாராம்சம், இது எல்எம்டிபியை எங்கள் அன்பானவர்களுக்கான சிறந்த தரவு ஆதாரமாக மாற்றுகிறது UICollectionView. ஒரு பரிவர்த்தனையைத் திறந்த பிறகு, எதுவும் இல்லாமல் போய்விடுமோ என்ற பயத்தில், தற்போதைய தரவை சில நினைவக அமைப்பில் அவசரமாக வெளியேற்றுவதன் மூலம் பயன்பாட்டின் நினைவக தடத்தை அதிகரிக்க வேண்டிய அவசியமில்லை. இந்த அம்சம் LMDB ஐ அதே SQLite இலிருந்து வேறுபடுத்துகிறது. பிந்தையவற்றில் இரண்டு பரிவர்த்தனைகளைத் திறந்து, அவற்றில் ஒன்றில் குறிப்பிட்ட பதிவை நீக்கிவிட்டால், மீதமுள்ள இரண்டாவது பதிவிற்குள் அதே பதிவைப் பெற முடியாது.

நாணயத்தின் மறுபக்கம் மெய்நிகர் நினைவகத்தின் குறிப்பிடத்தக்க அளவு அதிக நுகர்வு ஆகும். தரவுத்தளத்தின் வெவ்வேறு பதிப்புகளைப் பார்த்து 3 திறந்த வாசிப்பு பரிவர்த்தனைகளுடன் ஒரே நேரத்தில் மாற்றியமைக்கப்பட்டால் தரவுத்தள அமைப்பு எப்படி இருக்கும் என்பதை ஸ்லைடு காட்டுகிறது. தற்போதைய பரிவர்த்தனைகளுடன் தொடர்புடைய ரூட்களில் இருந்து அணுகக்கூடிய முனைகளை LMDB மீண்டும் பயன்படுத்த முடியாது என்பதால், நினைவகத்தில் மற்றொரு நான்காவது மூலத்தை ஒதுக்கி அதன் கீழ் மாற்றியமைக்கப்பட்ட பக்கங்களை மீண்டும் குளோன் செய்வதைத் தவிர கடைக்கு வேறு வழியில்லை.

நினைவக-மேப் செய்யப்பட்ட கோப்புகளின் பகுதியை இங்கே நினைவுபடுத்துவது பயனுள்ளதாக இருக்கும். மெய்நிகர் நினைவகத்தின் கூடுதல் நுகர்வு நம்மை அதிகம் கவலைப்பட வேண்டியதில்லை, ஏனெனில் இது பயன்பாட்டின் நினைவக தடயத்திற்கு பங்களிக்காது. இருப்பினும், அதே நேரத்தில், iOS அதை ஒதுக்குவதில் மிகவும் கஞ்சத்தனமாக உள்ளது, மேலும் ஒரு சர்வர் அல்லது டெஸ்க்டாப்பில், 1 டெராபைட் LMDB பகுதியை வழங்க முடியாது, மேலும் இந்த அம்சத்தைப் பற்றி சிந்திக்கவே இல்லை. முடிந்தால், பரிவர்த்தனைகளின் வாழ்நாளை முடிந்தவரை குறுகியதாக மாற்ற முயற்சிக்கவும்.

4. விசை மதிப்பு APIக்கு மேல் தரவுத் திட்டத்தை வடிவமைத்தல்

எல்எம்டிபி வழங்கிய அடிப்படை சுருக்கங்களைப் பார்த்து எங்கள் ஏபிஐ பகுப்பாய்வைத் தொடங்குவோம்: சூழல் மற்றும் தரவுத்தளங்கள், விசைகள் மற்றும் மதிப்புகள், பரிவர்த்தனைகள் மற்றும் கர்சர்கள்.

குறியீடு பட்டியல்கள் பற்றிய குறிப்பு

பொது எல்எம்டிபி ஏபிஐயில் உள்ள அனைத்து செயல்பாடுகளும் அவற்றின் வேலையின் முடிவை பிழைக் குறியீட்டின் வடிவில் வழங்கும், ஆனால் அனைத்து அடுத்தடுத்த பட்டியல்களிலும் அதன் சரிபார்ப்பு சுருக்கத்திற்காக தவிர்க்கப்பட்டது. நடைமுறையில், களஞ்சியத்துடன் தொடர்புகொள்வதற்கு நாங்கள் எங்கள் சொந்தத்தைப் பயன்படுத்தினோம். முள் கரண்டி சி++ ரேப்பர்கள் 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 கிளவுட் பயன்பாட்டில், இரண்டு அளவுருக்களின் இயல்புநிலை மதிப்புகளை மட்டுமே மாற்றியுள்ளோம்.

முதலாவது, சேமிப்பகக் கோப்பு மேப் செய்யப்பட்ட மெய்நிகர் முகவரி இடத்தின் அளவு. துரதிருஷ்டவசமாக, அதே சாதனத்தில் கூட, குறிப்பிட்ட மதிப்பு இயக்கத்திலிருந்து இயக்கத்திற்கு கணிசமாக மாறுபடும். IOS இன் இந்த அம்சத்தை கணக்கில் எடுத்துக்கொள்ள, அதிகபட்ச சேமிப்பக அளவு மாறும் வகையில் தேர்ந்தெடுக்கப்பட்டது. ஒரு குறிப்பிட்ட மதிப்பிலிருந்து தொடங்கி, செயல்பாடு வரை தொடர்ச்சியாக பாதியாகக் குறைக்கப்படுகிறது mdb_env_open இதிலிருந்து வேறுபட்ட முடிவைத் தராது ENOMEM. கோட்பாட்டில், எதிர் வழியும் உள்ளது - முதலில் இயந்திரத்திற்கு குறைந்தபட்ச நினைவகத்தை ஒதுக்கவும், பின்னர், பிழைகள் வரும்போது, MDB_MAP_FULL, அதை அதிகரிக்கவும். இருப்பினும், இது மிகவும் முட்கள் நிறைந்தது. காரணம், செயல்பாட்டைப் பயன்படுத்தி நினைவகத்தை (ரீமேப்) மறு ஒதுக்கீடு செய்வதற்கான செயல்முறை mdb_env_set_map_size எஞ்சினிலிருந்து முன்னர் பெறப்பட்ட அனைத்து நிறுவனங்களையும் (கர்சர்கள், பரிவர்த்தனைகள், விசைகள் மற்றும் மதிப்புகள்) செல்லாததாக்குகிறது. குறியீட்டில் இந்த நிகழ்வுகளின் திருப்பத்தை கணக்கில் எடுத்துக்கொள்வது அதன் குறிப்பிடத்தக்க சிக்கலுக்கு வழிவகுக்கும். எவ்வாறாயினும், மெய்நிகர் நினைவகம் உங்களுக்கு மிகவும் முக்கியமானது என்றால், முன்னோக்கிச் சென்ற முட்கரண்டியை உன்னிப்பாகப் பார்க்க இது ஒரு காரணமாக இருக்கலாம். MDBX, அறிவிக்கப்பட்ட அம்சங்களில் "தானாகவே பறக்கும் தரவுத்தள அளவு சரிசெய்தல்" உள்ளது.

இரண்டாவது அளவுரு, இயல்புநிலை மதிப்பு நமக்கு பொருந்தவில்லை, நூல் பாதுகாப்பை உறுதி செய்யும் இயக்கவியலை ஒழுங்குபடுத்துகிறது. துரதிர்ஷ்டவசமாக, குறைந்தது iOS 10 இல் நூல் உள்ளூர் சேமிப்பகத்திற்கான ஆதரவில் சிக்கல்கள் உள்ளன. இந்த காரணத்திற்காக, மேலே உள்ள எடுத்துக்காட்டில், களஞ்சியம் கொடியுடன் திறக்கப்படுகிறது MDB_NOTLS. இது தவிர, இது அவசியமாகவும் இருந்தது முள் கரண்டி சி++ ரேப்பர் lmdbxxஇந்த பண்பு மற்றும் அதில் உள்ள மாறிகளை வெட்டுவதற்கு.

தரவுத்தளங்கள்

தரவுத்தளமானது ஒரு தனி பி-ட்ரீ நிகழ்வாகும், நாங்கள் மேலே விவாதித்தோம். அதன் திறப்பு ஒரு பரிவர்த்தனைக்குள் நிகழ்கிறது, இது முதலில் கொஞ்சம் விசித்திரமாகத் தோன்றலாம்.

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

உண்மையில், எல்எம்டிபியில் ஒரு பரிவர்த்தனை என்பது ஒரு சேமிப்பக நிறுவனம், ஒரு குறிப்பிட்ட தரவுத்தள நிறுவனம் அல்ல. வெவ்வேறு தரவுத்தளங்களில் அமைந்துள்ள நிறுவனங்களில் அணு செயல்பாடுகளைச் செய்ய இந்த கருத்து உங்களை அனுமதிக்கிறது. கோட்பாட்டில், இது வெவ்வேறு தரவுத்தளங்களின் வடிவத்தில் அட்டவணைகளை மாடலிங் செய்வதற்கான வாய்ப்பைத் திறக்கிறது, ஆனால் ஒரு நேரத்தில் நான் வேறு பாதையை எடுத்தேன், கீழே விரிவாக விவரிக்கப்பட்டுள்ளது.

விசைகள் மற்றும் மதிப்புகள்

அமைப்பு MDB_val முக்கிய மற்றும் மதிப்பு ஆகிய இரண்டின் கருத்தையும் மாதிரியாகக் காட்டுகிறது. களஞ்சியத்திற்கு அவற்றின் சொற்பொருள் பற்றி எதுவும் தெரியாது. அவளுக்கு, வேறு ஏதோ கொடுக்கப்பட்ட அளவு பைட்டுகளின் வரிசை. அதிகபட்ச விசை அளவு 512 பைட்டுகள்.

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

ஒப்பீட்டாளரைப் பயன்படுத்தி, கடை விசைகளை ஏறுவரிசையில் வரிசைப்படுத்துகிறது. நீங்கள் அதை உங்கள் சொந்தமாக மாற்றவில்லை என்றால், இயல்புநிலை ஒன்று பயன்படுத்தப்படும், இது அவற்றை பைட் பைட் லெக்சிகோகிராஃபிக் வரிசையில் வரிசைப்படுத்தும்.

பரிவர்த்தனைகள்

பரிவர்த்தனை அமைப்பு விரிவாக விவரிக்கப்பட்டுள்ளது முந்தைய அத்தியாயம், எனவே இங்கே நான் அவற்றின் முக்கிய பண்புகளை சுருக்கமாக மீண்டும் சொல்கிறேன்:

1. அனைத்து அடிப்படை பண்புகளையும் ஆதரிக்கிறது ACID: அணு, நிலைத்தன்மை, தனிமைப்படுத்தல் மற்றும் நம்பகத்தன்மை. MDBX இல் சரி செய்யப்பட்ட macOS மற்றும் iOS இல் நீடித்துழைப்பு அடிப்படையில் பிழை இருப்பதை என்னால் கவனிக்க முடியவில்லை. அவற்றில் நீங்கள் மேலும் படிக்கலாம் என்னை தெரிந்து கொள்.
2. மல்டித்ரெடிங்கிற்கான அணுகுமுறை "ஒற்றை எழுத்தாளர் / பல வாசகர்கள்" திட்டத்தால் விவரிக்கப்படுகிறது. எழுத்தாளர்கள் ஒருவரையொருவர் தடுக்கிறார்கள், ஆனால் வாசகர்களைத் தடுக்காதீர்கள். வாசகர்கள் எழுத்தாளர்களையோ ஒருவரையொருவர் தடுப்பதில்லை.
3. உள்ளமை பரிவர்த்தனைகளுக்கான ஆதரவு.
4. பல்வகை ஆதரவு.

எல்எம்டிபியில் மல்டிவர்ஷன் மிகவும் நன்றாக உள்ளது, அதை நான் செயலில் நிரூபிக்க விரும்புகிறேன். ஒவ்வொரு பரிவர்த்தனையும் திறக்கப்பட்ட நேரத்தில் தற்போதைய தரவுத்தளத்தின் பதிப்புடன் செயல்படுவதைக் கீழே உள்ள குறியீட்டிலிருந்து நீங்கள் காணலாம், அது அனைத்து அடுத்தடுத்த மாற்றங்களிலிருந்தும் முற்றிலும் தனிமைப்படுத்தப்பட்டது. சேமிப்பகத்தைத் தொடங்குதல் மற்றும் அதில் ஒரு சோதனைப் பதிவைச் சேர்ப்பது சுவாரஸ்யமான எதையும் குறிக்காது, எனவே இந்த சடங்குகள் ஸ்பாய்லரின் கீழ் விடப்படுகின்றன.

சோதனை உள்ளீட்டைச் சேர்த்தல்

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 மாற்றங்களுடன் தொடர்புடைய செலவுகளையும் பெறுகிறோம். தற்காலிக அட்டவணையைப் பொறுத்தவரை, இது இன்னும் விலையுயர்ந்த இன்பம், இது அற்பமான நிகழ்வுகளில் மட்டுமே அர்த்தமுள்ளதாக இருக்கிறது.

எல்எம்டிபியின் மல்டிவர்ஷன் தீர்வு, நிலையான தரவு மூலத்தைப் பராமரிப்பதில் உள்ள சிக்கலை மிக நேர்த்தியான முறையில் தீர்க்கிறது. ஒரு பரிவர்த்தனை மற்றும் வோய்லாவைத் திறந்தால் போதும் - நாங்கள் அதை முடிக்கும் வரை, தரவுத் தொகுப்பு சரி செய்யப்படும். அதன் புதுப்பிப்பு வேகத்திற்கான தர்க்கம் இப்போது முழுவதுமாக விளக்கக்காட்சி அடுக்கின் கைகளில் உள்ளது, குறிப்பிடத்தக்க ஆதாரங்கள் எதுவும் இல்லை.

கர்சர்கள்

B-tree traversal மூலம் விசை மதிப்பு ஜோடிகளின் மீது ஒழுங்காக மறுசெலுத்துவதற்கான ஒரு பொறிமுறையை கர்சர்கள் வழங்குகின்றன. அவை இல்லாமல், தரவுத்தளத்தில் உள்ள அட்டவணைகளை திறம்பட மாதிரியாக்குவது சாத்தியமில்லை, அதை நாம் இப்போது பார்க்கிறோம்.

4.2 டேபிள் மாடலிங்

முக்கிய வரிசைப்படுத்தலின் சொத்து, அடிப்படை சுருக்கங்களின் மேல் ஒரு அட்டவணை போன்ற உயர்-நிலை சுருக்கத்தை உருவாக்க உங்களை அனுமதிக்கிறது. கிளவுட் கிளையண்டின் பிரதான அட்டவணையின் எடுத்துக்காட்டைப் பயன்படுத்தி இந்த செயல்முறையை பரிசீலிப்போம், இது பயனரின் அனைத்து கோப்புகள் மற்றும் கோப்புறைகள் பற்றிய தகவலை தற்காலிகமாக சேமிக்கிறது.

அட்டவணை திட்டம்

ஒரு கோப்புறை மரத்துடன் கூடிய அட்டவணை அமைப்பு வடிவமைக்கப்பட வேண்டிய பொதுவான காட்சிகளில் ஒன்று, கொடுக்கப்பட்ட கோப்பகத்தில் உள்ள அனைத்து உறுப்புகளின் தேர்வு ஆகும். இந்த வகையான திறமையான வினவல்களுக்கு ஒரு நல்ல தரவு அமைப்பு மாதிரி அருகிலுள்ள பட்டியல். முக்கிய மதிப்பு சேமிப்பகத்தின் மேல் அதை செயல்படுத்த, கோப்புகள் மற்றும் கோப்புறைகளின் விசைகளை பெற்றோர் கோப்பகத்தில் உள்ள உறுப்பினர்களின் அடிப்படையில் குழுவாக்குவது அவசியம். கூடுதலாக, கோப்பகத்தின் உள்ளடக்கங்களை விண்டோஸ் பயனருக்குத் தெரிந்த வடிவத்தில் காட்ட (முதலில் கோப்புறைகள், பின்னர் கோப்புகள், இரண்டும் அகரவரிசைப்படி வரிசைப்படுத்தப்பட்டவை), விசையில் தொடர்புடைய கூடுதல் புலங்களைச் சேர்க்க வேண்டியது அவசியம்.

கீழே உள்ள படம், கையில் உள்ள பணியின் அடிப்படையில், பைட் வரிசையின் வடிவத்தில் விசைகளின் பிரதிநிதித்துவம் எப்படி இருக்கும் என்பதைக் காட்டுகிறது. முதன்மை கோப்பகத்தின் (சிவப்பு) அடையாளங்காட்டியுடன் பைட்டுகள் முதலில் வைக்கப்படும், பின்னர் வகை (பச்சை) மற்றும் பெயருடன் (நீலம்) வால் பகுதியில் வைக்கப்படும். இயல்புநிலை 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 விஷயத்தில் அவை எவ்வாறு முற்றிலும் தவிர்க்கப்படலாம் என்பதைக் காட்டுகிறது. சேவையகத்திலிருந்து உள்வரும் பைட் வரிசை முதலில் ஸ்டாக் கட்டமைப்புகளாக மாற்றப்படுகிறது, பின்னர் அவை அற்பமாக சேமிப்பகத்தில் கொட்டப்படுகின்றன. எல்எம்டிபிக்குள் டைனமிக் ஒதுக்கீடுகள் எதுவும் இல்லை என்பதைக் கருத்தில் கொண்டு, 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. படிக்க மட்டுமேயான பரிவர்த்தனைக்கு, பரிவர்த்தனை மூடப்படும் வரை மட்டுமே மதிப்பு கட்டமைப்பிற்கான சுட்டிக்காட்டி செல்லுபடியாகும் என்று உத்தரவாதம் அளிக்கப்படுகிறது. முன்னர் குறிப்பிட்டது போல், ஒரு பொருள் அமைந்துள்ள B-tree பக்கங்கள், நகல்-ஆன்-ரைட் கொள்கைக்கு நன்றி, அவை குறைந்தபட்சம் ஒரு பரிவர்த்தனை மூலம் குறிப்பிடப்படும் வரை மாறாமல் இருக்கும். அதே நேரத்தில், அவற்றுடன் தொடர்புடைய கடைசி பரிவர்த்தனை முடிந்தவுடன், புதிய தரவுகளுக்கு பக்கங்களை மீண்டும் பயன்படுத்தலாம். பொருள்கள் அவற்றை உருவாக்கிய பரிவர்த்தனையைத் தக்கவைக்க வேண்டியது அவசியம் என்றால், அவை இன்னும் நகலெடுக்கப்பட வேண்டும்.
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). ARM இல் நீங்கள் அதே விளைவைக் கொண்டிருக்கலாம் அடைய மற்றும் பேக் செய்யப்பட்ட பண்புக்கூறைப் பயன்படுத்துதல். கட்டமைப்பால் ஆக்கிரமிக்கப்பட்ட இடத்தை மேம்படுத்தவும் இது உதவுகிறது என்பதைக் கருத்தில் கொண்டு, இந்த முறை எனக்கு விரும்பத்தக்கதாகத் தோன்றுகிறது. приводит தரவு அணுகல் செயல்பாடுகளின் விலையில் அதிகரிப்பு.

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

வரம்பு வினவல்கள்

ஒரு குழு பதிவுகளை மீண்டும் செய்ய, LMDB ஒரு கர்சர் சுருக்கத்தை வழங்குகிறது. ஏற்கனவே நமக்குத் தெரிந்த பயனர் கிளவுட் மெட்டாடேட்டாவைக் கொண்ட அட்டவணையின் உதாரணத்தைப் பயன்படுத்தி அதனுடன் எவ்வாறு செயல்படுவது என்பதைப் பார்ப்போம்.

ஒரு கோப்பகத்தில் கோப்புகளின் பட்டியலைக் காண்பிப்பதன் ஒரு பகுதியாக, அதன் குழந்தை கோப்புகள் மற்றும் கோப்புறைகள் தொடர்புடைய அனைத்து விசைகளையும் கண்டறிவது அவசியம். முந்தைய துணைப்பிரிவுகளில் விசைகளை வரிசைப்படுத்தினோம் NodeKey அவை முதன்மையாக பெற்றோர் கோப்பகத்தின் ஐடியால் ஆர்டர் செய்யப்படுகின்றன. எனவே, தொழில்நுட்ப ரீதியாக, ஒரு கோப்புறையின் உள்ளடக்கங்களை மீட்டெடுக்கும் பணியானது, கொடுக்கப்பட்ட முன்னொட்டுடன் கூடிய விசைகளின் குழுவின் மேல் எல்லையில் கர்சரை வைத்து பின்னர் கீழ் எல்லைக்கு திரும்பும்.

தொடர்ச்சியான தேடலின் மூலம் மேல் எல்லையை நேரடியாகக் காணலாம். இதைச் செய்ய, தரவுத்தளத்தில் உள்ள விசைகளின் முழுப் பட்டியலின் தொடக்கத்தில் கர்சர் வைக்கப்பட்டு, அதன் கீழே பெற்றோர் கோப்பகத்தின் அடையாளங்காட்டியுடன் கூடிய விசை தோன்றும் வரை மேலும் அதிகரிக்கப்படும். இந்த அணுகுமுறை 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 ஐப் பயன்படுத்தி மறு செய்கையின் ஒரு பகுதியாக, விசையை மட்டுமல்ல, மதிப்பையும் பெறுகிறோம். மாதிரி நிபந்தனைகளை நிறைவேற்ற, நீங்கள் மற்றவற்றுடன், பதிவின் மதிப்புப் பகுதியிலிருந்து புலங்களைச் சரிபார்க்க வேண்டும் என்றால், கூடுதல் சைகைகள் இல்லாமல் அவை மிகவும் அணுகக்கூடியவை.

4.3. அட்டவணைகளுக்கு இடையிலான மாடலிங் உறவுகள்

இப்போது, ​​ஒற்றை அட்டவணை தரவுத்தளத்தை வடிவமைத்தல் மற்றும் வேலை செய்வதற்கான அனைத்து அம்சங்களையும் நாங்கள் பரிசீலிக்க முடிந்தது. ஒரே மாதிரியான விசை-மதிப்பு ஜோடிகளைக் கொண்ட வரிசைப்படுத்தப்பட்ட பதிவுகளின் தொகுப்பே அட்டவணை என்று நாம் கூறலாம். நீங்கள் ஒரு விசையை செவ்வகமாகவும், அதனுடன் தொடர்புடைய மதிப்பை இணையாகக் காட்டினால், தரவுத்தளத்தின் காட்சி வரைபடத்தைப் பெறுவீர்கள்.

​

இருப்பினும், நிஜ வாழ்க்கையில் மிகக் குறைந்த இரத்தம் சிந்துவது அரிதாகவே சாத்தியமாகும். பெரும்பாலும் ஒரு தரவுத்தளத்தில், முதலில், பல அட்டவணைகள் இருக்க வேண்டும், இரண்டாவதாக, முதன்மை விசையிலிருந்து வேறுபட்ட வரிசையில் அவற்றில் தேர்வுகளை செய்ய வேண்டும். இந்த கடைசி பகுதி அவற்றின் உருவாக்கம் மற்றும் ஒன்றோடொன்று இணைந்த சிக்கல்களுக்கு அர்ப்பணிக்கப்பட்டுள்ளது.

குறியீட்டு அட்டவணைகள்

கிளவுட் பயன்பாட்டில் "கேலரி" பிரிவு உள்ளது. இது முழு மேகக்கணியிலிருந்தும் மீடியா உள்ளடக்கத்தை தேதியின்படி வரிசைப்படுத்துகிறது. அத்தகைய தேர்வை சிறந்த முறையில் செயல்படுத்த, பிரதான அட்டவணைக்கு அடுத்ததாக நீங்கள் புதிய வகை விசைகளுடன் இன்னொன்றை உருவாக்க வேண்டும். அவை கோப்பு உருவாக்கப்பட்ட தேதியுடன் ஒரு புலத்தைக் கொண்டிருக்கும், இது முதன்மை வரிசைப்படுத்தும் அளவுகோலாக செயல்படும். புதிய விசைகள் பிரதான அட்டவணையில் உள்ள விசைகளின் அதே தரவைக் குறிப்பிடுவதால், அவை குறியீட்டு விசைகள் என்று அழைக்கப்படுகின்றன. கீழே உள்ள படத்தில் அவை ஆரஞ்சு நிறத்தில் சிறப்பிக்கப்பட்டுள்ளன.

ஒரே தரவுத்தளத்தில் வெவ்வேறு அட்டவணைகளின் விசைகளை ஒன்றிலிருந்து மற்றொன்று பிரிக்கும் பொருட்டு, அவை அனைத்திலும் கூடுதல் தொழில்நுட்ப புலம் அட்டவணை ஐடி சேர்க்கப்பட்டது. வரிசைப்படுத்துதலுக்கு அதிக முன்னுரிமை கொடுப்பதன் மூலம், முதலில் அட்டவணைகள் மூலமாகவும், அட்டவணைகளுக்குள் - எங்கள் சொந்த விதிகளின்படி விசைகளின் தொகுப்பை அடைவோம்.

குறியீட்டு விசை முதன்மை விசையின் அதே தரவைக் குறிக்கிறது. முதன்மை விசையின் மதிப்பு பகுதியின் நகலை அதனுடன் இணைப்பதன் மூலம் இந்த சொத்தை நேரடியாக செயல்படுத்துவது பல கண்ணோட்டங்களில் உகந்ததாக இல்லை:

1. எடுக்கப்பட்ட இடத்தைப் பொறுத்தவரை, மெட்டாடேட்டா மிகவும் பணக்காரமாக இருக்கும்.
2. செயல்திறன் பார்வையில், ஒரு முனையின் மெட்டாடேட்டாவைப் புதுப்பிக்கும்போது, ​​​​நீங்கள் அதை இரண்டு விசைகளைப் பயன்படுத்தி மீண்டும் எழுத வேண்டும்.
3. குறியீடு ஆதரவின் பார்வையில், ஒரு விசைக்கான தரவைப் புதுப்பிக்க மறந்துவிட்டால், சேமிப்பகத்தில் தரவு முரண்பாட்டின் மழுப்பலான பிழையைப் பெறுவோம்.

அடுத்து, இந்த குறைபாடுகளை எவ்வாறு அகற்றுவது என்பதைக் கருத்தில் கொள்வோம்.

அட்டவணைகளுக்கு இடையிலான உறவுகளை ஒழுங்கமைத்தல்

குறியீட்டு அட்டவணையை பிரதான அட்டவணையுடன் இணைக்க இந்த முறை மிகவும் பொருத்தமானது "விசை மதிப்பாக". அதன் பெயர் குறிப்பிடுவது போல, குறியீட்டு பதிவின் மதிப்பு பகுதி முதன்மை முக்கிய மதிப்பின் நகலாகும். இந்த அணுகுமுறை முதன்மை பதிவின் மதிப்பு பகுதியின் நகலை சேமிப்பதில் தொடர்புடைய மேலே குறிப்பிடப்பட்ட அனைத்து குறைபாடுகளையும் நீக்குகிறது. ஒரே விலை குறியீட்டு விசை மூலம் மதிப்பைப் பெற, தரவுத்தளத்தில் ஒன்றுக்கு பதிலாக 2 வினவல்களைச் செய்ய வேண்டும். திட்டவட்டமாக, இதன் விளைவாக வரும் தரவுத்தளத் திட்டம் இப்படி இருக்கும்.

அட்டவணைகளுக்கு இடையில் உறவுகளை ஒழுங்கமைப்பதற்கான மற்றொரு முறை "தேவையற்ற விசை". அதன் சாராம்சம் விசையில் கூடுதல் பண்புகளைச் சேர்ப்பதாகும், அவை வரிசைப்படுத்துவதற்கு அல்ல, ஆனால் அதனுடன் தொடர்புடைய விசையை மீண்டும் உருவாக்குவதற்குத் தேவை. Mail.ru கிளவுட் பயன்பாட்டில் அதன் பயன்பாட்டின் உண்மையான எடுத்துக்காட்டுகள் உள்ளன, இருப்பினும், ஆழமாக மூழ்குவதைத் தவிர்ப்பதற்காக. குறிப்பிட்ட iOS கட்டமைப்பின் சூழலில், நான் ஒரு கற்பனையான, ஆனால் தெளிவான உதாரணம் தருகிறேன்

கிளவுட் மொபைல் கிளையண்டுகள் பயனர் மற்றவர்களுடன் பகிர்ந்துள்ள அனைத்து கோப்புகள் மற்றும் கோப்புறைகளைக் காண்பிக்கும் பக்கத்தைக் கொண்டுள்ளன. ஒப்பீட்டளவில் சில கோப்புகள் இருப்பதால், அவற்றுடன் தொடர்புடைய விளம்பரம் குறித்த பல்வேறு வகையான குறிப்பிட்ட தகவல்கள் (யாருக்கு அணுகல் வழங்கப்படுகிறது, என்ன உரிமைகள் போன்றவை) இருப்பதால், மதிப்புப் பகுதியைச் சுமப்பது நியாயமானதாக இருக்காது. அதனுடன் பிரதான அட்டவணையில் பதிவு செய்யவும். இருப்பினும், இதுபோன்ற கோப்புகளை நீங்கள் ஆஃப்லைனில் காட்ட விரும்பினால், அதை எங்காவது சேமிக்க வேண்டும். அதற்கென தனி அட்டவணையை உருவாக்குவதே இயற்கையான தீர்வு. கீழேயுள்ள வரைபடத்தில், அதன் விசையானது "P" உடன் முன்னொட்டாக உள்ளது, மேலும் "Propname" என்ற ஒதுக்கிடத்தை "பொது தகவல்" என்ற குறிப்பிட்ட மதிப்புடன் மாற்றலாம்.

புதிய அட்டவணை உருவாக்கப்பட்ட அனைத்து தனிப்பட்ட மெட்டாடேட்டாவும், பதிவின் மதிப்புப் பகுதியில் வைக்கப்பட்டுள்ளது. அதே நேரத்தில், பிரதான அட்டவணையில் ஏற்கனவே சேமிக்கப்பட்டுள்ள கோப்புகள் மற்றும் கோப்புறைகள் பற்றிய தரவை நீங்கள் நகலெடுக்க விரும்பவில்லை. அதற்கு பதிலாக, தேவையற்ற தரவு "P" விசையில் "நோட் ஐடி" மற்றும் "டைம்ஸ்டாம்ப்" புலங்களின் வடிவத்தில் சேர்க்கப்படும். அவர்களுக்கு நன்றி, நீங்கள் ஒரு குறியீட்டு விசையை உருவாக்கலாம், அதில் இருந்து நீங்கள் ஒரு முதன்மை விசையைப் பெறலாம், அதில் இருந்து இறுதியாக, நீங்கள் முனை மெட்டாடேட்டாவைப் பெறலாம்.

முடிவுரை

எல்எம்டிபி செயல்படுத்தப்பட்டதன் முடிவுகளை நாங்கள் சாதகமாக மதிப்பிடுகிறோம். அதன் பிறகு, பயன்பாடு முடக்கங்களின் எண்ணிக்கை 30% குறைந்துள்ளது.

செய்த வேலையின் முடிவுகள் iOS குழுவிற்கு அப்பால் எதிரொலித்தது. தற்போது, ​​ஆண்ட்ராய்டு பயன்பாட்டில் உள்ள முக்கிய "கோப்புகள்" பிரிவுகளில் ஒன்று எல்எம்டிபியைப் பயன்படுத்துவதற்கு மாறியுள்ளது, மேலும் பிற பகுதிகளும் செயல்படுகின்றன. C மொழி, இதில் முக்கிய மதிப்பு அங்காடி செயல்படுத்தப்பட்டது, C++ இல் குறுக்கு-தளத்தைச் சுற்றி ஒரு பயன்பாட்டு கட்டமைப்பை ஆரம்பத்தில் உருவாக்க ஒரு நல்ல உதவியாக இருந்தது. இதன் விளைவாக வரும் C++ நூலகத்தை குறிக்கோள்-C மற்றும் கோட்லின் ஆகியவற்றில் இயங்குதளக் குறியீட்டுடன் தடையின்றி இணைக்க ஒரு குறியீடு ஜெனரேட்டர் பயன்படுத்தப்பட்டது. டிஜின்னி டிராப்பாக்ஸிலிருந்து, ஆனால் அது முற்றிலும் மாறுபட்ட கதை.

ஆதாரம்: www.habr.com