2019 അവസാനത്തോടെ, Mail.ru ക്ലൗഡ് iOS ടീമിൽ ഏറെക്കാലമായി കാത്തിരുന്ന ഒരു ഇവൻ്റ് സംഭവിച്ചു. ആപ്ലിക്കേഷൻ അവസ്ഥയുടെ സ്ഥിരമായ സംഭരണത്തിനുള്ള പ്രധാന ഡാറ്റാബേസ് മൊബൈൽ ലോകത്തിന് വളരെ വിചിത്രമായി മാറിയിരിക്കുന്നു മിന്നൽ മെമ്മറി-മാപ്പ് ചെയ്ത ഡാറ്റാബേസ് (എൽഎംഡിബി). കട്ടിന് താഴെ ഞങ്ങൾ നാല് ഭാഗങ്ങളായി അതിൻ്റെ വിശദമായ അവലോകനം നിങ്ങൾക്ക് വാഗ്ദാനം ചെയ്യുന്നു. ആദ്യം, അത്തരം നിസ്സാരമല്ലാത്തതും ബുദ്ധിമുട്ടുള്ളതുമായ തിരഞ്ഞെടുപ്പിൻ്റെ കാരണങ്ങളെക്കുറിച്ച് സംസാരിക്കാം. തുടർന്ന്, എൽഎംഡിബി ആർക്കിടെക്ചറിൻ്റെ ഹൃദയഭാഗത്തുള്ള മൂന്ന് സ്തംഭങ്ങൾ പരിഗണിക്കുന്നതിലേക്ക് ഞങ്ങൾ നീങ്ങും: മെമ്മറി-മാപ്പ് ചെയ്ത ഫയലുകൾ, ബി+-ട്രീ, ഇടപാടുകളും മൾട്ടിവേർഷനും നടപ്പിലാക്കുന്നതിനുള്ള കോപ്പി-ഓൺ-റൈറ്റ് സമീപനം. അവസാനമായി, മധുരപലഹാരത്തിന് - പ്രായോഗിക ഭാഗം. ലോ-ലെവൽ കീ-വാല്യൂ API-യുടെ മുകളിൽ ഒരു സൂചിക ഉൾപ്പെടെ നിരവധി പട്ടികകളുള്ള ഒരു ഡാറ്റാബേസ് സ്കീമ എങ്ങനെ രൂപകൽപ്പന ചെയ്യാമെന്നും നടപ്പിലാക്കാമെന്നും അതിൽ ഞങ്ങൾ നോക്കും.

ഉള്ളടക്കം

നടപ്പിലാക്കുന്നതിനുള്ള പ്രചോദനം
LMDB പൊസിഷനിംഗ്
എൽഎംഡിബിയുടെ മൂന്ന് തൂണുകൾ
3.1. തിമിംഗലം #1. മെമ്മറി മാപ്പ് ചെയ്ത ഫയലുകൾ
3.2. തിമിംഗലം #2. ബി+-മരം
3.3. തിമിംഗലം #3. കോപ്പി-ഓൺ-റൈറ്റ്
കീ-വാല്യൂ API-യുടെ മുകളിൽ ഒരു ഡാറ്റാ സ്കീമ രൂപകൽപ്പന ചെയ്യുന്നു
4.1. അടിസ്ഥാന അമൂർത്തങ്ങൾ
4.2. ടേബിൾ മോഡലിംഗ്
4.3. പട്ടികകൾ തമ്മിലുള്ള മോഡലിംഗ് ബന്ധങ്ങൾ

1. നടപ്പിലാക്കുന്നതിനുള്ള പ്രചോദനം

2015-ൽ ഒരു വർഷം, ഞങ്ങളുടെ ആപ്ലിക്കേഷൻ്റെ ഇൻ്റർഫേസ് എത്ര തവണ കാലതാമസമാണെന്ന് അളക്കാൻ ഞങ്ങൾ ബുദ്ധിമുട്ടി. ഒരു കാരണത്താലാണ് ഞങ്ങൾ ഇത് ചെയ്തത്. ഉപയോക്തൃ പ്രവർത്തനങ്ങളോട് ചിലപ്പോൾ ആപ്ലിക്കേഷൻ പ്രതികരിക്കുന്നത് നിർത്തുന്നതായി ഞങ്ങൾക്ക് പതിവായി പരാതികൾ ലഭിച്ചിട്ടുണ്ട്: ബട്ടണുകൾ അമർത്താൻ കഴിയില്ല, ലിസ്റ്റുകൾ സ്ക്രോൾ ചെയ്യുന്നില്ല, മുതലായവ. അളവുകളുടെ മെക്കാനിക്സിനെക്കുറിച്ച് പറഞ്ഞു AvitoTech-ൽ, അതിനാൽ ഇവിടെ ഞാൻ നമ്പറുകളുടെ ക്രമം മാത്രം നൽകുന്നു.

അളക്കൽ ഫലങ്ങൾ ഞങ്ങൾക്ക് ഒരു തണുത്ത മഴയായി. മരവിപ്പിക്കൽ മൂലമുണ്ടാകുന്ന പ്രശ്നങ്ങൾ മറ്റേതിനേക്കാളും കൂടുതലാണെന്ന് ഇത് മാറി. ഈ വസ്തുത മനസ്സിലാക്കുന്നതിന് മുമ്പ് ഗുണനിലവാരത്തിൻ്റെ പ്രധാന സാങ്കേതിക സൂചകം ക്രാഷ് ഫ്രീ ആയിരുന്നുവെങ്കിൽ, ഫോക്കസിന് ശേഷം മാറ്റി ഫ്രീസ് ഫ്രീയിൽ.

പണിതത് ഫ്രീസുകളുള്ള ഡാഷ്‌ബോർഡ് ചെലവഴിച്ചതിനു ശേഷവും അളവ് и ഗുണമേന്മയുള്ള അവരുടെ കാരണങ്ങളുടെ വിശകലനത്തിൽ, പ്രധാന ശത്രു വ്യക്തമായി - ആപ്ലിക്കേഷൻ്റെ പ്രധാന ത്രെഡിൽ കനത്ത ബിസിനസ്സ് യുക്തി നടപ്പിലാക്കി. ഈ അപമാനത്തോടുള്ള സ്വാഭാവിക പ്രതികരണം, അത് ജോലി സ്ട്രീമുകളിലേക്ക് തള്ളിവിടാനുള്ള ജ്വലിക്കുന്ന ആഗ്രഹമായിരുന്നു. ഈ പ്രശ്നം വ്യവസ്ഥാപിതമായി പരിഹരിക്കുന്നതിന്, ഭാരം കുറഞ്ഞ അഭിനേതാക്കളെ അടിസ്ഥാനമാക്കിയുള്ള ഒരു മൾട്ടി-ത്രെഡഡ് ആർക്കിടെക്ചർ ഞങ്ങൾ അവലംബിച്ചു. iOS ലോകത്തിനായുള്ള അതിൻ്റെ അഡാപ്റ്റേഷനായി ഞാൻ ഇത് സമർപ്പിച്ചു രണ്ട് ത്രെഡുകൾ കൂട്ടായ ട്വിറ്ററിലും ഹബ്രെയെക്കുറിച്ചുള്ള ലേഖനം. നിലവിലെ വിവരണത്തിൻ്റെ ഭാഗമായി, ഡാറ്റാബേസിൻ്റെ തിരഞ്ഞെടുപ്പിനെ സ്വാധീനിച്ച തീരുമാനത്തിൻ്റെ വശങ്ങൾ ഊന്നിപ്പറയാൻ ഞാൻ ആഗ്രഹിക്കുന്നു.

സിസ്റ്റം ഓർഗനൈസേഷൻ്റെ ആക്ടർ മോഡൽ അനുമാനിക്കുന്നത് മൾട്ടിത്രെഡിംഗ് അതിൻ്റെ രണ്ടാമത്തെ സത്തയായി മാറുമെന്നാണ്. അതിലെ മോഡൽ ഒബ്ജക്റ്റുകൾ സ്ട്രീം അതിരുകൾ കടക്കാൻ ഇഷ്ടപ്പെടുന്നു. അവർ ഇത് ചിലപ്പോൾ ഇവിടെയും അങ്ങോട്ടും ഇങ്ങോട്ടും അല്ല, മിക്കവാറും എല്ലായിടത്തും നിരന്തരം ചെയ്യുന്നു

അവതരിപ്പിച്ച ഡയഗ്രാമിലെ അടിസ്ഥാന ഘടകങ്ങളിലൊന്നാണ് ഡാറ്റാബേസ്. മാക്രോ പാറ്റേൺ നടപ്പിലാക്കുക എന്നതാണ് ഇതിൻ്റെ പ്രധാന ദൌത്യം പങ്കിട്ട ഡാറ്റാബേസ്. എൻ്റർപ്രൈസ് ലോകത്ത് സേവനങ്ങൾക്കിടയിൽ ഡാറ്റ സിൻക്രൊണൈസേഷൻ സംഘടിപ്പിക്കാൻ ഇത് ഉപയോഗിക്കുന്നുവെങ്കിൽ, നടൻ ആർക്കിടെക്ചറിൻ്റെ കാര്യത്തിൽ - ത്രെഡുകൾക്കിടയിലുള്ള ഡാറ്റ. അതിനാൽ, ഒരു മൾട്ടി-ത്രെഡ് പരിതസ്ഥിതിയിൽ പ്രവർത്തിക്കുമ്പോൾ കുറഞ്ഞ ബുദ്ധിമുട്ടുകൾ പോലും ഉണ്ടാക്കാത്ത ഒരു ഡാറ്റാബേസ് ഞങ്ങൾക്ക് ആവശ്യമാണ്. പ്രത്യേകിച്ചും, ഇതിൽ നിന്ന് ലഭിക്കുന്ന വസ്തുക്കൾ കുറഞ്ഞത് ത്രെഡ്-സുരക്ഷിതമായിരിക്കണം, കൂടാതെ പൂർണ്ണമായും മാറ്റാനാവാത്തതായിരിക്കണം എന്നാണ് ഇതിനർത്ഥം. നിങ്ങൾക്കറിയാവുന്നതുപോലെ, രണ്ടാമത്തേത് ഒരു ലോക്കിംഗും അവലംബിക്കാതെ നിരവധി ത്രെഡുകളിൽ നിന്ന് ഒരേസമയം ഉപയോഗിക്കാൻ കഴിയും, ഇത് പ്രകടനത്തിൽ ഗുണം ചെയ്യും.

ഡാറ്റാബേസിൻ്റെ തിരഞ്ഞെടുപ്പിനെ സ്വാധീനിച്ച രണ്ടാമത്തെ പ്രധാന ഘടകം ഞങ്ങളുടെ ക്ലൗഡ് API ആയിരുന്നു. ജിറ്റ് സ്വീകരിച്ച സിൻക്രൊണൈസേഷൻ സമീപനത്തിൽ നിന്നാണ് ഇത് പ്രചോദനം ഉൾക്കൊണ്ടത്. അവനെപ്പോലെ ഞങ്ങളും ലക്ഷ്യമാക്കി ഓഫ്‌ലൈൻ-ആദ്യ API, ഇത് ക്ലൗഡ് ക്ലയൻ്റുകൾക്ക് അനുയോജ്യമാണെന്ന് തോന്നുന്നു. അവർ ഒരിക്കൽ മാത്രമേ ക്ലൗഡിൻ്റെ മുഴുവൻ അവസ്ഥയും പമ്പ് ചെയ്യുകയുള്ളൂ എന്ന് അനുമാനിക്കപ്പെട്ടു, തുടർന്ന് ഭൂരിഭാഗം കേസുകളിലും സമന്വയം മാറ്റങ്ങളിലൂടെ സംഭവിക്കും. അയ്യോ, ഈ അവസരം ഇപ്പോഴും സൈദ്ധാന്തിക മേഖലയിൽ മാത്രമാണ്, പ്രായോഗികമായി പാച്ചുകൾ ഉപയോഗിച്ച് എങ്ങനെ പ്രവർത്തിക്കണമെന്ന് ക്ലയൻ്റുകൾ പഠിച്ചിട്ടില്ല. ഇതിന് വസ്തുനിഷ്ഠമായ നിരവധി കാരണങ്ങളുണ്ട്, അവ ആമുഖം വൈകിപ്പിക്കാതിരിക്കാൻ, ഞങ്ങൾ ബ്രാക്കറ്റുകൾ ഉപേക്ഷിക്കും. ഇപ്പോൾ, കൂടുതൽ താൽപ്പര്യമുള്ളത് ഒരു API "A" എന്നും അതിൻ്റെ ഉപഭോക്താവ് "B" എന്ന് പറയാതിരിക്കുകയും ചെയ്യുമ്പോൾ എന്ത് സംഭവിക്കും എന്നതിനെക്കുറിച്ചുള്ള പാഠത്തിൻ്റെ പ്രബോധനപരമായ നിഗമനങ്ങളാണ്.

അതിനാൽ, ഒരു പുൾ കമാൻഡ് എക്സിക്യൂട്ട് ചെയ്യുമ്പോൾ, ഒരു ലോക്കൽ സ്നാപ്പ്ഷോട്ടിലേക്ക് പാച്ചുകൾ പ്രയോഗിക്കുന്നതിനുപകരം, അതിൻ്റെ പൂർണ്ണമായ അവസ്ഥയെ പൂർണ്ണ സെർവർ അവസ്ഥയുമായി താരതമ്യം ചെയ്യുന്ന git നിങ്ങൾ സങ്കൽപ്പിക്കുന്നുവെങ്കിൽ, ക്ലൗഡിൽ സമന്വയം എങ്ങനെ സംഭവിക്കുന്നു എന്നതിനെക്കുറിച്ച് നിങ്ങൾക്ക് കൃത്യമായ ധാരണ ലഭിക്കും. ഉപഭോക്താക്കൾ. ഇത് നടപ്പിലാക്കാൻ, എല്ലാ സെർവറുകളെയും ലോക്കൽ ഫയലുകളെയും കുറിച്ചുള്ള മെറ്റാ-വിവരങ്ങൾക്കൊപ്പം മെമ്മറിയിൽ രണ്ട് DOM ട്രീകൾ അനുവദിക്കേണ്ടതുണ്ടെന്ന് ഊഹിക്കാൻ എളുപ്പമാണ്. ഒരു ഉപയോക്താവ് 500 ആയിരം ഫയലുകൾ ക്ലൗഡിൽ സംഭരിക്കുന്നുവെങ്കിൽ, അത് സമന്വയിപ്പിക്കുന്നതിന് 1 ദശലക്ഷം നോഡുകളുള്ള രണ്ട് മരങ്ങൾ പുനർനിർമ്മിക്കുകയും നശിപ്പിക്കുകയും ചെയ്യേണ്ടത് ആവശ്യമാണ്. എന്നാൽ ഓരോ നോഡും ഉപവിഷയങ്ങളുടെ ഒരു ഗ്രാഫ് അടങ്ങുന്ന ഒരു സംഗ്രഹമാണ്. ഈ വെളിച്ചത്തിൽ, പ്രൊഫൈലിംഗ് ഫലങ്ങൾ പ്രതീക്ഷിച്ചിരുന്നു. ലയിപ്പിക്കുന്ന അൽഗോരിതം കണക്കിലെടുക്കാതെ തന്നെ, ഒരു വലിയ സംഖ്യ ചെറിയ ഒബ്‌ജക്റ്റുകൾ സൃഷ്ടിക്കുന്നതിനും നശിപ്പിക്കുന്നതിനുമുള്ള നടപടിക്രമത്തിന് തന്നെ ഒരു ചില്ലിക്കാശും ചിലവാകും. അടിസ്ഥാന സമന്വയ പ്രവർത്തനം ഒരു വലിയ സംഖ്യയിൽ ഉൾപ്പെടുത്തിയിരിക്കുന്നതിനാൽ സ്ഥിതി കൂടുതൽ വഷളാക്കുന്നു. ഉപയോക്തൃ സ്ക്രിപ്റ്റുകളുടെ. തൽഫലമായി, ഒരു ഡാറ്റാബേസ് തിരഞ്ഞെടുക്കുന്നതിനുള്ള രണ്ടാമത്തെ പ്രധാന മാനദണ്ഡം ഞങ്ങൾ ശരിയാക്കുന്നു - ഒബ്‌ജക്റ്റുകളുടെ ചലനാത്മക അലോക്കേഷൻ ഇല്ലാതെ CRUD പ്രവർത്തനങ്ങൾ നടപ്പിലാക്കാനുള്ള കഴിവ്.

മറ്റ് ആവശ്യകതകൾ കൂടുതൽ പരമ്പരാഗതവും അവയുടെ മുഴുവൻ പട്ടികയും താഴെ പറയുന്നവയാണ്.

ത്രെഡ് സുരക്ഷ.
മൾട്ടിപ്രോസസിംഗ്. ത്രെഡുകൾക്കിടയിൽ മാത്രമല്ല, പ്രധാന ആപ്ലിക്കേഷനും ഐഒഎസ് എക്സ്റ്റൻഷനുകളും തമ്മിലുള്ള അവസ്ഥ സമന്വയിപ്പിക്കാൻ ഒരേ ഡാറ്റാബേസ് ഉദാഹരണം ഉപയോഗിക്കാനുള്ള ആഗ്രഹത്താൽ നിർദ്ദേശിക്കപ്പെടുന്നു.
സംഭരിച്ചിരിക്കുന്ന എൻ്റിറ്റികളെ മാറ്റാനാവാത്ത വസ്തുക്കളായി പ്രതിനിധീകരിക്കാനുള്ള കഴിവ്
CRUD പ്രവർത്തനങ്ങളിൽ ഡൈനാമിക് അലോക്കേഷനുകളൊന്നുമില്ല.
അടിസ്ഥാന പ്രോപ്പർട്ടികൾക്കുള്ള ഇടപാട് പിന്തുണ എസിഐഡി: ആറ്റോമിസിറ്റി, സ്ഥിരത, ഒറ്റപ്പെടൽ, വിശ്വാസ്യത.
ഏറ്റവും ജനപ്രിയമായ കേസുകളിൽ വേഗത.

ഈ ആവശ്യകതകൾക്കൊപ്പം, SQLite ഒരു നല്ല ചോയിസായിരുന്നു. എന്നിരുന്നാലും, ബദലുകളെക്കുറിച്ചുള്ള പഠനത്തിൻ്റെ ഭാഗമായി, ഞാൻ ഒരു പുസ്തകം കണ്ടു "LevelDB ഉപയോഗിച്ച് ആരംഭിക്കുന്നു". അവളുടെ നേതൃത്വത്തിൽ, യഥാർത്ഥ ക്ലൗഡ് സാഹചര്യങ്ങളിലെ വ്യത്യസ്ത ഡാറ്റാബേസുകളുമായി ജോലിയുടെ വേഗത താരതമ്യം ചെയ്തുകൊണ്ട് ഒരു ബെഞ്ച്മാർക്ക് എഴുതി. ഫലം ഞങ്ങളുടെ വന്യമായ പ്രതീക്ഷകളെ കവിഞ്ഞു. ഏറ്റവും ജനപ്രിയമായ സന്ദർഭങ്ങളിൽ - എല്ലാ ഫയലുകളുടെയും അടുക്കിയ ലിസ്റ്റിൽ ഒരു കഴ്‌സർ ലഭിക്കുന്നു, തന്നിരിക്കുന്ന ഡയറക്‌ടറിക്കായി എല്ലാ ഫയലുകളുടെയും അടുക്കിയ ലിസ്റ്റും - LMDB SQLite-നേക്കാൾ 10 മടങ്ങ് വേഗതയുള്ളതായി മാറി. തിരഞ്ഞെടുപ്പ് വ്യക്തമായി.

2. എൽഎംഡിബി പൊസിഷനിംഗ്

LMDB എന്നത് വളരെ ചെറിയ ഒരു ലൈബ്രറിയാണ് (10K വരികൾ മാത്രം), അത് ഡാറ്റാബേസുകളുടെ ഏറ്റവും താഴ്ന്ന അടിസ്ഥാന പാളി - സംഭരണം നടപ്പിലാക്കുന്നു.

മുകളിലെ ഡയഗ്രം കാണിക്കുന്നത്, ഉയർന്ന ലെവലുകൾ നടപ്പിലാക്കുന്ന SQLite-മായി LMDB താരതമ്യം ചെയ്യുന്നത് കോർ ഡാറ്റയുള്ള SQLite-നേക്കാൾ ശരിയല്ല എന്നാണ്. BerkeleyDB, LevelDB, Sophia, RocksDB, മുതലായവ - ഒരേ സ്റ്റോറേജ് എഞ്ചിനുകളെ തുല്യ എതിരാളികളായി ഉദ്ധരിക്കുന്നത് കൂടുതൽ ന്യായമായിരിക്കും. SQLite-ൻ്റെ സ്റ്റോറേജ് എഞ്ചിൻ ഘടകമായി LMDB പ്രവർത്തിക്കുന്ന സംഭവവികാസങ്ങൾ പോലും ഉണ്ട്. 2012ലായിരുന്നു ഇത്തരമൊരു പരീക്ഷണം ചെലവഴിച്ചു LMDB മുഖേന ഹോവാർഡ് ചു. ഫലങ്ങൾ വളരെ കൗതുകകരമായി മാറി, അദ്ദേഹത്തിൻ്റെ സംരംഭം OSS പ്രേമികൾ ഏറ്റെടുക്കുകയും വ്യക്തിയിൽ അതിൻ്റെ തുടർച്ച കണ്ടെത്തുകയും ചെയ്തു. LumoSQL. 2020 ജനുവരിയിൽ, ഈ പദ്ധതിയുടെ രചയിതാവ് ഡെൻ ഷിയറർ ആയിരുന്നു അവതരിപ്പിച്ചു അത് LinuxConfAu-ൽ.

എൽഎംഡിബി പ്രധാനമായും ആപ്ലിക്കേഷൻ ഡാറ്റാബേസുകൾക്കുള്ള എഞ്ചിൻ ആയി ഉപയോഗിക്കുന്നു. ലൈബ്രറി അതിൻ്റെ രൂപത്തിന് ഡെവലപ്പർമാരോട് കടപ്പെട്ടിരിക്കുന്നു OpenLDAP, അവരുടെ പ്രോജക്റ്റിൻ്റെ അടിസ്ഥാനമായി BerkeleyDB യിൽ കടുത്ത അതൃപ്തിയുള്ളവർ. ഒരു മിതമായ ലൈബ്രറിയിൽ നിന്ന് ആരംഭിക്കുന്നു ബി മരം, ഹോവാർഡ് ചു നമ്മുടെ കാലത്തെ ഏറ്റവും ജനപ്രിയമായ ഒരു ബദൽ സൃഷ്ടിക്കാൻ കഴിഞ്ഞു. ഈ കഥയ്ക്കും എൽഎംഡിബിയുടെ ആന്തരിക ഘടനയ്ക്കും അദ്ദേഹം തൻ്റെ വളരെ രസകരമായ റിപ്പോർട്ട് സമർപ്പിച്ചു. "മിന്നൽ മെമ്മറി-മാപ്പ് ചെയ്ത ഡാറ്റാബേസ്". ഒരു സ്റ്റോറേജ് സൗകര്യം കീഴടക്കുന്നതിനുള്ള ഒരു നല്ല ഉദാഹരണം ലിയോനിഡ് യൂറിയേവ് പങ്കിട്ടു (അക്ക യെലിയോ) ഹൈലോഡ് 2015 ലെ തൻ്റെ റിപ്പോർട്ടിൽ പോസിറ്റീവ് ടെക്നോളജീസിൽ നിന്ന് "LMDB എഞ്ചിൻ ഒരു പ്രത്യേക ചാമ്പ്യനാണ്". അതിൽ, ReOpenLDAP നടപ്പിലാക്കുന്നതിനുള്ള സമാനമായ ഒരു ചുമതലയുടെ പശ്ചാത്തലത്തിൽ അദ്ദേഹം LMDB-യെ കുറിച്ച് സംസാരിക്കുന്നു, LevelDB ഇതിനകം താരതമ്യ വിമർശനത്തിന് വിധേയമായിട്ടുണ്ട്. നടപ്പിലാക്കിയതിൻ്റെ ഫലമായി, പോസിറ്റീവ് ടെക്നോളജീസിന് സജീവമായി വികസിച്ചുകൊണ്ടിരിക്കുന്ന ഫോർക്ക് പോലും ഉണ്ടായിരുന്നു MDBX വളരെ രുചികരമായ സവിശേഷതകൾ, ഒപ്റ്റിമൈസേഷനുകൾ കൂടാതെ ബഗ് പരിഹാരങ്ങൾ.

എൽഎംഡിബി പലപ്പോഴും ഒരു സ്റ്റോറേജ് ആയി ഉപയോഗിക്കുന്നു. ഉദാഹരണത്തിന്, മോസില്ല ഫയർഫോക്സ് ബ്രൗസർ തിരഞ്ഞെടുത്തു ഇത് നിരവധി ആവശ്യങ്ങൾക്കായി, കൂടാതെ, പതിപ്പ് 9 മുതൽ, Xcode മുൻഗണന സൂചികകൾ സംഭരിക്കുന്നതിന് അതിൻ്റെ SQLite.

മൊബൈൽ ഡെവലപ്‌മെൻ്റിൻ്റെ ലോകത്തും ഈ എൻജിൻ അതിൻ്റെതായ അടയാളം പതിപ്പിച്ചിട്ടുണ്ട്. അതിൻ്റെ ഉപയോഗത്തിൻ്റെ സൂചനകൾ ആകാം കണ്ടെത്താം ടെലിഗ്രാമിനായുള്ള iOS ക്ലയൻ്റിൽ. ലിങ്ക്ഡ്ഇൻ കൂടുതൽ മുന്നോട്ട് പോയി അതിൻ്റെ ഹോംഗ്രൗൺ ഡാറ്റ കാഷിംഗ് ഫ്രെയിംവർക്ക് റോക്കറ്റ് ഡാറ്റയുടെ ഡിഫോൾട്ട് സ്റ്റോറേജായി LMDB തിരഞ്ഞെടുത്തു. പറഞ്ഞു 2016 ലെ അദ്ദേഹത്തിൻ്റെ ലേഖനത്തിൽ.

ഒറാക്കിളിൻ്റെ നിയന്ത്രണത്തിലായതിന് ശേഷം ബെർക്ക്‌ലിഡിബി അവശേഷിപ്പിച്ച സ്ഥലത്ത് സൂര്യനിൽ ഒരു സ്ഥാനത്തിനായി എൽഎംഡിബി വിജയകരമായി പോരാടുകയാണ്. സഹപാഠികളുമായി താരതമ്യപ്പെടുത്തുമ്പോൾ പോലും അതിൻ്റെ വേഗതയ്ക്കും വിശ്വാസ്യതയ്ക്കും ലൈബ്രറി പ്രിയപ്പെട്ടതാണ്. നിങ്ങൾക്കറിയാവുന്നതുപോലെ, സൗജന്യ ഉച്ചഭക്ഷണങ്ങളൊന്നുമില്ല, കൂടാതെ LMDB, SQLite എന്നിവയ്ക്കിടയിൽ തിരഞ്ഞെടുക്കുമ്പോൾ നിങ്ങൾ അഭിമുഖീകരിക്കേണ്ടിവരുന്ന ട്രേഡ്-ഓഫിനെ ഞാൻ ഊന്നിപ്പറയാൻ ആഗ്രഹിക്കുന്നു. വർധിച്ച വേഗത എങ്ങനെ കൈവരിക്കാമെന്ന് മുകളിലുള്ള ഡയഗ്രം വ്യക്തമായി കാണിക്കുന്നു. ആദ്യം, ഡിസ്ക് സംഭരണത്തിന് മുകളിലുള്ള അമൂർത്തീകരണത്തിൻ്റെ അധിക പാളികൾക്കായി ഞങ്ങൾ പണം നൽകില്ല. അവയില്ലാതെ ഒരു നല്ല വാസ്തുവിദ്യയ്ക്ക് ഇപ്പോഴും ചെയ്യാൻ കഴിയില്ലെന്ന് വ്യക്തമാണ്, അവ അനിവാര്യമായും ആപ്ലിക്കേഷൻ കോഡിൽ ദൃശ്യമാകും, പക്ഷേ അവ വളരെ സൂക്ഷ്മമായിരിക്കും. ഒരു നിർദ്ദിഷ്‌ട അപ്ലിക്കേഷന് ആവശ്യമില്ലാത്ത സവിശേഷതകൾ അവയിൽ അടങ്ങിയിരിക്കില്ല, ഉദാഹരണത്തിന്, SQL ഭാഷയിലെ ചോദ്യങ്ങൾക്കുള്ള പിന്തുണ. രണ്ടാമതായി, ഡിസ്ക് സ്റ്റോറേജിലേക്കുള്ള അഭ്യർത്ഥനകളിൽ ആപ്ലിക്കേഷൻ പ്രവർത്തനങ്ങളുടെ മാപ്പിംഗ് ഒപ്റ്റിമൽ നടപ്പിലാക്കുന്നത് സാധ്യമാകും. SQLite ആണെങ്കിൽ എന്റെ ജോലിയിൽ ഒരു ശരാശരി ആപ്ലിക്കേഷൻ്റെ ശരാശരി സ്റ്റാറ്റിസ്റ്റിക്കൽ ആവശ്യകതകളെ അടിസ്ഥാനമാക്കിയുള്ളതാണ്, അപ്പോൾ ഒരു ആപ്ലിക്കേഷൻ ഡെവലപ്പർ എന്ന നിലയിൽ നിങ്ങൾക്ക് പ്രധാന ജോലിഭാരം സാഹചര്യങ്ങളെക്കുറിച്ച് നന്നായി അറിയാം. കൂടുതൽ ഉൽപ്പാദനക്ഷമമായ ഒരു പരിഹാരത്തിനായി, പ്രാരംഭ പരിഹാരത്തിൻ്റെ വികസനത്തിനും തുടർന്നുള്ള പിന്തുണയ്‌ക്കും നിങ്ങൾ വർദ്ധിപ്പിച്ച വില നൽകേണ്ടിവരും.

3. എൽഎംഡിബിയുടെ മൂന്ന് തൂണുകൾ

ഒരു പക്ഷിയുടെ കാഴ്ചയിൽ നിന്ന് എൽഎംഡിബിയിലേക്ക് നോക്കിയതിനാൽ, ആഴത്തിൽ പോകാനുള്ള സമയമായി. അടുത്ത മൂന്ന് വിഭാഗങ്ങൾ സ്റ്റോറേജ് ആർക്കിടെക്ചർ നിലനിൽക്കുന്ന പ്രധാന തൂണുകളുടെ വിശകലനത്തിനായി നീക്കിവച്ചിരിക്കുന്നു:

ഡിസ്കിൽ പ്രവർത്തിക്കുന്നതിനും ആന്തരിക ഡാറ്റ ഘടനകൾ സമന്വയിപ്പിക്കുന്നതിനുമുള്ള ഒരു മെക്കാനിസമായി മെമ്മറി-മാപ്പ് ചെയ്ത ഫയലുകൾ.
സംഭരിച്ച ഡാറ്റയുടെ ഘടനയുടെ ഒരു ഓർഗനൈസേഷനായി B+-ട്രീ.
ACID ട്രാൻസാക്ഷൻ പ്രോപ്പർട്ടികളും മൾട്ടിവേർഷനും നൽകുന്നതിനുള്ള ഒരു സമീപനമെന്ന നിലയിൽ കോപ്പി-ഓൺ-റൈറ്റ്.

3.1 തിമിംഗലം #1. മെമ്മറി മാപ്പ് ചെയ്ത ഫയലുകൾ

മെമ്മറി-മാപ്പ് ചെയ്ത ഫയലുകൾ വളരെ പ്രധാനപ്പെട്ട ഒരു വാസ്തുവിദ്യാ ഘടകമാണ്, അവ ശേഖരണത്തിൻ്റെ പേരിൽ പോലും ദൃശ്യമാകുന്നു. സംഭരിച്ച വിവരങ്ങളിലേക്കുള്ള ആക്‌സസ് കാഷിംഗ്, സിൻക്രൊണൈസേഷൻ എന്നിവയുടെ പ്രശ്നങ്ങൾ പൂർണ്ണമായും ഓപ്പറേറ്റിംഗ് സിസ്റ്റത്തിന് വിട്ടുകൊടുത്തിരിക്കുന്നു. എൽഎംഡിബിയിൽ കാഷെകളൊന്നും തന്നെ അടങ്ങിയിട്ടില്ല. ഇത് രചയിതാവിൻ്റെ ബോധപൂർവമായ തീരുമാനമാണ്, കാരണം മാപ്പ് ചെയ്ത ഫയലുകളിൽ നിന്ന് നേരിട്ട് ഡാറ്റ വായിക്കുന്നത് എഞ്ചിൻ നടപ്പിലാക്കുന്നതിൽ ധാരാളം കോണുകൾ മുറിക്കാൻ നിങ്ങളെ അനുവദിക്കുന്നു. അവയിൽ ചിലതിൻ്റെ പൂർണ്ണമായ പട്ടികയിൽ നിന്ന് വളരെ അകലെയാണ് ചുവടെ.

നിരവധി പ്രക്രിയകളിൽ നിന്ന് പ്രവർത്തിക്കുമ്പോൾ സ്റ്റോറേജിലെ ഡാറ്റയുടെ സ്ഥിരത നിലനിർത്തുന്നത് ഓപ്പറേറ്റിംഗ് സിസ്റ്റത്തിൻ്റെ ഉത്തരവാദിത്തമായി മാറുന്നു. അടുത്ത വിഭാഗത്തിൽ, ഈ മെക്കാനിക്സ് വിശദമായും ചിത്രങ്ങളുമായും ചർച്ചചെയ്യുന്നു.
കാഷെകളുടെ അഭാവം ഡൈനാമിക് അലോക്കേഷനുമായി ബന്ധപ്പെട്ട ഓവർഹെഡിൽ നിന്ന് എൽഎംഡിബിയെ പൂർണ്ണമായും ഒഴിവാക്കുന്നു. പ്രായോഗികമായി ഡാറ്റ വായിക്കുക എന്നതിനർത്ഥം വെർച്വൽ മെമ്മറിയിൽ ശരിയായ വിലാസത്തിലേക്ക് ഒരു പോയിൻ്റർ സജ്ജീകരിക്കുക, അതിൽ കൂടുതലൊന്നും ഇല്ല. ഇത് സയൻസ് ഫിക്ഷൻ പോലെ തോന്നുന്നു, എന്നാൽ സ്റ്റോറേജ് സോഴ്സ് കോഡിൽ calloc ലേക്കുള്ള എല്ലാ കോളുകളും സ്റ്റോറേജ് കോൺഫിഗറേഷൻ ഫംഗ്ഷനിൽ കേന്ദ്രീകരിച്ചിരിക്കുന്നു.
കാഷെകളുടെ അഭാവം അവയുടെ ആക്‌സസ് സമന്വയവുമായി ബന്ധപ്പെട്ട ലോക്കുകളുടെ അഭാവവും അർത്ഥമാക്കുന്നു. ഒരേ സമയം അനിയന്ത്രിതമായ വായനക്കാരുടെ എണ്ണം ഉണ്ടാകാവുന്ന വായനക്കാർക്ക്, ഡാറ്റയിലേക്കുള്ള വഴിയിൽ ഒരു മ്യൂട്ടെക്സ് പോലും കാണുന്നില്ല. ഇതുമൂലം, CPU-കളുടെ എണ്ണത്തെ അടിസ്ഥാനമാക്കി വായനാ വേഗതയ്ക്ക് അനുയോജ്യമായ ലീനിയർ സ്കേലബിളിറ്റി ഉണ്ട്. എൽഎംഡിബിയിൽ, പരിഷ്ക്കരണ പ്രവർത്തനങ്ങൾ മാത്രമേ സമന്വയിപ്പിച്ചിട്ടുള്ളൂ. ഒരു സമയത്ത് ഒരു എഴുത്തുകാരൻ മാത്രമേ ഉണ്ടാകൂ.
ഒരു മൾട്ടി-ത്രെഡഡ് പരിതസ്ഥിതിയിൽ പ്രവർത്തിക്കുന്നതുമായി ബന്ധപ്പെട്ട വളരെ സങ്കീർണ്ണമായ പിശകുകൾ ഒഴിവാക്കുന്നതാണ് ഏറ്റവും കുറഞ്ഞ കാഷിംഗ്, സിൻക്രൊണൈസേഷൻ ലോജിക്. Usenix OSDI 2014 കോൺഫറൻസിൽ രസകരമായ രണ്ട് ഡാറ്റാബേസ് പഠനങ്ങൾ ഉണ്ടായിരുന്നു: "എല്ലാ ഫയൽ സിസ്റ്റങ്ങളും തുല്യമായി സൃഷ്ടിച്ചിട്ടില്ല: ക്രാഷ്-കോൺസിസ്റ്റൻ്റ് ആപ്ലിക്കേഷനുകളുടെ ക്രാഫ്റ്റിംഗിൻ്റെ സങ്കീർണ്ണതയെക്കുറിച്ച്" и "വിനോദത്തിനും ലാഭത്തിനും വേണ്ടിയുള്ള പീഡന ഡാറ്റാബേസുകൾ". അവയിൽ നിന്ന് നിങ്ങൾക്ക് LMDB-യുടെ അഭൂതപൂർവമായ വിശ്വാസ്യതയെക്കുറിച്ചും SQLite-നേക്കാൾ മികച്ച ACID ഇടപാട് പ്രോപ്പർട്ടികളുടെ ഏതാണ്ട് കുറ്റമറ്റ രീതിയിൽ നടപ്പിലാക്കുന്നതിനെക്കുറിച്ചും വിവരങ്ങൾ ശേഖരിക്കാനാകും.
എൽഎംഡിബിയുടെ മിനിമലിസം അതിൻ്റെ കോഡിൻ്റെ മെഷീൻ പ്രാതിനിധ്യം പ്രോസസറിൻ്റെ എൽ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 മെക്കാനിസം ഉപയോഗിക്കുന്നില്ല എന്നതാണ്. ഇതിനർത്ഥം, പ്രദർശിപ്പിച്ച ഡാറ്റയെ ഐഒഎസ് ക്ലീൻ മെമ്മറിയായി തരംതിരിച്ചിരിക്കുന്നു, കൂടാതെ മെമ്മറി ഫൂട്ട്പ്രിൻ്റിന് സംഭാവന നൽകുന്നില്ല എന്നാണ്. VM ട്രാക്കർ എന്ന ഒരു Xcode ടൂൾ ഉപയോഗിച്ച് നിങ്ങൾക്ക് ഇത് സ്ഥിരീകരിക്കാൻ കഴിയും. പ്രവർത്തന സമയത്ത് ക്ലൗഡ് ആപ്ലിക്കേഷൻ്റെ iOS വെർച്വൽ മെമ്മറിയുടെ അവസ്ഥ ചുവടെയുള്ള സ്ക്രീൻഷോട്ട് കാണിക്കുന്നു. തുടക്കത്തിൽ, 2 LMDB സംഭവങ്ങൾ അതിൽ ആരംഭിച്ചു. ആദ്യത്തേത് 1GiB വെർച്വൽ മെമ്മറിയിൽ തൻ്റെ ഫയൽ പ്രദർശിപ്പിക്കാൻ അനുവദിച്ചു, രണ്ടാമത്തേത് - 512MiB. രണ്ട് സ്റ്റോറേജുകളും ഒരു നിശ്ചിത അളവിലുള്ള റസിഡൻ്റ് മെമ്മറി കൈവശപ്പെടുത്തിയിട്ടുണ്ടെങ്കിലും, അവ രണ്ടും വൃത്തികെട്ട വലുപ്പം സംഭാവന ചെയ്യുന്നില്ല.

ഇപ്പോൾ മോശം വാർത്തകളുടെ സമയമാണ്. 64-ബിറ്റ് ഡെസ്ക്ടോപ്പ് ഓപ്പറേറ്റിംഗ് സിസ്റ്റങ്ങളിലെ സ്വാപ്പ് മെക്കാനിസത്തിന് നന്ദി, ഓരോ പ്രോസസിനും അതിൻ്റെ സാധ്യതയുള്ള സ്വാപ്പിനുള്ള സൌജന്യ ഹാർഡ് ഡിസ്ക് സ്പേസ് അനുവദിക്കുന്നത്ര വെർച്വൽ അഡ്രസ് സ്പേസ് എടുക്കാൻ കഴിയും. iOS-ൽ കംപ്രഷൻ ഉപയോഗിച്ച് സ്വാപ്പ് മാറ്റിസ്ഥാപിക്കുന്നത് സൈദ്ധാന്തികമായ പരമാവധി കുറയ്ക്കുന്നു. ഇപ്പോൾ എല്ലാ ജീവനുള്ള പ്രക്രിയകളും പ്രധാന (റാം റീഡ്) മെമ്മറിയിലേക്ക് യോജിച്ചതായിരിക്കണം, കൂടാതെ അനുയോജ്യമല്ലാത്തവയെല്ലാം അവസാനിപ്പിക്കാൻ നിർബന്ധിതരായിരിക്കണം. മുകളിൽ സൂചിപ്പിച്ചതുപോലെ ഇത് പ്രസ്താവിച്ചിരിക്കുന്നു റിപ്പോർട്ട്, കൂടാതെ ഔദ്യോഗിക ഡോക്യുമെന്റേഷൻ. അനന്തരഫലമായി, mmap വഴിയുള്ള അലോക്കേഷന് ലഭ്യമായ മെമ്മറിയുടെ അളവ് iOS കഠിനമായി പരിമിതപ്പെടുത്തുന്നു. ഇവിടെ ഇവിടെ ഈ സിസ്‌റ്റം കോൾ ഉപയോഗിച്ച് വ്യത്യസ്‌ത ഉപകരണങ്ങളിൽ അനുവദിക്കാവുന്ന മെമ്മറിയുടെ അളവിൻ്റെ അനുഭവപരമായ പരിധികൾ നിങ്ങൾക്ക് പരിശോധിക്കാം. ഏറ്റവും ആധുനിക സ്മാർട്ട്‌ഫോൺ മോഡലുകളിൽ, iOS 2 ജിഗാബൈറ്റുകളാൽ ഉദാരമായി മാറിയിരിക്കുന്നു, കൂടാതെ ഐപാഡിൻ്റെ മികച്ച പതിപ്പുകളിൽ - 4. പ്രായോഗികമായി, തീർച്ചയായും, നിങ്ങൾ ഏറ്റവും കുറഞ്ഞ പിന്തുണയുള്ള ഉപകരണ മോഡലുകളിൽ ശ്രദ്ധ കേന്ദ്രീകരിക്കേണ്ടതുണ്ട്, അവിടെ എല്ലാം വളരെ സങ്കടകരമാണ്. അതിലും മോശം, വിഎം ട്രാക്കറിലെ ആപ്ലിക്കേഷൻ്റെ മെമ്മറി നില നോക്കുന്നതിലൂടെ, മെമ്മറി-മാപ്പ് ചെയ്ത മെമ്മറിയിൽ നിന്ന് എൽഎംഡിബി വളരെ അകലെയാണെന്ന് നിങ്ങൾ കണ്ടെത്തും. സിസ്റ്റം അലോക്കേറ്ററുകൾ, റിസോഴ്സ് ഫയലുകൾ, ഇമേജ് ഫ്രെയിംവർക്കുകൾ, മറ്റ് ചെറിയ വേട്ടക്കാർ എന്നിവയാൽ നല്ല കഷണങ്ങൾ തിന്നുതീർക്കുന്നു.

ക്ലൗഡിലെ പരീക്ഷണ ഫലങ്ങളെ അടിസ്ഥാനമാക്കി, എൽഎംഡിബി അനുവദിച്ച മെമ്മറിക്കായി ഞങ്ങൾ ഇനിപ്പറയുന്ന വിട്ടുവീഴ്ച മൂല്യങ്ങളിലേക്ക് എത്തി: 384-ബിറ്റ് ഉപകരണങ്ങൾക്കായി 32 മെഗാബൈറ്റും 768-ബിറ്റ് ഉപകരണങ്ങൾക്ക് 64 ഉം. ഈ വോളിയം ഉപയോഗിച്ചതിന് ശേഷം, ഏത് പരിഷ്ക്കരണ പ്രവർത്തനങ്ങളും കോഡിൽ അവസാനിക്കാൻ തുടങ്ങും MDB_MAP_FULL. ഞങ്ങളുടെ നിരീക്ഷണത്തിൽ അത്തരം പിശകുകൾ ഞങ്ങൾ നിരീക്ഷിക്കുന്നു, പക്ഷേ അവ വളരെ ചെറുതാണ്, ഈ ഘട്ടത്തിൽ അവ അവഗണിക്കാം.

സ്‌റ്റോറേജിൻ്റെ അമിതമായ മെമ്മറി ഉപഭോഗത്തിനുള്ള ഒരു വ്യക്തമല്ലാത്ത കാരണം ദീർഘകാല ഇടപാടുകളായിരിക്കാം. ഈ രണ്ട് പ്രതിഭാസങ്ങളും എങ്ങനെ ബന്ധപ്പെട്ടിരിക്കുന്നു എന്ന് മനസിലാക്കാൻ, എൽഎംഡിബിയുടെ ശേഷിക്കുന്ന രണ്ട് തൂണുകൾ പരിഗണിക്കുന്നതിലൂടെ ഞങ്ങളെ സഹായിക്കും.

3.2 തിമിംഗലം #2. ബി+-മരം

ഒരു കീ-മൂല്യം സംഭരണത്തിന് മുകളിലുള്ള പട്ടികകൾ അനുകരിക്കുന്നതിന്, ഇനിപ്പറയുന്ന പ്രവർത്തനങ്ങൾ അതിൻ്റെ API-യിൽ ഉണ്ടായിരിക്കണം:

ഒരു പുതിയ ഘടകം ചേർക്കുന്നു.
നൽകിയിരിക്കുന്ന കീ ഉപയോഗിച്ച് ഒരു ഘടകത്തിനായി തിരയുക.
ഒരു ഘടകം നീക്കംചെയ്യുന്നു.
കീകൾ അടുക്കിയ ക്രമത്തിൽ അവയുടെ ഇടവേളകളിൽ ആവർത്തിക്കുക.

നാല് പ്രവർത്തനങ്ങളും എളുപ്പത്തിൽ നടപ്പിലാക്കാൻ കഴിയുന്ന ഏറ്റവും ലളിതമായ ഡാറ്റാ ഘടന ഒരു ബൈനറി സെർച്ച് ട്രീ ആണ്. അതിൻ്റെ ഓരോ നോഡുകളും ഒരു കീ പ്രതിനിധീകരിക്കുന്നു, അത് ചൈൽഡ് കീകളുടെ മുഴുവൻ ഉപവിഭാഗത്തെയും രണ്ട് സബ്ട്രീകളായി വിഭജിക്കുന്നു. ഇടത് ഭാഗത്ത് മാതാപിതാക്കളേക്കാൾ ചെറുതും വലതുവശത്ത് വലുതും അടങ്ങിയിരിക്കുന്നു. ഓർഡർ ചെയ്‌ത ഒരു കൂട്ടം കീകൾ നേടുന്നത് ക്ലാസിക് ട്രീ ട്രാവേസലുകളിലൊന്നിലൂടെയാണ്

ബൈനറി മരങ്ങൾക്ക് രണ്ട് അടിസ്ഥാന പിഴവുകൾ ഉണ്ട്, അത് ഒരു ഡിസ്ക് അധിഷ്ഠിത ഡാറ്റാ ഘടനയായി പ്രവർത്തിക്കുന്നതിൽ നിന്ന് തടയുന്നു. ഒന്നാമതായി, അവരുടെ സന്തുലിതാവസ്ഥയുടെ അളവ് പ്രവചനാതീതമാണ്. വൃക്ഷങ്ങൾ ലഭിക്കുന്നതിന് ഗണ്യമായ അപകടസാധ്യതയുണ്ട്, അതിൽ വ്യത്യസ്ത ശാഖകളുടെ ഉയരം വളരെ വ്യത്യസ്തമായിരിക്കും, ഇത് പ്രതീക്ഷിക്കുന്നതിനേക്കാൾ തിരയലിൻ്റെ അൽഗോരിതം സങ്കീർണ്ണതയെ ഗണ്യമായി വഷളാക്കുന്നു. രണ്ടാമതായി, നോഡുകൾക്കിടയിലുള്ള ക്രോസ്-ലിങ്കുകളുടെ സമൃദ്ധി ബൈനറി ട്രീകൾക്ക് മെമ്മറിയിലെ പ്രാദേശികത്വം നഷ്ടപ്പെടുത്തുന്നു, ക്ലോസ് നോഡുകൾ (അവ തമ്മിലുള്ള കണക്ഷനുകളുടെ കാര്യത്തിൽ) വെർച്വൽ മെമ്മറിയിലെ തികച്ചും വ്യത്യസ്തമായ പേജുകളിൽ സ്ഥിതിചെയ്യാം. അനന്തരഫലമായി, ഒരു ട്രീയിലെ നിരവധി അയൽപക്ക നോഡുകളുടെ ലളിതമായ യാത്രയ്ക്ക് പോലും, താരതമ്യപ്പെടുത്താവുന്ന എണ്ണം പേജുകൾ സന്ദർശിക്കേണ്ടി വന്നേക്കാം. ഇൻ-മെമ്മറി ഡാറ്റാ ഘടന എന്ന നിലയിൽ ബൈനറി മരങ്ങളുടെ ഫലപ്രാപ്തിയെക്കുറിച്ച് നമ്മൾ സംസാരിക്കുമ്പോൾ പോലും ഇത് ഒരു പ്രശ്നമാണ്, കാരണം പ്രോസസർ കാഷെയിൽ പേജുകൾ നിരന്തരം തിരിക്കുന്നത് വിലകുറഞ്ഞ ആനന്ദമല്ല. ഡിസ്കിൽ നിന്ന് നോഡുകളുമായി ബന്ധപ്പെട്ട പേജുകൾ ഇടയ്ക്കിടെ വീണ്ടെടുക്കുമ്പോൾ, സാഹചര്യം പൂർണ്ണമായും മാറുന്നു പരിതാപകരം.

ബി-ട്രീകൾ, ബൈനറി മരങ്ങളുടെ പരിണാമമായതിനാൽ, മുമ്പത്തെ ഖണ്ഡികയിൽ കണ്ടെത്തിയ പ്രശ്നങ്ങൾ പരിഹരിക്കുന്നു. ഒന്നാമതായി, അവർ സ്വയം ബാലൻസ് ചെയ്യുന്നു. രണ്ടാമതായി, അവരുടെ ഓരോ നോഡുകളും ചൈൽഡ് കീകളുടെ സെറ്റിനെ 2 ആയി വിഭജിക്കുന്നു, മറിച്ച് M ഓർഡർ ചെയ്ത ഉപസെറ്റുകളായി വിഭജിക്കുന്നു, കൂടാതെ M എന്ന സംഖ്യ നൂറുകണക്കിന് അല്ലെങ്കിൽ ആയിരക്കണക്കിന് ക്രമത്തിൽ വളരെ വലുതായിരിക്കും.

അതുവഴി:

ഓരോ നോഡിലും ഇതിനകം ഓർഡർ ചെയ്ത ധാരാളം കീകൾ അടങ്ങിയിരിക്കുന്നു, മരങ്ങൾ വളരെ ചെറുതാണ്.
മരത്തിന് മെമ്മറിയിലെ സ്ഥലത്തിൻ്റെ സ്വത്ത് ലഭിക്കുന്നു, കാരണം മൂല്യത്തിൽ അടുത്തിരിക്കുന്ന കീകൾ സ്വാഭാവികമായും ഒരേ അല്ലെങ്കിൽ അയൽ നോഡുകളിൽ പരസ്പരം അടുത്തായി സ്ഥിതിചെയ്യുന്നു.
ഒരു തിരച്ചിൽ ഓപ്പറേഷൻ സമയത്ത് ഒരു മരത്തിൽ ഇറങ്ങുമ്പോൾ ട്രാൻസിറ്റ് നോഡുകളുടെ എണ്ണം കുറയുന്നു.
ശ്രേണി അന്വേഷണങ്ങളിൽ വായിക്കുന്ന ടാർഗെറ്റ് നോഡുകളുടെ എണ്ണം കുറയുന്നു, കാരണം അവയിൽ ഓരോന്നിനും ഇതിനകം തന്നെ ധാരാളം ഓർഡർ ചെയ്ത കീകൾ അടങ്ങിയിരിക്കുന്നു.

ഡാറ്റ സംഭരിക്കുന്നതിന് എൽഎംഡിബി ബി-ട്രീയുടെ ഒരു വ്യതിയാനം ബി+ ട്രീ ഉപയോഗിക്കുന്നു. മുകളിലുള്ള ഡയഗ്രം അതിൽ നിലനിൽക്കുന്ന മൂന്ന് തരം നോഡുകൾ കാണിക്കുന്നു:

മുകളിൽ റൂട്ട് ആണ്. ഒരു വെയർഹൗസിനുള്ളിലെ ഒരു ഡാറ്റാബേസ് എന്ന ആശയമല്ലാതെ മറ്റൊന്നും ഇത് യാഥാർത്ഥ്യമാക്കുന്നില്ല. ഒരു LMDB ഉദാഹരണത്തിനുള്ളിൽ, നിങ്ങൾക്ക് മാപ്പ് ചെയ്‌ത വെർച്വൽ വിലാസ ഇടം പങ്കിടുന്ന നിരവധി ഡാറ്റാബേസുകൾ സൃഷ്ടിക്കാൻ കഴിയും. അവ ഓരോന്നും സ്വന്തം വേരിൽ നിന്നാണ് ആരംഭിക്കുന്നത്.
ഏറ്റവും താഴ്ന്ന നിലയിലാണ് ഇലകൾ. അവയിൽ മാത്രം ഡാറ്റാബേസിൽ സംഭരിച്ചിരിക്കുന്ന കീ-മൂല്യം ജോഡികൾ അടങ്ങിയിരിക്കുന്നു. വഴിയിൽ, ഇതാണ് ബി+-മരങ്ങളുടെ പ്രത്യേകത. ഒരു സാധാരണ ബി-ട്രീ എല്ലാ ലെവലുകളുടെയും നോഡുകളിൽ മൂല്യമുള്ള ഭാഗങ്ങൾ സംഭരിക്കുന്നുവെങ്കിൽ, B+ വ്യതിയാനം ഏറ്റവും താഴ്ന്നതിൽ മാത്രമായിരിക്കും. ഈ വസ്തുത പരിഹരിച്ച ശേഷം, എൽഎംഡിബിയിൽ ഉപയോഗിക്കുന്ന ട്രീയുടെ ഉപവിഭാഗത്തെ ഞങ്ങൾ ബി-ട്രീ എന്ന് വിളിക്കും.
റൂട്ടിനും ഇലകൾക്കും ഇടയിൽ നാവിഗേഷൻ (ശാഖ) നോഡുകളുള്ള 0 അല്ലെങ്കിൽ അതിൽ കൂടുതൽ സാങ്കേതിക തലങ്ങളുണ്ട്. ക്രമീകരിച്ച കീകൾ ഇലകൾക്കിടയിൽ വിഭജിക്കുക എന്നതാണ് അവരുടെ ചുമതല.

ഭൗതികമായി, നോഡുകൾ ഒരു മുൻകൂട്ടി നിശ്ചയിച്ച ദൈർഘ്യത്തിൻ്റെ മെമ്മറി ബ്ലോക്കുകളാണ്. അവയുടെ വലുപ്പം ഞങ്ങൾ മുകളിൽ ചർച്ച ചെയ്ത ഓപ്പറേറ്റിംഗ് സിസ്റ്റത്തിലെ മെമ്മറി പേജുകളുടെ വലുപ്പത്തിൻ്റെ ഗുണിതമാണ്. നോഡ് ഘടന താഴെ കാണിച്ചിരിക്കുന്നു. തലക്കെട്ടിൽ മെറ്റാ വിവരങ്ങൾ അടങ്ങിയിരിക്കുന്നു, അതിൽ ഏറ്റവും വ്യക്തമായത് ചെക്ക്സം ആണ്. ഡാറ്റയുള്ള സെല്ലുകൾ സ്ഥിതിചെയ്യുന്ന ഓഫ്‌സെറ്റുകളെക്കുറിച്ചുള്ള വിവരങ്ങൾ അടുത്തതായി വരുന്നു. നാവിഗേഷൻ നോഡുകളെക്കുറിച്ചാണ് നമ്മൾ സംസാരിക്കുന്നതെങ്കിൽ, ഡാറ്റ ഒന്നുകിൽ കീകളാകാം, അല്ലെങ്കിൽ ഇലകളുടെ കാര്യത്തിൽ മുഴുവൻ കീ-വാല്യൂ ജോഡികളാകാം. സൃഷ്ടിയിലെ പേജുകളുടെ ഘടനയെക്കുറിച്ച് നിങ്ങൾക്ക് കൂടുതൽ വായിക്കാം. "ഉയർന്ന പെർഫോമൻസ് കീ-വാല്യൂ സ്റ്റോറുകളുടെ വിലയിരുത്തൽ".

പേജ് നോഡുകളുടെ ആന്തരിക ഉള്ളടക്കം കൈകാര്യം ചെയ്ത ശേഷം, ഇനിപ്പറയുന്ന രൂപത്തിൽ ഞങ്ങൾ എൽഎംഡിബി ബി-ട്രീയെ ലളിതമായ രീതിയിൽ പ്രതിനിധീകരിക്കും.

നോഡുകളുള്ള പേജുകൾ ഡിസ്കിൽ തുടർച്ചയായി സ്ഥിതിചെയ്യുന്നു. ഫയലിൻ്റെ അറ്റത്താണ് കൂടുതൽ അക്കമിട്ട പേജുകൾ സ്ഥിതി ചെയ്യുന്നത്. മെറ്റാ പേജ് എന്ന് വിളിക്കപ്പെടുന്നതിൽ എല്ലാ മരങ്ങളുടെയും വേരുകൾ കണ്ടെത്താൻ കഴിയുന്ന ഓഫ്‌സെറ്റുകളെക്കുറിച്ചുള്ള വിവരങ്ങൾ അടങ്ങിയിരിക്കുന്നു. ഒരു ഫയൽ തുറക്കുമ്പോൾ, സാധുവായ ഒരു മെറ്റാ പേജ് തിരയുന്നതിനായി LMDB ഫയൽ പേജ് അവസാനം മുതൽ തുടക്കം വരെ സ്കാൻ ചെയ്യുകയും അതിലൂടെ നിലവിലുള്ള ഡാറ്റാബേസുകൾ കണ്ടെത്തുകയും ചെയ്യുന്നു.

ഇപ്പോൾ, ഡാറ്റാ ഓർഗനൈസേഷൻ്റെ ലോജിക്കൽ, ഫിസിക്കൽ ഘടനയെക്കുറിച്ച് ഒരു ആശയം ഉള്ളതിനാൽ, നമുക്ക് LMDB യുടെ മൂന്നാമത്തെ സ്തംഭം പരിഗണിക്കാം. അതിൻ്റെ സഹായത്തോടെയാണ് എല്ലാ സ്റ്റോറേജ് പരിഷ്‌ക്കരണങ്ങളും ഇടപാടുകളായും പരസ്പരം ഒറ്റപ്പെട്ടും സംഭവിക്കുന്നത്, ഡാറ്റാബേസിന് മൊത്തത്തിൽ മൾട്ടിവേർഷൻ്റെ പ്രോപ്പർട്ടി നൽകുന്നു.

3.3 തിമിംഗലം #3. കോപ്പി-ഓൺ-റൈറ്റ്

ചില ബി-ട്രീ പ്രവർത്തനങ്ങളിൽ അതിൻ്റെ നോഡുകളിൽ മാറ്റങ്ങൾ വരുത്തുന്നത് ഉൾപ്പെടുന്നു. ഒരു നോഡിലേക്ക് ഒരു പുതിയ കീ ചേർക്കുന്നത് ഒരു ഉദാഹരണമാണ്, അത് ഇതിനകം തന്നെ അതിൻ്റെ പരമാവധി ശേഷിയിൽ എത്തിയിരിക്കുന്നു. ഈ സാഹചര്യത്തിൽ, ഒന്നാമതായി, നോഡ് രണ്ടായി വിഭജിക്കേണ്ടത് ആവശ്യമാണ്, രണ്ടാമതായി, പുതിയ ബഡ്ഡിംഗ് ചൈൽഡ് നോഡിലേക്ക് ഒരു ലിങ്ക് ചേർക്കുക. ഈ നടപടിക്രമം വളരെ അപകടകരമാണ്. ചില കാരണങ്ങളാൽ (തകർച്ച, വൈദ്യുതി തടസ്സം മുതലായവ) പരമ്പരയിൽ നിന്നുള്ള മാറ്റങ്ങളുടെ ഒരു ഭാഗം മാത്രമേ സംഭവിക്കുകയുള്ളൂവെങ്കിൽ, മരം ഒരു അസ്ഥിരമായ അവസ്ഥയിൽ തുടരും.

ഒരു ഡാറ്റാബേസ് തെറ്റ്-സഹിഷ്ണുത ഉണ്ടാക്കുന്നതിനുള്ള ഒരു പരമ്പരാഗത പരിഹാരം ബി-ട്രീയുടെ അടുത്തായി ഒരു അധിക ഓൺ-ഡിസ്‌ക് ഡാറ്റ ഘടന ചേർക്കുക എന്നതാണ് - ഒരു ഇടപാട് ലോഗ്, ഇത് റൈറ്റ്-എഹെഡ് ലോഗ് (WAL) എന്നും അറിയപ്പെടുന്നു. ബി-ട്രീ തന്നെ പരിഷ്കരിക്കുന്നതിന് മുമ്പ് ഉദ്ദേശിച്ച പ്രവർത്തനം കർശനമായി എഴുതിയിരിക്കുന്ന ഒരു ഫയലാണിത്. അതിനാൽ, സ്വയം രോഗനിർണ്ണയ സമയത്ത് ഡാറ്റ അഴിമതി കണ്ടെത്തിയാൽ, ഡാറ്റാബേസ് സ്വയം ക്രമപ്പെടുത്തുന്നതിന് ലോഗ് പരിശോധിക്കുന്നു.

കോപ്പി-ഓൺ-റൈറ്റ് എന്ന് വിളിക്കപ്പെടുന്ന ഒരു തെറ്റ് സഹിഷ്ണുത മെക്കാനിസമായി എൽഎംഡിബി മറ്റൊരു രീതി തിരഞ്ഞെടുത്തു. നിലവിലുള്ള ഒരു പേജിലെ ഡാറ്റ അപ്‌ഡേറ്റ് ചെയ്യുന്നതിനുപകരം, അത് ആദ്യം അത് പൂർണ്ണമായും പകർത്തുകയും പകർപ്പിൽ എല്ലാ മാറ്റങ്ങളും വരുത്തുകയും ചെയ്യുന്നു എന്നതാണ് ഇതിൻ്റെ സാരം.

അടുത്തതായി, അപ്‌ഡേറ്റ് ചെയ്‌ത ഡാറ്റ ലഭ്യമാകുന്നതിന്, അതിൻ്റെ പാരൻ്റ് നോഡിൽ നിലവിലുള്ള നോഡിലേക്കുള്ള ലിങ്ക് മാറ്റേണ്ടത് ആവശ്യമാണ്. ഇതിനും മാറ്റം വരുത്തേണ്ടതിനാൽ അതും മുൻപേ പകർത്തി. ഈ പ്രക്രിയ റൂട്ട് വരെ ആവർത്തിച്ച് തുടരുന്നു. അവസാനമായി മാറ്റേണ്ടത് മെറ്റാ പേജിലെ ഡാറ്റയാണ്.

അപ്‌ഡേറ്റ് നടപടിക്രമത്തിനിടയിൽ പെട്ടെന്ന് പ്രോസസ്സ് തകരാറിലായാൽ, ഒന്നുകിൽ ഒരു പുതിയ മെറ്റാ പേജ് സൃഷ്ടിക്കപ്പെടില്ല, അല്ലെങ്കിൽ അത് പൂർണ്ണമായും ഡിസ്കിലേക്ക് എഴുതപ്പെടില്ല, കൂടാതെ അതിൻ്റെ ചെക്ക്സം തെറ്റായിരിക്കും. ഈ രണ്ട് സാഹചര്യങ്ങളിലും, പുതിയ പേജുകൾ ലഭ്യമല്ല, എന്നാൽ പഴയ പേജുകളെ ബാധിക്കില്ല. ഡാറ്റാ സ്ഥിരത നിലനിർത്താൻ എൽഎംഡിബി രേഖാമൂലം എഴുതേണ്ടതിൻ്റെ ആവശ്യകത ഇത് ഇല്ലാതാക്കുന്നു. യഥാർത്ഥത്തിൽ, മുകളിൽ വിവരിച്ച ഡിസ്കിലെ ഡാറ്റ സംഭരണത്തിൻ്റെ ഘടന ഒരേസമയം അതിൻ്റെ പ്രവർത്തനം ഏറ്റെടുക്കുന്നു. വ്യക്തമായ ഇടപാട് ലോഗിൻ്റെ അഭാവം ഉയർന്ന ഡാറ്റ റീഡിംഗ് വേഗത നൽകുന്ന എൽഎംഡിബിയുടെ സവിശേഷതകളിലൊന്നാണ്.

തത്ഫലമായുണ്ടാകുന്ന ഡിസൈൻ, ആപ്പൻഡ്-ഒൺലി ബി-ട്രീ എന്ന് വിളിക്കുന്നു, സ്വാഭാവികമായും ഇടപാട് ഒറ്റപ്പെടലും മൾട്ടി-വേർഷനിംഗും നൽകുന്നു. LMDB-യിൽ, ഓരോ ഓപ്പൺ ഇടപാടുകളും നിലവിൽ പ്രസക്തമായ ട്രീ റൂട്ടുമായി ബന്ധപ്പെട്ടിരിക്കുന്നു. ഇടപാട് പൂർത്തിയാകുന്നതുവരെ, അതുമായി ബന്ധപ്പെട്ട ട്രീയുടെ പേജുകൾ ഒരിക്കലും മാറ്റുകയോ ഡാറ്റയുടെ പുതിയ പതിപ്പുകൾക്കായി വീണ്ടും ഉപയോഗിക്കുകയോ ചെയ്യില്ല. അതിനാൽ, ആ സമയത്ത് പ്രസക്തമായിരുന്ന ഡാറ്റയുടെ സെറ്റ് ഉപയോഗിച്ച് നിങ്ങൾക്ക് ഇഷ്ടമുള്ളിടത്തോളം പ്രവർത്തിക്കാൻ കഴിയും. ഈ സമയത്ത് സ്റ്റോറേജ് സജീവമായി അപ്‌ഡേറ്റ് ചെയ്യുന്നത് തുടരുകയാണെങ്കിൽപ്പോലും, ഇടപാട് തുറന്നു. ഇതാണ് മൾട്ടിവേർഷൻ്റെ സത്ത, എൽഎംഡിബിയെ നമ്മുടെ പ്രിയപ്പെട്ടവർക്ക് അനുയോജ്യമായ ഒരു ഡാറ്റാ ഉറവിടമാക്കി മാറ്റുന്നു UICollectionView. ഒരു ട്രാൻസാക്ഷൻ തുറന്ന് കഴിഞ്ഞാൽ, ഒന്നും ബാക്കിയാകുമോ എന്ന ഭയത്താൽ, നിലവിലുള്ള ഡാറ്റ ചില ഇൻ-മെമ്മറി ഘടനയിലേക്ക് വേഗത്തിൽ പമ്പ് ചെയ്ത് ആപ്ലിക്കേഷൻ്റെ മെമ്മറി ഫുട്‌പ്രിൻ്റ് വർദ്ധിപ്പിക്കേണ്ട ആവശ്യമില്ല. ഈ സവിശേഷത എൽഎംഡിബിയെ അതേ SQLite-ൽ നിന്ന് വേർതിരിക്കുന്നു, ഇത് അത്തരം മൊത്തത്തിലുള്ള ഒറ്റപ്പെടലിനെക്കുറിച്ച് അഭിമാനിക്കാൻ കഴിയില്ല. രണ്ടാമത്തേതിൽ രണ്ട് ഇടപാടുകൾ തുറക്കുകയും അവയിലൊന്നിൽ ഒരു നിശ്ചിത റെക്കോർഡ് ഇല്ലാതാക്കുകയും ചെയ്‌താൽ, ശേഷിക്കുന്ന രണ്ടാമത്തേതിൽ അതേ റെക്കോർഡ് ഇനി ലഭിക്കില്ല.

നാണയത്തിൻ്റെ മറുവശം വെർച്വൽ മെമ്മറിയുടെ ഉയർന്ന ഉപഭോഗമാണ്. ഡാറ്റാബേസിൻ്റെ വ്യത്യസ്ത പതിപ്പുകൾ നോക്കി 3 ഓപ്പൺ റീഡ് ട്രാൻസാക്ഷനുകൾക്കൊപ്പം ഒരേസമയം പരിഷ്കരിച്ചാൽ ഡാറ്റാബേസ് ഘടന എങ്ങനെയായിരിക്കുമെന്ന് സ്ലൈഡ് കാണിക്കുന്നു. നിലവിലെ ഇടപാടുകളുമായി ബന്ധപ്പെട്ട റൂട്ടുകളിൽ നിന്ന് ലഭ്യമാകുന്ന നോഡുകൾ എൽഎംഡിബിക്ക് വീണ്ടും ഉപയോഗിക്കാൻ കഴിയാത്തതിനാൽ, മെമ്മറിയിൽ മറ്റൊരു നാലാമത്തെ റൂട്ട് അനുവദിക്കുകയും അതിന് കീഴിലുള്ള പരിഷ്കരിച്ച പേജുകൾ വീണ്ടും ക്ലോൺ ചെയ്യുകയും ചെയ്യുകയല്ലാതെ സ്റ്റോറിന് മറ്റ് മാർഗമില്ല.

ഇവിടെ മെമ്മറി-മാപ്പ് ചെയ്ത ഫയലുകളുടെ വിഭാഗം തിരിച്ചുവിളിക്കുന്നത് ഉപയോഗപ്രദമാകും. വെർച്വൽ മെമ്മറിയുടെ അധിക ഉപഭോഗം ഞങ്ങളെ വളരെയധികം വിഷമിപ്പിക്കേണ്ടതില്ലെന്ന് തോന്നുന്നു, കാരണം ഇത് ആപ്ലിക്കേഷൻ്റെ മെമ്മറി ഫുട്‌പ്രിൻ്റിലേക്ക് സംഭാവന ചെയ്യുന്നില്ല. എന്നിരുന്നാലും, അതേ സമയം, അത് അനുവദിക്കുന്നതിൽ iOS വളരെ പിശുക്ക് കാണിക്കുന്നുവെന്നും, ഒരു സെർവറിലോ ഡെസ്ക്ടോപ്പിലോ ഉള്ളതുപോലെ, 1 ടെറാബൈറ്റിൻ്റെ LMDB മേഖല നൽകാൻ ഞങ്ങൾക്ക് കഴിയില്ലെന്നും ഈ സവിശേഷതയെക്കുറിച്ച് ചിന്തിക്കേണ്ടതില്ലെന്നും ശ്രദ്ധിക്കപ്പെട്ടു. സാധ്യമെങ്കിൽ, ഇടപാടുകളുടെ ആയുസ്സ് കഴിയുന്നത്ര ചെറുതാക്കാൻ നിങ്ങൾ ശ്രമിക്കണം.

4. കീ-വാല്യൂ API-യുടെ മുകളിൽ ഒരു ഡാറ്റാ സ്കീമ രൂപകൽപ്പന ചെയ്യുന്നു

എൽഎംഡിബി നൽകുന്ന അടിസ്ഥാന സംഗ്രഹങ്ങൾ നോക്കി നമുക്ക് ഞങ്ങളുടെ API വിശകലനം ആരംഭിക്കാം: പരിസ്ഥിതിയും ഡാറ്റാബേസുകളും, കീകളും മൂല്യങ്ങളും, ഇടപാടുകളും കഴ്‌സറുകളും.

കോഡ് ലിസ്റ്റിംഗുകളെക്കുറിച്ചുള്ള ഒരു കുറിപ്പ്

പൊതു LMDB 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. ഇതുകൂടാതെ, അത് ആവശ്യമായിരുന്നു നാൽക്കവല 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;

ഒരു കംപാറേറ്റർ ഉപയോഗിച്ച്, സ്റ്റോർ കീകൾ ആരോഹണ ക്രമത്തിൽ അടുക്കുന്നു. നിങ്ങളത് മാറ്റിസ്ഥാപിക്കുന്നില്ലെങ്കിൽ, ഡിഫോൾട്ട് ഉപയോഗിക്കും, അത് അവയെ ബൈറ്റ്-ബൈ-ബൈറ്റ് എന്ന ക്രമത്തിൽ നിഘണ്ടു ക്രമത്തിൽ അടുക്കുന്നു.

ഇടപാടുകൾ

ഇടപാട് ഘടന വിശദമായി വിവരിച്ചിരിക്കുന്നു മുൻ അധ്യായം, അതിനാൽ ഇവിടെ ഞാൻ അവയുടെ പ്രധാന സവിശേഷതകൾ ചുരുക്കമായി ആവർത്തിക്കും:

എല്ലാ അടിസ്ഥാന ഗുണങ്ങളെയും പിന്തുണയ്ക്കുന്നു എസിഐഡി: ആറ്റോമിസിറ്റി, സ്ഥിരത, ഒറ്റപ്പെടൽ, വിശ്വാസ്യത. MDBX-ൽ പരിഹരിച്ച MacOS-ലും iOS-ലും ഡ്യൂറബിലിറ്റിയുടെ കാര്യത്തിൽ ഒരു ബഗ് ഉണ്ടെന്ന് ശ്രദ്ധിക്കാതിരിക്കാൻ എനിക്ക് കഴിയില്ല. നിങ്ങൾക്ക് അവയിൽ കൂടുതൽ വായിക്കാം വായിക്കുക.
മൾട്ടി ത്രെഡിംഗിൻ്റെ സമീപനം "ഒറ്റ എഴുത്തുകാരൻ / ഒന്നിലധികം വായനക്കാർ" സ്കീം വിവരിക്കുന്നു. എഴുത്തുകാർ പരസ്പരം തടയുന്നു, പക്ഷേ വായനക്കാരെ തടയരുത്. വായനക്കാർ എഴുത്തുകാരെയോ പരസ്പരം തടയുന്നില്ല.
നെസ്റ്റഡ് ഇടപാടുകൾക്കുള്ള പിന്തുണ.
മൾട്ടിവേർഷൻ പിന്തുണ.

എൽഎംഡിബിയിലെ മൾട്ടിവേർഷൻ വളരെ മികച്ചതാണ്, അത് പ്രവർത്തനത്തിൽ പ്രകടിപ്പിക്കാൻ ഞാൻ ആഗ്രഹിക്കുന്നു. താഴെയുള്ള കോഡിൽ നിന്ന്, ഓരോ ഇടപാടും അത് തുറന്ന സമയത്ത് നിലവിലുള്ള ഡാറ്റാബേസിൻ്റെ പതിപ്പ് ഉപയോഗിച്ച് പ്രവർത്തിക്കുന്നുണ്ടെന്ന് നിങ്ങൾക്ക് കാണാൻ കഴിയും, തുടർന്നുള്ള എല്ലാ മാറ്റങ്ങളിൽ നിന്നും പൂർണ്ണമായും ഒറ്റപ്പെട്ടു. സംഭരണം ആരംഭിക്കുന്നതും അതിലേക്ക് ഒരു ടെസ്റ്റ് റെക്കോർഡ് ചേർക്കുന്നതും രസകരമായ ഒന്നും പ്രതിനിധീകരിക്കുന്നില്ല, അതിനാൽ ഈ ആചാരങ്ങൾ സ്‌പോയിലറിന് കീഴിൽ അവശേഷിക്കുന്നു.

ഒരു ടെസ്റ്റ് എൻട്രി ചേർക്കുന്നു

MDB_env *env;
MDB_dbi dbi;
MDB_txn *txn;

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

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

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

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

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

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

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

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

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

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

SQLite-ലും ഇതേ ട്രിക്ക് പരീക്ഷിച്ച് എന്താണ് സംഭവിക്കുന്നതെന്ന് കാണാൻ ഞാൻ ശുപാർശ ചെയ്യുന്നു.

മൾട്ടിവേർഷൻ ഒരു iOS ഡെവലപ്പറുടെ ജീവിതത്തിന് വളരെ നല്ല ആനുകൂല്യങ്ങൾ നൽകുന്നു. ഈ പ്രോപ്പർട്ടി ഉപയോഗിച്ച്, ഉപയോക്തൃ അനുഭവപരിഗണനകളെ അടിസ്ഥാനമാക്കി നിങ്ങൾക്ക് സ്‌ക്രീൻ ഫോമുകൾക്കായുള്ള ഡാറ്റ ഉറവിടത്തിൻ്റെ അപ്‌ഡേറ്റ് നിരക്ക് എളുപ്പത്തിലും സ്വാഭാവികമായും ക്രമീകരിക്കാനാകും. ഉദാഹരണത്തിന്, സിസ്റ്റം മീഡിയ ഗാലറിയിൽ നിന്ന് ഉള്ളടക്കം സ്വയമേവ ലോഡുചെയ്യുന്നത് പോലെയുള്ള Mail.ru ക്ലൗഡ് ആപ്ലിക്കേഷൻ്റെ ഒരു സവിശേഷത എടുക്കാം. ഒരു നല്ല കണക്ഷൻ ഉപയോഗിച്ച്, സെർവറിലേക്ക് സെക്കൻഡിൽ നിരവധി ഫോട്ടോകൾ ചേർക്കാൻ ക്ലയൻ്റിന് കഴിയും. ഓരോ ഡൗൺലോഡിനും ശേഷം നിങ്ങൾ അപ്ഡേറ്റ് ചെയ്യുകയാണെങ്കിൽ UICollectionView ഉപയോക്താവിൻ്റെ ക്ലൗഡിലെ മീഡിയ ഉള്ളടക്കം ഉപയോഗിച്ച്, ഈ പ്രക്രിയയിൽ നിങ്ങൾക്ക് 60 എഫ്പിഎസുകളും സുഗമമായ സ്ക്രോളിംഗും മറക്കാൻ കഴിയും. ഇടയ്‌ക്കിടെയുള്ള സ്‌ക്രീൻ അപ്‌ഡേറ്റുകൾ തടയാൻ, അടിസ്ഥാനത്തിലുള്ള ഡാറ്റ മാറുന്ന നിരക്ക് നിങ്ങൾ എങ്ങനെയെങ്കിലും പരിമിതപ്പെടുത്തേണ്ടതുണ്ട് UICollectionViewDataSource.

ഡാറ്റാബേസ് മൾട്ടിവേർഷനെ പിന്തുണയ്ക്കുന്നില്ലെങ്കിൽ നിലവിലെ നിലവിലെ അവസ്ഥയിൽ മാത്രം പ്രവർത്തിക്കാൻ നിങ്ങളെ അനുവദിക്കുകയാണെങ്കിൽ, ഡാറ്റയുടെ സമയ-സ്ഥിരതയുള്ള സ്നാപ്പ്ഷോട്ട് സൃഷ്ടിക്കുന്നതിന്, നിങ്ങൾ അത് ചില ഇൻ-മെമ്മറി ഡാറ്റാ ഘടനയിലേക്കോ താൽക്കാലിക പട്ടികയിലേക്കോ പകർത്തേണ്ടതുണ്ട്. ഈ സമീപനങ്ങളിൽ ഏതെങ്കിലും വളരെ ചെലവേറിയതാണ്. ഇൻ-മെമ്മറി സ്‌റ്റോറേജിൻ്റെ കാര്യത്തിൽ, നിർമ്മിച്ച ഒബ്‌ജക്‌റ്റുകൾ സംഭരിക്കുന്നതിലൂടെ ഉണ്ടാകുന്ന മെമ്മറിയിലും കാലക്രമേണ, അനാവശ്യ ORM പരിവർത്തനങ്ങളുമായി ബന്ധപ്പെട്ടും ഞങ്ങൾക്ക് ചിലവ് ലഭിക്കും. താൽക്കാലിക പട്ടികയെ സംബന്ധിച്ചിടത്തോളം, ഇത് കൂടുതൽ ചെലവേറിയ ആനന്ദമാണ്, നിസ്സാരമല്ലാത്ത കേസുകളിൽ മാത്രം അർത്ഥമാക്കുന്നു.

എൽഎംഡിബിയുടെ മൾട്ടിവേർഷൻ സൊല്യൂഷൻ വളരെ ഗംഭീരമായ രീതിയിൽ സ്ഥിരതയുള്ള ഡാറ്റാ ഉറവിടം നിലനിർത്തുന്നതിനുള്ള പ്രശ്നം പരിഹരിക്കുന്നു. ഒരു ഇടപാടും വോയിലയും തുറന്നാൽ മാത്രം മതി - ഞങ്ങൾ അത് പൂർത്തിയാക്കുന്നത് വരെ, ഡാറ്റ സെറ്റ് ശരിയാക്കുമെന്ന് ഉറപ്പുനൽകുന്നു. അതിൻ്റെ അപ്‌ഡേറ്റ് വേഗതയുടെ യുക്തി ഇപ്പോൾ പൂർണ്ണമായും അവതരണ പാളിയുടെ കൈകളിലാണ്, കാര്യമായ ഉറവിടങ്ങളൊന്നുമില്ല.

കഴ്‌സറുകൾ

ബി-ട്രീ ട്രാവെർസലിലൂടെ കീ-വാല്യൂ ജോഡികളിൽ ക്രമാനുഗതമായി ആവർത്തിക്കുന്നതിനുള്ള ഒരു സംവിധാനം കഴ്‌സറുകൾ നൽകുന്നു. അവയില്ലാതെ, ഡാറ്റാബേസിലെ പട്ടികകൾ ഫലപ്രദമായി മാതൃകയാക്കുന്നത് അസാധ്യമാണ്, അത് ഞങ്ങൾ ഇപ്പോൾ തിരിയുന്നു.

4.2 ടേബിൾ മോഡലിംഗ്

അടിസ്ഥാന അമൂർത്തതകൾക്ക് മുകളിൽ ഒരു ടേബിൾ പോലെയുള്ള ഉയർന്ന തലത്തിലുള്ള അമൂർത്തീകരണം നിർമ്മിക്കാൻ കീ ഓർഡറിംഗിൻ്റെ പ്രോപ്പർട്ടി നിങ്ങളെ അനുവദിക്കുന്നു. ക്ലൗഡ് ക്ലയൻ്റിൻ്റെ പ്രധാന പട്ടികയുടെ ഉദാഹരണം ഉപയോഗിച്ച് ഈ പ്രക്രിയ പരിഗണിക്കാം, അത് ഉപയോക്താവിൻ്റെ എല്ലാ ഫയലുകളെയും ഫോൾഡറുകളെയും കുറിച്ചുള്ള വിവരങ്ങൾ കാഷെ ചെയ്യുന്നു.

ടേബിൾ സ്കീമ

ഒരു ഫോൾഡർ ട്രീ ഉള്ള ഒരു ടേബിൾ സ്ട്രക്ചർ ക്രമീകരിക്കേണ്ട ഒരു പൊതു സാഹചര്യമാണ് നൽകിയിരിക്കുന്ന ഡയറക്‌ടറിയിൽ സ്ഥിതിചെയ്യുന്ന എല്ലാ ഘടകങ്ങളുടെയും തിരഞ്ഞെടുപ്പ്. ഇത്തരത്തിലുള്ള കാര്യക്ഷമമായ അന്വേഷണങ്ങൾക്കുള്ള ഒരു നല്ല ഡാറ്റാ ഓർഗനൈസേഷൻ മാതൃകയാണ് തൊട്ടടുത്തുള്ള ലിസ്റ്റ്. കീ-വാല്യൂ സ്റ്റോറേജിന് മുകളിൽ ഇത് നടപ്പിലാക്കാൻ, പാരൻ്റ് ഡയറക്‌ടറിയിലെ അംഗത്വത്തെ അടിസ്ഥാനമാക്കി ഗ്രൂപ്പുചെയ്യുന്ന തരത്തിൽ ഫയലുകളുടെയും ഫോൾഡറുകളുടെയും കീകൾ അടുക്കേണ്ടത് ആവശ്യമാണ്. കൂടാതെ, ഒരു വിൻഡോസ് ഉപയോക്താവിന് പരിചിതമായ രൂപത്തിൽ ഡയറക്‌ടറിയിലെ ഉള്ളടക്കങ്ങൾ പ്രദർശിപ്പിക്കുന്നതിന് (ആദ്യം ഫോൾഡറുകൾ, തുടർന്ന് ഫയലുകൾ, രണ്ടും അക്ഷരമാലാക്രമത്തിൽ അടുക്കുന്നു), കീയിൽ അനുബന്ധ അധിക ഫീൽഡുകൾ ഉൾപ്പെടുത്തേണ്ടത് ആവശ്യമാണ്.

കൈയിലുള്ള ടാസ്‌ക്കിനെ അടിസ്ഥാനമാക്കി, ഒരു ബൈറ്റ് അറേയുടെ രൂപത്തിലുള്ള കീകളുടെ പ്രാതിനിധ്യം എങ്ങനെയായിരിക്കുമെന്ന് ചുവടെയുള്ള ചിത്രം കാണിക്കുന്നു. പാരൻ്റ് ഡയറക്‌ടറിയുടെ (ചുവപ്പ്) ഐഡൻ്റിഫയർ ഉള്ള ബൈറ്റുകൾ ആദ്യം സ്ഥാപിക്കുന്നു, തുടർന്ന് തരം (പച്ച) ഒപ്പം വാലിൽ പേര് (നീല). ഡിഫോൾട്ട് എൽഎംഡിബി കംപാറേറ്റർ ഉപയോഗിച്ച് നിഘണ്ടു ക്രമത്തിൽ അടുക്കി, അവ ക്രമീകരിച്ചിരിക്കുന്നത് ആവശ്യമായ രീതിയിൽ. ഒരേ ചുവന്ന പ്രിഫിക്‌സുള്ള കീകൾ തുടർച്ചയായി സഞ്ചരിക്കുന്നത്, അധിക പോസ്റ്റ്-പ്രോസസ്സിംഗ് ആവശ്യമില്ലാതെ, ഉപയോക്തൃ ഇൻ്റർഫേസിൽ (വലതുവശത്ത്) പ്രദർശിപ്പിക്കേണ്ട ക്രമത്തിൽ അവയുടെ അനുബന്ധ മൂല്യങ്ങൾ ഞങ്ങൾക്ക് നൽകുന്നു.

കീകളും മൂല്യങ്ങളും സീരിയലൈസ് ചെയ്യുന്നു

വസ്തുക്കളെ സീരിയലൈസ് ചെയ്യുന്നതിനുള്ള നിരവധി രീതികൾ ലോകത്ത് കണ്ടുപിടിച്ചിട്ടുണ്ട്. വേഗതയല്ലാതെ മറ്റൊരു ആവശ്യവുമില്ലാത്തതിനാൽ, ഞങ്ങൾ സ്വയം സാധ്യമായ ഏറ്റവും വേഗതയേറിയത് തിരഞ്ഞെടുത്തു - സി ഭാഷാ ഘടനയുടെ ഒരു ഉദാഹരണം ഉൾക്കൊള്ളുന്ന മെമ്മറിയുടെ ഒരു ഡംപ് അങ്ങനെ, ഒരു ഡയറക്ടറി എലമെൻ്റിൻ്റെ കീ ഇനിപ്പറയുന്ന ഘടന ഉപയോഗിച്ച് മാതൃകയാക്കാം. NodeKey.

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

സംരക്ഷിക്കാൻ NodeKey ഒബ്ജക്റ്റിൽ ആവശ്യമായ സ്റ്റോറേജിൽ MDB_val ഘടനയുടെ തുടക്കത്തിൻ്റെ വിലാസത്തിലേക്ക് ഡാറ്റ പോയിൻ്റർ സ്ഥാപിക്കുക, ഫംഗ്ഷൻ ഉപയോഗിച്ച് അവയുടെ വലുപ്പം കണക്കാക്കുക sizeof.

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

ഡാറ്റാബേസ് തിരഞ്ഞെടുക്കൽ മാനദണ്ഡത്തെക്കുറിച്ചുള്ള ആദ്യ അധ്യായത്തിൽ, CRUD ഓപ്പറേഷനുകൾക്കുള്ളിലെ ഡൈനാമിക് അലോക്കേഷനുകൾ ഒരു പ്രധാന തിരഞ്ഞെടുക്കൽ ഘടകമായി കുറയ്ക്കുന്നത് ഞാൻ പരാമർശിച്ചു. ഫംഗ്ഷൻ കോഡ് serialize ഡാറ്റാബേസിലേക്ക് പുതിയ റെക്കോർഡുകൾ ചേർക്കുമ്പോൾ എൽഎംഡിബിയുടെ കാര്യത്തിൽ അവ എങ്ങനെ പൂർണമായും ഒഴിവാക്കാം എന്ന് കാണിക്കുന്നു. സെർവറിൽ നിന്നുള്ള ഇൻകമിംഗ് ബൈറ്റ് അറേ ആദ്യം സ്റ്റാക്ക് സ്ട്രക്ചറുകളായി രൂപാന്തരപ്പെടുന്നു, തുടർന്ന് അവ നിസ്സാരമായി സംഭരണത്തിലേക്ക് വലിച്ചെറിയപ്പെടുന്നു. എൽഎംഡിബിയിൽ ഡൈനാമിക് അലോക്കേഷനുകളൊന്നും ഇല്ലെന്നത് കണക്കിലെടുക്കുമ്പോൾ, iOS മാനദണ്ഡങ്ങൾക്കനുസൃതമായി നിങ്ങൾക്ക് ഒരു മികച്ച സാഹചര്യം ലഭിക്കും - നെറ്റ്‌വർക്കിൽ നിന്ന് ഡിസ്കിലേക്കുള്ള മുഴുവൻ പാതയിലും ഡാറ്റയുമായി പ്രവർത്തിക്കാൻ സ്റ്റാക്ക് മെമ്മറി മാത്രം ഉപയോഗിക്കുക!

ഒരു ബൈനറി കംപാറേറ്റർ ഉപയോഗിച്ച് കീകൾ ഓർഡർ ചെയ്യുന്നു

ഒരു കംപാറേറ്റർ എന്ന് വിളിക്കുന്ന ഒരു പ്രത്യേക ഫംഗ്ഷനാണ് കീ ഓർഡർ ബന്ധം വ്യക്തമാക്കുന്നത്. എഞ്ചിന് അവയിൽ അടങ്ങിയിരിക്കുന്ന ബൈറ്റുകളുടെ സെമാൻ്റിക്‌സിനെ കുറിച്ച് ഒന്നും അറിയാത്തതിനാൽ, സ്വതവേയുള്ള താരതമ്യപ്പെടുത്തുന്നയാൾക്ക് ഒരു ബൈറ്റ്-ബൈ-ബൈറ്റ് താരതമ്യത്തിലൂടെ കീകൾ ലെക്സിക്കോഗ്രാഫിക് ക്രമത്തിൽ ക്രമീകരിക്കുകയല്ലാതെ മറ്റ് മാർഗമില്ല. ഘടനകൾ സംഘടിപ്പിക്കുന്നതിന് ഇത് ഉപയോഗിക്കുന്നത് വെട്ടിയ കോടാലി ഉപയോഗിച്ച് ഷേവ് ചെയ്യുന്നതിന് സമാനമാണ്. എന്നിരുന്നാലും, ലളിതമായ സന്ദർഭങ്ങളിൽ ഈ രീതി സ്വീകാര്യമാണെന്ന് ഞാൻ കാണുന്നു. ബദൽ ചുവടെ വിവരിച്ചിരിക്കുന്നു, എന്നാൽ ഈ പാതയിൽ ചിതറിക്കിടക്കുന്ന രണ്ട് റേക്കുകൾ ഞാൻ ഇവിടെ ശ്രദ്ധിക്കും.

ആദ്യം ഓർമ്മിക്കേണ്ടത് പ്രാകൃത ഡാറ്റാ തരങ്ങളുടെ മെമ്മറി പ്രാതിനിധ്യമാണ്. അങ്ങനെ, എല്ലാ Apple ഉപകരണങ്ങളിലും, പൂർണ്ണസംഖ്യ വേരിയബിളുകൾ ഫോർമാറ്റിൽ സൂക്ഷിക്കുന്നു ലിറ്റിൽ എൻ‌ഡിയൻ. ഇതിനർത്ഥം ഏറ്റവും കുറഞ്ഞ പ്രാധാന്യമുള്ള ബൈറ്റ് ഇടതുവശത്തായിരിക്കും, കൂടാതെ ബൈറ്റ്-ബൈ-ബൈറ്റ് താരതമ്യം ഉപയോഗിച്ച് പൂർണ്ണസംഖ്യകൾ അടുക്കാൻ കഴിയില്ല. ഉദാഹരണത്തിന്, 0 മുതൽ 511 വരെയുള്ള ഒരു കൂട്ടം സംഖ്യകൾ ഉപയോഗിച്ച് ഇത് ചെയ്യാൻ ശ്രമിക്കുന്നത് ഇനിപ്പറയുന്ന ഫലം നൽകും.

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

ഈ പ്രശ്നം പരിഹരിക്കാൻ, ബൈറ്റ്-ബൈറ്റ് കംപാറേറ്ററിന് അനുയോജ്യമായ ഫോർമാറ്റിൽ പൂർണ്ണസംഖ്യകൾ കീയിൽ സൂക്ഷിക്കണം. കുടുംബത്തിൽ നിന്നുള്ള പ്രവർത്തനങ്ങൾ ആവശ്യമായ പരിവർത്തനം നടത്താൻ നിങ്ങളെ സഹായിക്കും hton* (പ്രത്യേകിച്ച് htons ഉദാഹരണത്തിൽ നിന്നുള്ള ഇരട്ട-ബൈറ്റ് നമ്പറുകൾക്കായി).

പ്രോഗ്രാമിംഗിലെ സ്ട്രിംഗുകളെ പ്രതിനിധീകരിക്കുന്നതിനുള്ള ഫോർമാറ്റ്, നിങ്ങൾക്കറിയാവുന്നതുപോലെ, മൊത്തത്തിലുള്ളതാണ് ചരിത്രം. സ്‌ട്രിംഗുകളുടെ സെമാൻ്റിക്‌സും മെമ്മറിയിൽ അവയെ പ്രതിനിധീകരിക്കാൻ ഉപയോഗിക്കുന്ന എൻകോഡിംഗും ഒരു പ്രതീകത്തിന് ഒന്നിൽ കൂടുതൽ ബൈറ്റുകൾ ഉണ്ടായിരിക്കാമെന്ന് സൂചിപ്പിക്കുന്നുവെങ്കിൽ, ഒരു ഡിഫോൾട്ട് കംപാറേറ്റർ ഉപയോഗിക്കുന്ന ആശയം ഉടനടി ഉപേക്ഷിക്കുന്നതാണ് നല്ലത്.

മനസ്സിൽ സൂക്ഷിക്കേണ്ട രണ്ടാമത്തെ കാര്യം വിന്യാസ തത്വങ്ങൾ ഘടന ഫീൽഡ് കംപൈലർ. അവ കാരണം, ഫീൽഡുകൾക്കിടയിലുള്ള മെമ്മറിയിൽ മാലിന്യ മൂല്യങ്ങളുള്ള ബൈറ്റുകൾ രൂപീകരിക്കാൻ കഴിയും, ഇത് തീർച്ചയായും ബൈറ്റ്-ബൈറ്റ് സോർട്ടിംഗിനെ തകർക്കുന്നു. മാലിന്യം ഇല്ലാതാക്കാൻ, ഒന്നുകിൽ നിങ്ങൾ ഫീൽഡുകൾ കർശനമായി നിർവചിച്ച ക്രമത്തിൽ പ്രഖ്യാപിക്കേണ്ടതുണ്ട്, വിന്യാസ നിയമങ്ങൾ മനസ്സിൽ വയ്ക്കുക അല്ലെങ്കിൽ ഘടനാ പ്രഖ്യാപനത്തിലെ ആട്രിബ്യൂട്ട് ഉപയോഗിക്കുക packed.

ഒരു ബാഹ്യ താരതമ്യം ഉപയോഗിച്ച് കീകൾ ഓർഡർ ചെയ്യുന്നു

ഒരു ബൈനറി താരതമ്യത്തിന് കീ താരതമ്യ യുക്തി വളരെ സങ്കീർണ്ണമായേക്കാം. ഘടനകൾക്കുള്ളിലെ സാങ്കേതിക മേഖലകളുടെ സാന്നിധ്യമാണ് പല കാരണങ്ങളിലൊന്ന്. നമുക്ക് ഇതിനകം പരിചിതമായ ഒരു ഡയറക്‌ടറി ഘടകത്തിനായുള്ള ഒരു കീയുടെ ഉദാഹരണം ഉപയോഗിച്ച് അവരുടെ സംഭവം ഞാൻ ചിത്രീകരിക്കും.

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

ലാളിത്യം ഉണ്ടായിരുന്നിട്ടും, മിക്ക കേസുകളിലും ഇത് വളരെയധികം മെമ്മറി ഉപയോഗിക്കുന്നു. പേരിൻ്റെ ബഫർ 256 ബൈറ്റുകൾ എടുക്കുന്നു, എന്നിരുന്നാലും ശരാശരി ഫയലുകളുടെയും ഫോൾഡറിൻ്റെയും പേരുകൾ അപൂർവ്വമായി 20-30 പ്രതീകങ്ങൾ കവിയുന്നു.

ഒരു റെക്കോർഡിൻ്റെ വലുപ്പം ഒപ്റ്റിമൈസ് ചെയ്യുന്നതിനുള്ള സ്റ്റാൻഡേർഡ് ടെക്നിക്കുകളിലൊന്ന് അത് യഥാർത്ഥ വലുപ്പത്തിലേക്ക് "ട്രിം" ചെയ്യുക എന്നതാണ്. എല്ലാ വേരിയബിൾ-ലെങ്ത് ഫീൽഡുകളുടെയും ഉള്ളടക്കങ്ങൾ ഘടനയുടെ അറ്റത്തുള്ള ഒരു ബഫറിൽ സൂക്ഷിക്കുന്നു, അവയുടെ നീളം പ്രത്യേക വേരിയബിളുകളിൽ സൂക്ഷിക്കുന്നു എന്നതാണ് ഇതിൻ്റെ സാരം. ഈ സമീപനം അനുസരിച്ച്, കീ NodeKey ഇനിപ്പറയുന്ന രീതിയിൽ രൂപാന്തരപ്പെടുന്നു.

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

കൂടാതെ, സീരിയലൈസ് ചെയ്യുമ്പോൾ, ഡാറ്റ വലുപ്പം വ്യക്തമാക്കിയിട്ടില്ല sizeof മുഴുവൻ ഘടനയും, എല്ലാ ഫീൽഡുകളുടെയും വലുപ്പം ഒരു നിശ്ചിത നീളവും ബഫറിൻ്റെ യഥാർത്ഥത്തിൽ ഉപയോഗിക്കുന്ന ഭാഗത്തിൻ്റെ വലുപ്പവുമാണ്.

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

റീഫാക്‌ടറിംഗിൻ്റെ ഫലമായി, കീകൾ കൈവശപ്പെടുത്തിയ സ്ഥലത്ത് ഞങ്ങൾക്ക് കാര്യമായ ലാഭം ലഭിച്ചു. എന്നിരുന്നാലും, സാങ്കേതിക മേഖല കാരണം nameLength, ഡിഫോൾട്ട് ബൈനറി കംപാറേറ്റർ ഇനി കീ താരതമ്യത്തിന് അനുയോജ്യമല്ല. നാമത് നമ്മുടേതായി മാറ്റിസ്ഥാപിക്കുന്നില്ലെങ്കിൽ, പേരിൻ്റെ ദൈർഘ്യം പേരിനേക്കാൾ കൂടുതൽ മുൻഗണനാ ഘടകമായിരിക്കും.

ഓരോ ഡാറ്റാബേസിനും അതിൻ്റേതായ കീ താരതമ്യ ഫംഗ്‌ഷൻ ഉണ്ടായിരിക്കാൻ 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 // ...
}

ഡാറ്റാബേസിലെ എല്ലാ കീകളും ഒരേ തരത്തിലുള്ളതാണെങ്കിൽ, അവയുടെ ബൈറ്റ് പ്രാതിനിധ്യം ആപ്ലിക്കേഷൻ കീ ഘടനയുടെ തരത്തിലേക്ക് നിരുപാധികം കാസ്റ്റുചെയ്യുന്നത് നിയമപരമാണ്. ഇവിടെ ഒരു ന്യൂനൻസ് ഉണ്ട്, എന്നാൽ അത് "റീഡിംഗ് റെക്കോർഡ്സ്" ഉപവിഭാഗത്തിൽ താഴെ ചർച്ച ചെയ്യും.

മൂല്യങ്ങൾ ക്രമപ്പെടുത്തുന്നു

സൂക്ഷിച്ചിരിക്കുന്ന രേഖകളുടെ കീകൾ ഉപയോഗിച്ച് എൽഎംഡിബി വളരെ തീവ്രമായി പ്രവർത്തിക്കുന്നു. അവ പരസ്പരം താരതമ്യം ചെയ്യുന്നത് ഏതെങ്കിലും പ്രയോഗിച്ച പ്രവർത്തനത്തിൻ്റെ ചട്ടക്കൂടിനുള്ളിൽ സംഭവിക്കുന്നു, കൂടാതെ മുഴുവൻ പരിഹാരത്തിൻ്റെയും പ്രകടനം താരതമ്യത്തിൻ്റെ വേഗതയെ ആശ്രയിച്ചിരിക്കുന്നു. ഒരു അനുയോജ്യമായ ലോകത്ത്, കീകൾ താരതമ്യം ചെയ്യാൻ സ്ഥിരസ്ഥിതി ബൈനറി താരതമ്യപ്പെടുത്തൽ മതിയാകും, എന്നാൽ നിങ്ങളുടേത് ഉപയോഗിക്കണമെങ്കിൽ, അതിലെ കീകൾ ഡീസിയലൈസ് ചെയ്യുന്നതിനുള്ള നടപടിക്രമം കഴിയുന്നത്ര വേഗത്തിലായിരിക്കണം.

റെക്കോർഡിൻ്റെ (മൂല്യം) മൂല്യ ഭാഗത്ത് ഡാറ്റാബേസിന് പ്രത്യേക താൽപ്പര്യമില്ല. ഒരു ബൈറ്റ് പ്രാതിനിധ്യത്തിൽ നിന്ന് ഒരു ഒബ്‌ജക്റ്റിലേക്കുള്ള അതിൻ്റെ പരിവർത്തനം സംഭവിക്കുന്നത് ആപ്ലിക്കേഷൻ കോഡിന് ഇതിനകം ആവശ്യമുള്ളപ്പോൾ മാത്രമാണ്, ഉദാഹരണത്തിന്, അത് സ്ക്രീനിൽ പ്രദർശിപ്പിക്കുന്നതിന്. ഇത് താരതമ്യേന അപൂർവ്വമായി സംഭവിക്കുന്നതിനാൽ, ഈ നടപടിക്രമത്തിനുള്ള വേഗത ആവശ്യകതകൾ അത്ര നിർണായകമല്ല, മാത്രമല്ല ഇത് നടപ്പിലാക്കുന്നതിൽ നമുക്ക് സൗകര്യങ്ങളിൽ ശ്രദ്ധ കേന്ദ്രീകരിക്കാൻ കൂടുതൽ സ്വാതന്ത്ര്യമുണ്ട്.ഉദാഹരണത്തിന്, ഇതുവരെ ഡൗൺലോഡ് ചെയ്യാത്ത ഫയലുകളെക്കുറിച്ചുള്ള മെറ്റാഡാറ്റ സീരിയലൈസ് ചെയ്യാൻ ഞങ്ങൾ ഉപയോഗിക്കുന്നു. 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 ലഭിക്കുന്നു. സമീപനത്തിൻ്റെ എല്ലാ സൗന്ദര്യവും ഉണ്ടായിരുന്നിട്ടും, അതുമായി ബന്ധപ്പെട്ട നിരവധി സവിശേഷതകൾ ഓർമ്മിക്കേണ്ടത് ആവശ്യമാണ്.

വായിക്കാൻ മാത്രമുള്ള ഇടപാടിന്, ഇടപാട് അവസാനിപ്പിക്കുന്നത് വരെ മൂല്യ ഘടനയിലേക്കുള്ള പോയിൻ്റർ സാധുവായി തുടരുമെന്ന് ഉറപ്പുനൽകുന്നു. നേരത്തെ സൂചിപ്പിച്ചതുപോലെ, ഒരു ഒബ്‌ജക്‌റ്റ് സ്ഥിതിചെയ്യുന്ന ബി-ട്രീ പേജുകൾ, കോപ്പി-ഓൺ-റൈറ്റ് തത്വത്തിന് നന്ദി, കുറഞ്ഞത് ഒരു ഇടപാടിലൂടെയെങ്കിലും അവ പരാമർശിക്കപ്പെടുന്നിടത്തോളം മാറ്റമില്ലാതെ തുടരും. അതേ സമയം, അവയുമായി ബന്ധപ്പെട്ട അവസാന ഇടപാട് പൂർത്തിയാകുമ്പോൾ, പുതിയ ഡാറ്റയ്ക്കായി പേജുകൾ വീണ്ടും ഉപയോഗിക്കാനാകും. വസ്തുക്കൾ സൃഷ്ടിച്ച ഇടപാടിനെ അതിജീവിക്കാൻ അത് ആവശ്യമാണെങ്കിൽ, അവ ഇപ്പോഴും പകർത്തേണ്ടതുണ്ട്.
ഒരു റീഡ്‌റൈറ്റ് ഇടപാടിന്, ഫലമായുണ്ടാകുന്ന മൂല്യ ഘടനയിലേക്കുള്ള പോയിൻ്റർ ആദ്യത്തെ പരിഷ്‌ക്കരണ നടപടിക്രമം വരെ മാത്രമേ സാധുതയുള്ളൂ (ഡാറ്റ എഴുതുകയോ ഇല്ലാതാക്കുകയോ ചെയ്യുക).
ഘടന ആണെങ്കിലും NodeValue പൂർണ്ണമായതല്ല, മറിച്ച് ട്രിം ചെയ്‌തിരിക്കുന്നു (“ഒരു ബാഹ്യ താരതമ്യപ്പെടുത്തൽ ഉപയോഗിച്ച് കീകൾ ഓർഡർ ചെയ്യുന്നു” എന്ന ഉപവിഭാഗം കാണുക), പോയിൻ്ററിലൂടെ നിങ്ങൾക്ക് സുരക്ഷിതമായി അതിൻ്റെ ഫീൽഡുകൾ ആക്‌സസ് ചെയ്യാൻ കഴിയും. പ്രധാന കാര്യം അത് ഒഴിവാക്കരുത് എന്നതാണ്!
ഒരു സാഹചര്യത്തിലും സ്വീകരിച്ച പോയിൻ്ററിലൂടെ ഘടനയിൽ മാറ്റം വരുത്തരുത്. എല്ലാ മാറ്റങ്ങളും രീതിയിലൂടെ മാത്രമേ വരുത്താവൂ mdb_put. എന്നിരുന്നാലും, നിങ്ങൾ ഇത് ചെയ്യാൻ എത്ര കഠിനമായി ആഗ്രഹിച്ചാലും, ഇത് സാധ്യമല്ല, കാരണം ഈ ഘടന സ്ഥിതിചെയ്യുന്ന മെമ്മറി ഏരിയ റീഡൺലി മോഡിൽ മാപ്പ് ചെയ്തിരിക്കുന്നു.
ഫംഗ്ഷൻ ഉപയോഗിച്ച് പരമാവധി സംഭരണ വലുപ്പം വർദ്ധിപ്പിക്കുന്നതിന്, ഉദാഹരണത്തിന്, പ്രോസസ്സ് വിലാസ സ്ഥലത്തേക്ക് ഒരു ഫയൽ റീമാപ്പ് ചെയ്യുക 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 വ്യക്തമായ പോരായ്മകളുണ്ട്:

ലീനിയർ സെർച്ച് കോംപ്ലക്‌സിറ്റി, അറിയപ്പെടുന്നത് പോലെ, മരങ്ങളിൽ പൊതുവെയും ബി-ട്രീയിൽ പ്രത്യേകിച്ചും അത് ലോഗരിഥമിക് സമയത്ത് നടപ്പിലാക്കാൻ കഴിയും.
വ്യർത്ഥമായി, തിരയുന്ന പേജിന് മുമ്പുള്ള എല്ലാ പേജുകളും ഫയലിൽ നിന്ന് പ്രധാന മെമ്മറിയിലേക്ക് ഉയർത്തുന്നു, അത് വളരെ ചെലവേറിയതാണ്.

ഭാഗ്യവശാൽ, 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 പട്ടികകൾ തമ്മിലുള്ള മോഡലിംഗ് ബന്ധങ്ങൾ

ഇപ്പോൾ, ഒരു സിംഗിൾ-ടേബിൾ ഡാറ്റാബേസ് രൂപകൽപ്പന ചെയ്യുന്നതിനും പ്രവർത്തിക്കുന്നതിനുമുള്ള എല്ലാ വശങ്ങളും പരിഗണിക്കാൻ ഞങ്ങൾക്ക് കഴിഞ്ഞു. ഒരേ തരത്തിലുള്ള കീ-വാല്യൂ ജോഡികൾ അടങ്ങുന്ന അടുക്കിയ റെക്കോർഡുകളുടെ ഒരു കൂട്ടമാണ് പട്ടിക എന്ന് നമുക്ക് പറയാം. നിങ്ങൾ ഒരു കീ ഒരു ദീർഘചതുരായും അനുബന്ധ മൂല്യം ഒരു സമാന്തര പൈപ്പ് ആയും പ്രദർശിപ്പിക്കുകയാണെങ്കിൽ, നിങ്ങൾക്ക് ഡാറ്റാബേസിൻ്റെ ഒരു വിഷ്വൽ ഡയഗ്രം ലഭിക്കും.

മയക്കുമരുന്ന്

എന്നിരുന്നാലും, യഥാർത്ഥ ജീവിതത്തിൽ വളരെ കുറച്ച് രക്തച്ചൊരിച്ചിലിലൂടെ അത് അപൂർവ്വമായി മാത്രമേ സാധ്യമാകൂ. പലപ്പോഴും ഒരു ഡാറ്റാബേസിൽ അത് ആവശ്യമാണ്, ഒന്നാമതായി, നിരവധി പട്ടികകൾ ഉണ്ടായിരിക്കണം, രണ്ടാമതായി, പ്രാഥമിക കീയിൽ നിന്ന് വ്യത്യസ്തമായ ക്രമത്തിൽ അവയിൽ തിരഞ്ഞെടുക്കലുകൾ നടത്തണം. ഈ അവസാന ഭാഗം അവയുടെ സൃഷ്ടിയുടെയും പരസ്പര ബന്ധത്തിൻ്റെയും പ്രശ്നങ്ങൾക്കായി നീക്കിവച്ചിരിക്കുന്നു.

സൂചിക പട്ടികകൾ

ക്ലൗഡ് ആപ്ലിക്കേഷന് ഒരു "ഗാലറി" വിഭാഗമുണ്ട്. തീയതി പ്രകാരം അടുക്കിയ മുഴുവൻ ക്ലൗഡിൽ നിന്നുമുള്ള മീഡിയ ഉള്ളടക്കം ഇത് പ്രദർശിപ്പിക്കുന്നു. അത്തരമൊരു തിരഞ്ഞെടുപ്പ് ഒപ്റ്റിമൽ നടപ്പിലാക്കാൻ, പ്രധാന പട്ടികയ്ക്ക് അടുത്തായി നിങ്ങൾ ഒരു പുതിയ തരം കീകൾ ഉപയോഗിച്ച് മറ്റൊന്ന് സൃഷ്ടിക്കേണ്ടതുണ്ട്. ഫയൽ സൃഷ്ടിച്ച തീയതിയുള്ള ഒരു ഫീൽഡ് അവയിൽ അടങ്ങിയിരിക്കും, അത് പ്രാഥമിക സോർട്ടിംഗ് മാനദണ്ഡമായി പ്രവർത്തിക്കും. പുതിയ കീകൾ പ്രധാന പട്ടികയിലെ കീകളുടെ അതേ ഡാറ്റയെ പരാമർശിക്കുന്നതിനാൽ, അവയെ സൂചിക കീകൾ എന്ന് വിളിക്കുന്നു. ചുവടെയുള്ള ചിത്രത്തിൽ അവ ഓറഞ്ചിൽ ഹൈലൈറ്റ് ചെയ്തിരിക്കുന്നു.

ഒരേ ഡാറ്റാബേസിൽ നിന്ന് വ്യത്യസ്ത പട്ടികകളുടെ കീകൾ പരസ്പരം വേർതിരിക്കുന്നതിന്, അവയിലെല്ലാം ഒരു അധിക സാങ്കേതിക ഫീൽഡ് ടേബിൾ ഐഡി ചേർത്തു. അടുക്കുന്നതിനുള്ള ഏറ്റവും ഉയർന്ന മുൻഗണന നൽകുന്നതിലൂടെ, ഞങ്ങൾ ആദ്യം പട്ടികകൾ വഴിയും പട്ടികകൾക്കുള്ളിൽ - ഞങ്ങളുടെ സ്വന്തം നിയമങ്ങൾക്കനുസരിച്ച് കീകളുടെ ഗ്രൂപ്പിംഗ് നേടും.

ഇൻഡെക്സ് കീ പ്രാഥമിക കീയുടെ അതേ ഡാറ്റയെ പരാമർശിക്കുന്നു. പ്രൈമറി കീയുടെ മൂല്യ ഭാഗത്തിൻ്റെ ഒരു പകർപ്പ് ഇതുമായി ബന്ധപ്പെടുത്തുന്നതിലൂടെ ഈ പ്രോപ്പർട്ടി നേരിട്ട് നടപ്പിലാക്കുന്നത് പല വീക്ഷണകോണുകളിൽ നിന്നും അനുയോജ്യമല്ല:

എടുത്ത സ്ഥലത്തിൻ്റെ കാര്യത്തിൽ, മെറ്റാഡാറ്റ വളരെ സമ്പന്നമായിരിക്കും.
ഒരു പ്രകടന വീക്ഷണകോണിൽ നിന്ന്, ഒരു നോഡിൻ്റെ മെറ്റാഡാറ്റ അപ്ഡേറ്റ് ചെയ്യുമ്പോൾ, രണ്ട് കീകൾ ഉപയോഗിച്ച് നിങ്ങൾ അത് വീണ്ടും എഴുതേണ്ടതുണ്ട്.
കോഡ് പിന്തുണയുടെ വീക്ഷണകോണിൽ നിന്ന്, ഒരു കീയുടെ ഡാറ്റ അപ്‌ഡേറ്റ് ചെയ്യാൻ ഞങ്ങൾ മറന്നാൽ, സംഭരണത്തിലെ ഡാറ്റാ പൊരുത്തക്കേടിൻ്റെ ഒരു അവ്യക്തമായ ബഗ് നമുക്ക് ലഭിക്കും.

അടുത്തതായി, ഈ കുറവുകൾ എങ്ങനെ ഇല്ലാതാക്കാമെന്ന് ഞങ്ങൾ പരിഗണിക്കും.

പട്ടികകൾ തമ്മിലുള്ള ബന്ധങ്ങൾ സംഘടിപ്പിക്കുക

സൂചിക പട്ടികയെ പ്രധാന പട്ടികയുമായി ബന്ധിപ്പിക്കുന്നതിന് പാറ്റേൺ അനുയോജ്യമാണ് "മൂല്യമായി താക്കോൽ". അതിൻ്റെ പേര് സൂചിപ്പിക്കുന്നത് പോലെ, സൂചിക റെക്കോർഡിൻ്റെ മൂല്യ ഭാഗം പ്രാഥമിക കീ മൂല്യത്തിൻ്റെ ഒരു പകർപ്പാണ്. ഈ സമീപനം പ്രാഥമിക റെക്കോർഡിൻ്റെ മൂല്യ ഭാഗത്തിൻ്റെ ഒരു പകർപ്പ് സംഭരിക്കുന്നതുമായി ബന്ധപ്പെട്ട മുകളിൽ സൂചിപ്പിച്ച എല്ലാ ദോഷങ്ങളും ഇല്ലാതാക്കുന്നു. ഇൻഡെക്സ് കീ ഉപയോഗിച്ച് ഒരു മൂല്യം ലഭിക്കുന്നതിന്, നിങ്ങൾ ഡാറ്റാബേസിലേക്ക് ഒന്നിന് പകരം 2 അന്വേഷണങ്ങൾ നടത്തേണ്ടതുണ്ട് എന്നതാണ് ഏക ചെലവ്. സ്കീമാറ്റിക്കായി, തത്ഫലമായുണ്ടാകുന്ന ഡാറ്റാബേസ് സ്കീമ ഇതുപോലെ കാണപ്പെടുന്നു.

പട്ടികകൾ തമ്മിലുള്ള ബന്ധങ്ങൾ സംഘടിപ്പിക്കുന്നതിനുള്ള മറ്റൊരു മാതൃകയാണ് "അനവധി കീ". കീയിലേക്ക് അധിക ആട്രിബ്യൂട്ടുകൾ ചേർക്കുക എന്നതാണ് ഇതിൻ്റെ സാരാംശം, അവ സോർട്ടിംഗിനല്ല, അനുബന്ധ കീ പുനർനിർമ്മിക്കുന്നതിന് ആവശ്യമാണ്. Mail.ru ക്ലൗഡ് ആപ്ലിക്കേഷനിൽ അതിൻ്റെ ഉപയോഗത്തിൻ്റെ യഥാർത്ഥ ഉദാഹരണങ്ങളുണ്ട്, എന്നിരുന്നാലും, ആഴത്തിലുള്ള ഡൈവ് ഒഴിവാക്കാൻ നിർദ്ദിഷ്ട iOS ചട്ടക്കൂടുകളുടെ സന്ദർഭം, ഞാൻ ഒരു സാങ്കൽപ്പികവും എന്നാൽ വ്യക്തമായതുമായ ഒരു ഉദാഹരണം നൽകും

ക്ലൗഡ് മൊബൈൽ ക്ലയൻ്റുകൾക്ക് ഉപയോക്താവ് മറ്റ് ആളുകളുമായി പങ്കിട്ട എല്ലാ ഫയലുകളും ഫോൾഡറുകളും പ്രദർശിപ്പിക്കുന്ന ഒരു പേജ് ഉണ്ട്. അത്തരം ഫയലുകൾ താരതമ്യേന കുറവായതിനാലും അവയുമായി ബന്ധപ്പെട്ട പബ്ലിസിറ്റിയെക്കുറിച്ചുള്ള വിവിധ തരത്തിലുള്ള പ്രത്യേക വിവരങ്ങൾ ഉള്ളതിനാലും (ആർക്കൊക്കെ ആക്‌സസ്സ് അനുവദിച്ചിരിക്കുന്നു, എന്ത് അവകാശങ്ങൾ മുതലായവ) മൂല്യത്തിൻ്റെ ഭാഗത്തെ ഭാരപ്പെടുത്തുന്നത് യുക്തിസഹമല്ല. അതിനൊപ്പം പ്രധാന പട്ടികയിൽ രേഖപ്പെടുത്തുക. എന്നിരുന്നാലും, അത്തരം ഫയലുകൾ ഓഫ്‌ലൈനിൽ പ്രദർശിപ്പിക്കണമെങ്കിൽ, നിങ്ങൾ അത് ഇപ്പോഴും എവിടെയെങ്കിലും സൂക്ഷിക്കേണ്ടതുണ്ട്. അതിനായി ഒരു പ്രത്യേക ടേബിൾ ഉണ്ടാക്കുക എന്നതാണ് പ്രകൃതിദത്ത പരിഹാരം. ചുവടെയുള്ള ഡയഗ്രാമിൽ, അതിൻ്റെ കീ "P" എന്ന് പ്രിഫിക്‌സ് ചെയ്‌തിരിക്കുന്നു, കൂടാതെ പ്ലെയ്‌സ്‌ഹോൾഡർ "പ്രൊപ്‌നെയിം" മാറ്റി പകരം "പബ്ലിക് ഇൻഫോ" എന്ന കൂടുതൽ പ്രത്യേക മൂല്യം നൽകാം.

എല്ലാ അദ്വിതീയ മെറ്റാഡാറ്റയും, പുതിയ പട്ടിക സൃഷ്ടിച്ച സംഭരിക്കുന്നതിനായി, റെക്കോർഡിൻ്റെ മൂല്യ ഭാഗത്ത് സ്ഥാപിച്ചിരിക്കുന്നു. അതേ സമയം, പ്രധാന പട്ടികയിൽ ഇതിനകം സംഭരിച്ചിരിക്കുന്ന ഫയലുകളെയും ഫോൾഡറുകളെയും കുറിച്ചുള്ള ഡാറ്റ തനിപ്പകർപ്പാക്കാൻ നിങ്ങൾ ആഗ്രഹിക്കുന്നില്ല. പകരം, "നോഡ് ഐഡി", "ടൈംസ്റ്റാമ്പ്" ഫീൽഡുകളുടെ രൂപത്തിൽ "പി" കീയിലേക്ക് അനാവശ്യ ഡാറ്റ ചേർക്കുന്നു. അവർക്ക് നന്ദി, നിങ്ങൾക്ക് ഒരു ഇൻഡെക്സ് കീ നിർമ്മിക്കാൻ കഴിയും, അതിൽ നിന്ന് നിങ്ങൾക്ക് ഒരു പ്രാഥമിക കീ ലഭിക്കും, അതിൽ നിന്ന്, ഒടുവിൽ, നിങ്ങൾക്ക് നോഡ് മെറ്റാഡാറ്റ ലഭിക്കും.

ഉപസംഹാരം

എൽഎംഡിബി നടപ്പിലാക്കുന്നതിൻ്റെ ഫലങ്ങൾ ഞങ്ങൾ പോസിറ്റീവായി വിലയിരുത്തുന്നു. അതിനുശേഷം, ആപ്ലിക്കേഷൻ ഫ്രീസുകളുടെ എണ്ണം 30% കുറഞ്ഞു.

ചെയ്‌ത ജോലിയുടെ ഫലങ്ങൾ iOS ടീമിനപ്പുറം പ്രതിധ്വനിച്ചു. നിലവിൽ, Android അപ്ലിക്കേഷനിലെ പ്രധാന "ഫയലുകൾ" വിഭാഗങ്ങളിലൊന്നും LMDB ഉപയോഗിക്കുന്നതിലേക്ക് മാറി, മറ്റ് ഭാഗങ്ങൾ വഴിയിലാണ്. കീ-വാല്യൂ സ്റ്റോർ നടപ്പിലാക്കിയിരിക്കുന്ന സി ഭാഷ, തുടക്കത്തിൽ C++-ൽ ക്രോസ്-പ്ലാറ്റ്‌ഫോമിന് ചുറ്റും ഒരു ആപ്ലിക്കേഷൻ ചട്ടക്കൂട് സൃഷ്ടിക്കാൻ നല്ലൊരു സഹായമായിരുന്നു. ഒബ്ജക്റ്റീവ്-സി, കോട്ലിൻ എന്നിവയിലെ പ്ലാറ്റ്ഫോം കോഡുമായി തത്ഫലമായുണ്ടാകുന്ന C++ ലൈബ്രറിയെ തടസ്സമില്ലാതെ ബന്ധിപ്പിക്കാൻ ഒരു കോഡ് ജനറേറ്റർ ഉപയോഗിച്ചു. ജിന്നി ഡ്രോപ്പ്ബോക്സിൽ നിന്ന്, പക്ഷേ അത് തികച്ചും വ്യത്യസ്തമായ ഒരു കഥയാണ്.

അവലംബം: www.habr.com

ഐഒഎസ് ആപ്ലിക്കേഷനുകളിലെ കീ-വാല്യൂ ഡാറ്റാബേസ് എൽഎംഡിബിയുടെ തിളക്കവും ദാരിദ്ര്യവും

ഉള്ളടക്കം

1. നടപ്പിലാക്കുന്നതിനുള്ള പ്രചോദനം

2. എൽഎംഡിബി പൊസിഷനിംഗ്

3. എൽഎംഡിബിയുടെ മൂന്ന് തൂണുകൾ

3.1 തിമിംഗലം #1. മെമ്മറി മാപ്പ് ചെയ്ത ഫയലുകൾ

മെമ്മറി മാപ്പ് ചെയ്ത ഫയലുകളെക്കുറിച്ചുള്ള പൊതുവായ വിവരങ്ങൾ

iOS-ലെ മെമ്മറി-മാപ്പ് ചെയ്ത ഫയലുകളുടെ പ്രത്യേകതകൾ

3.2 തിമിംഗലം #2. ബി+-മരം

3.3 തിമിംഗലം #3. കോപ്പി-ഓൺ-റൈറ്റ്

4. കീ-വാല്യൂ API-യുടെ മുകളിൽ ഒരു ഡാറ്റാ സ്കീമ രൂപകൽപ്പന ചെയ്യുന്നു

4.1. അടിസ്ഥാന സംഗ്രഹങ്ങൾ

പരിസ്ഥിതി

ഡാറ്റാബേസുകൾ

കീകളും മൂല്യങ്ങളും

ഇടപാടുകൾ

കഴ്‌സറുകൾ

4.2 ടേബിൾ മോഡലിംഗ്

ടേബിൾ സ്കീമ

കീകളും മൂല്യങ്ങളും സീരിയലൈസ് ചെയ്യുന്നു

ഒരു ബൈനറി കംപാറേറ്റർ ഉപയോഗിച്ച് കീകൾ ഓർഡർ ചെയ്യുന്നു

ഒരു ബാഹ്യ താരതമ്യം ഉപയോഗിച്ച് കീകൾ ഓർഡർ ചെയ്യുന്നു

മൂല്യങ്ങൾ ക്രമപ്പെടുത്തുന്നു

രേഖകൾ ചേർക്കുന്നതും അപ്ഡേറ്റ് ചെയ്യുന്നതും

എൻട്രികൾ വായിക്കുന്നു

റേഞ്ച് ചോദ്യങ്ങൾ

4.3 പട്ടികകൾ തമ്മിലുള്ള മോഡലിംഗ് ബന്ധങ്ങൾ

സൂചിക പട്ടികകൾ

പട്ടികകൾ തമ്മിലുള്ള ബന്ധങ്ങൾ സംഘടിപ്പിക്കുക

ഉപസംഹാരം

ഒരു അഭിപ്രായം ചേർക്കുക

ഐഒഎസ് ആപ്ലിക്കേഷനുകളിലെ കീ-വാല്യൂ ഡാറ്റാബേസ് എൽഎംഡിബിയുടെ തിളക്കവും ദാരിദ്ര്യവും

ഉള്ളടക്കം

1. നടപ്പിലാക്കുന്നതിനുള്ള പ്രചോദനം

2. എൽഎംഡിബി പൊസിഷനിംഗ്

3. എൽഎംഡിബിയുടെ മൂന്ന് തൂണുകൾ

3.1 തിമിംഗലം #1. മെമ്മറി മാപ്പ് ചെയ്ത ഫയലുകൾ

മെമ്മറി മാപ്പ് ചെയ്ത ഫയലുകളെക്കുറിച്ചുള്ള പൊതുവായ വിവരങ്ങൾ

iOS-ലെ മെമ്മറി-മാപ്പ് ചെയ്ത ഫയലുകളുടെ പ്രത്യേകതകൾ

3.2 തിമിംഗലം #2. ബി+-മരം

3.3 തിമിംഗലം #3. കോപ്പി-ഓൺ-റൈറ്റ്

4. കീ-വാല്യൂ API-യുടെ മുകളിൽ ഒരു ഡാറ്റാ സ്കീമ രൂപകൽപ്പന ചെയ്യുന്നു

4.1. അടിസ്ഥാന സംഗ്രഹങ്ങൾ

പരിസ്ഥിതി

ഡാറ്റാബേസുകൾ

കീകളും മൂല്യങ്ങളും

ഇടപാടുകൾ

കഴ്‌സറുകൾ

4.2 ടേബിൾ മോഡലിംഗ്

ടേബിൾ സ്കീമ

കീകളും മൂല്യങ്ങളും സീരിയലൈസ് ചെയ്യുന്നു

ഒരു ബൈനറി കംപാറേറ്റർ ഉപയോഗിച്ച് കീകൾ ഓർഡർ ചെയ്യുന്നു

ഒരു ബാഹ്യ താരതമ്യം ഉപയോഗിച്ച് കീകൾ ഓർഡർ ചെയ്യുന്നു

മൂല്യങ്ങൾ ക്രമപ്പെടുത്തുന്നു

രേഖകൾ ചേർക്കുന്നതും അപ്ഡേറ്റ് ചെയ്യുന്നതും

എൻട്രികൾ വായിക്കുന്നു

റേഞ്ച് ചോദ്യങ്ങൾ

4.3 പട്ടികകൾ തമ്മിലുള്ള മോഡലിംഗ് ബന്ധങ്ങൾ

സൂചിക പട്ടികകൾ

പട്ടികകൾ തമ്മിലുള്ള ബന്ധങ്ങൾ സംഘടിപ്പിക്കുക

ഉപസംഹാരം

ഒരു അഭിപ്രായം ചേർക്കുക മറുപടി റദ്ദാക്കാൻ

ഒരു അഭിപ്രായം ചേർക്കുക