2019 ના પાનખરમાં, Mail.ru ક્લાઉડ iOS ટીમમાં લાંબા સમયથી રાહ જોવાતી ઘટના બની. એપ્લિકેશન સ્ટેટના સતત સ્ટોરેજ માટેનો મુખ્ય ડેટાબેઝ મોબાઇલ વિશ્વ માટે ખૂબ જ વિચિત્ર બની ગયો છે લાઈટનિંગ મેમરી-મેપ્ડ ડેટાબેઝ (LMDB). કટની નીચે અમે તમને ચાર ભાગોમાં તેની વિગતવાર સમીક્ષા ઓફર કરીએ છીએ. પ્રથમ, ચાલો આવી બિન-તુચ્છ અને મુશ્કેલ પસંદગીના કારણો વિશે વાત કરીએ. પછી અમે LMDB આર્કિટેક્ચરના હાર્દમાં ત્રણ સ્તંભોને ધ્યાનમાં લેવા આગળ વધીશું: મેમરી-મેપ કરેલી ફાઇલો, B+-ટ્રી, વ્યવહાર અને મલ્ટિવર્ઝન અમલીકરણ માટે કૉપિ-ઑન-રાઇટ અભિગમ. અંતે, ડેઝર્ટ માટે - વ્યવહારુ ભાગ. તેમાં આપણે નીચા-સ્તરના કી-વેલ્યુ APIની ટોચ પર, ઇન્ડેક્સ એક સહિત અનેક કોષ્ટકો સાથે ડેટાબેઝ સ્કીમા કેવી રીતે ડિઝાઇન અને અમલમાં મૂકવી તે જોઈશું.

અનુક્રમણિકા

અમલીકરણ માટે પ્રેરણા
LMDB પોઝિશનિંગ
LMDB ના ત્રણ સ્તંભો
3.1. વ્હેલ #1. મેમરી-મેપ કરેલી ફાઇલો
3.2. વ્હેલ #2. B+-વૃક્ષ
3.3. વ્હેલ #3. કોપી-ઓન-રાઈટ
કી-વેલ્યુ API ની ટોચ પર ડેટા સ્કીમા ડિઝાઇન કરવી
4.1. મૂળભૂત એબ્સ્ટ્રેક્શન્સ
4.2. ટેબલ મોડેલિંગ
4.3. કોષ્ટકો વચ્ચે મોડેલિંગ સંબંધો

1. અમલીકરણ માટે પ્રેરણા

2015 માં એક વર્ષ, અમે અમારી એપ્લિકેશનનું ઇન્ટરફેસ કેટલી વાર લેગ થાય છે તે માપવા માટે મુશ્કેલી લીધી. અમે એક કારણસર આ કર્યું. અમને વધુ વારંવાર ફરિયાદો મળી છે કે કેટલીકવાર એપ્લિકેશન વપરાશકર્તાની ક્રિયાઓને પ્રતિસાદ આપવાનું બંધ કરે છે: બટનો દબાવી શકાતા નથી, સૂચિઓ સ્ક્રોલ થતી નથી, વગેરે. માપના મિકેનિક્સ વિશે કહ્યું એવિટોટેક પર, તેથી અહીં હું ફક્ત સંખ્યાઓનો ક્રમ આપું છું.

માપનના પરિણામો અમારા માટે ઠંડા ફુવારો બન્યા. તે બહાર આવ્યું છે કે અન્ય કોઈપણ કરતાં ફ્રીઝને કારણે ઘણી વધુ સમસ્યાઓ છે. જો આ હકીકતને સમજતા પહેલા ગુણવત્તાનું મુખ્ય તકનીકી સૂચક ક્રેશ ફ્રી હતું, તો પછી ધ્યાન કેન્દ્રિત કર્યા પછી સ્થળાંતર કર્યું ફ્રીઝ ફ્રી પર.

બાંધ્યા ફ્રીઝ સાથે ડેશબોર્ડ અને ખર્ચ કર્યા પછી માત્રાત્મક и ગુણવત્તા તેમના કારણોનું વિશ્લેષણ, મુખ્ય દુશ્મન સ્પષ્ટ થઈ ગયો - એપ્લિકેશનના મુખ્ય થ્રેડમાં ભારે બિઝનેસ લોજિક ચલાવવામાં આવ્યું. આ બદનામીની કુદરતી પ્રતિક્રિયા તેને કામના પ્રવાહમાં ધકેલી દેવાની સળગતી ઇચ્છા હતી. આ સમસ્યાને વ્યવસ્થિત રીતે ઉકેલવા માટે, અમે લાઇટવેઇટ એક્ટર્સ પર આધારિત મલ્ટિ-થ્રેડેડ આર્કિટેક્ચરનો આશરો લીધો. મેં તેને iOS વિશ્વ માટે તેના અનુકૂલન માટે સમર્પિત કર્યું બે થ્રેડો સામૂહિક ટ્વિટર પર અને હેબ્રે પરનો લેખ. વર્તમાન વર્ણનના ભાગરૂપે, હું નિર્ણયના તે પાસાઓ પર ભાર મૂકવા માંગુ છું જેણે ડેટાબેઝની પસંદગીને પ્રભાવિત કરી હતી.

સિસ્ટમ સંસ્થાના અભિનેતા મોડેલ ધારે છે કે મલ્ટિથ્રેડીંગ તેનો બીજો સાર બની જાય છે. તેમાંના મોડલ ઑબ્જેક્ટ્સ પ્રવાહની સીમાઓ પાર કરવાનું પસંદ કરે છે. અને તેઓ આ ક્યારેક અને અહીં અને ત્યાં નહીં, પરંતુ લગભગ સતત અને દરેક જગ્યાએ કરે છે

પ્રસ્તુત રેખાકૃતિમાં ડેટાબેઝ એ પાયાના ઘટકોમાંથી એક છે. તેનું મુખ્ય કાર્ય મેક્રોપેટર્નનો અમલ કરવાનું છે વહેંચાયેલ ડેટાબેઝ. જો એન્ટરપ્રાઇઝ વિશ્વમાં તેનો ઉપયોગ સેવાઓ વચ્ચે ડેટા સિંક્રનાઇઝેશનને ગોઠવવા માટે થાય છે, તો પછી અભિનેતા આર્કિટેક્ચરના કિસ્સામાં - થ્રેડો વચ્ચેનો ડેટા. આમ, અમને એવા ડેટાબેઝની જરૂર હતી કે જે બહુ-થ્રેડેડ વાતાવરણમાં તેની સાથે કામ કરતી વખતે ઓછામાં ઓછી મુશ્કેલીઓ ન સર્જે. ખાસ કરીને, આનો અર્થ એ છે કે તેમાંથી મેળવેલી વસ્તુઓ ઓછામાં ઓછી થ્રેડ-સલામત હોવી જોઈએ, અને આદર્શ રીતે સંપૂર્ણપણે બિન-પરિવર્તનશીલ હોવી જોઈએ. જેમ તમે જાણો છો, બાદમાં કોઈપણ લોકીંગનો આશરો લીધા વિના એક સાથે અનેક થ્રેડોમાંથી ઉપયોગ કરી શકાય છે, જે કામગીરી પર ફાયદાકારક અસર કરે છે.

ડેટાબેઝની પસંદગીને પ્રભાવિત કરનાર બીજું મહત્ત્વનું પરિબળ અમારું ક્લાઉડ API હતું. તે git દ્વારા અપનાવવામાં આવેલ સિંક્રનાઇઝેશન અભિગમથી પ્રેરિત હતું. તેની જેમ, અમે લક્ષ્ય રાખ્યું ઑફલાઇન-પ્રથમ API, જે ક્લાઉડ ક્લાયંટ માટે યોગ્ય કરતાં વધુ લાગે છે. એવું માનવામાં આવતું હતું કે તેઓ માત્ર એક જ વાર ક્લાઉડની સંપૂર્ણ સ્થિતિને બહાર કાઢશે, અને પછી મોટા ભાગના કિસ્સાઓમાં સિંક્રનાઇઝેશન રોલ આઉટ ફેરફારો દ્વારા થશે. અરે, આ તક હજુ પણ માત્ર સૈદ્ધાંતિક ઝોનમાં છે, અને ગ્રાહકોએ વ્યવહારમાં પેચો સાથે કેવી રીતે કામ કરવું તે શીખ્યા નથી. આના માટે ઘણા ઉદ્દેશ્ય કારણો છે, જે પરિચયમાં વિલંબ ન કરવા માટે, અમે કૌંસ પાછળ છોડીશું. હવે, જ્યારે API "A" કહે છે અને તેના ઉપભોક્તા "B" ન કહે છે ત્યારે શું થાય છે તે વિશેના પાઠના ઉપદેશક તારણો વધુ રસપ્રદ છે.

તેથી, જો તમે ગિટની કલ્પના કરો છો, જે પુલ કમાન્ડનો અમલ કરતી વખતે, સ્થાનિક સ્નેપશોટ પર પેચો લાગુ કરવાને બદલે, તેની સંપૂર્ણ સ્થિતિની સંપૂર્ણ સર્વર સ્થિતિ સાથે તુલના કરે છે, તો પછી તમને ક્લાઉડમાં સિંક્રનાઇઝેશન કેવી રીતે થાય છે તેનો એકદમ સચોટ ખ્યાલ હશે. ગ્રાહકો અનુમાન લગાવવું સરળ છે કે તેને અમલમાં મૂકવા માટે, તમારે તમામ સર્વર અને સ્થાનિક ફાઇલો વિશે મેટા-માહિતી સાથે મેમરીમાં બે DOM વૃક્ષો ફાળવવાની જરૂર છે. તે તારણ આપે છે કે જો કોઈ વપરાશકર્તા ક્લાઉડમાં 500 હજાર ફાઇલો સંગ્રહિત કરે છે, તો તેને સિંક્રનાઇઝ કરવા માટે 1 મિલિયન નોડ્સ સાથે બે વૃક્ષોને ફરીથી બનાવવા અને નાશ કરવા જરૂરી છે. પરંતુ દરેક નોડ એ એકંદર છે જેમાં સબબેક્ટ્સનો ગ્રાફ હોય છે. આ પ્રકાશમાં, પ્રોફાઇલિંગ પરિણામો અપેક્ષિત હતા. તે બહાર આવ્યું છે કે મર્જિંગ એલ્ગોરિધમને ધ્યાનમાં લીધા વિના પણ, મોટી સંખ્યામાં નાની વસ્તુઓ બનાવવાની અને પછીથી તેનો નાશ કરવાની ખૂબ જ પ્રક્રિયામાં એક સુંદર પૈસો ખર્ચ થાય છે. પરિસ્થિતિ એ હકીકત દ્વારા વણસી છે કે મૂળભૂત સિંક્રનાઇઝેશન કામગીરી મોટી સંખ્યામાં શામેલ છે. વપરાશકર્તા સ્ક્રિપ્ટો. પરિણામે, અમે ડેટાબેઝ પસંદ કરવા માટે બીજા મહત્વપૂર્ણ માપદંડને ઠીક કરીએ છીએ - ઑબ્જેક્ટ્સની ગતિશીલ ફાળવણી વિના CRUD ઑપરેશન્સ અમલમાં મૂકવાની ક્ષમતા.

અન્ય જરૂરિયાતો વધુ પરંપરાગત છે અને તેમની સંપૂર્ણ સૂચિ નીચે મુજબ છે.

થ્રેડ સલામતી.
મલ્ટિપ્રોસેસિંગ. માત્ર થ્રેડો વચ્ચે જ નહીં, પણ મુખ્ય એપ્લીકેશન અને iOS એક્સ્ટેન્શન્સ વચ્ચેની સ્થિતિને સિંક્રનાઇઝ કરવા માટે સમાન ડેટાબેઝ દાખલાનો ઉપયોગ કરવાની ઇચ્છા દ્વારા નિર્ધારિત.
સંગ્રહિત સંસ્થાઓને બિન-પરિવર્તનશીલ પદાર્થો તરીકે રજૂ કરવાની ક્ષમતા
CRUD કામગીરીમાં કોઈ ગતિશીલ ફાળવણી નથી.
મૂળભૂત મિલકતો માટે ટ્રાન્ઝેક્શન સપોર્ટ ACID: પરમાણુ, સુસંગતતા, અલગતા અને વિશ્વસનીયતા.
સૌથી વધુ લોકપ્રિય કેસો પર ઝડપ.

આવશ્યકતાઓના આ સમૂહ સાથે, SQLite સારી પસંદગી હતી અને રહે છે. જો કે, વિકલ્પોના અભ્યાસના ભાગરૂપે, મને એક પુસ્તક મળ્યું "લેવલડીબી સાથે પ્રારંભ કરવું". તેણીના નેતૃત્વ હેઠળ, વાસ્તવિક ક્લાઉડ દૃશ્યોમાં વિવિધ ડેટાબેઝ સાથે કામની ઝડપની તુલના કરવા માટે એક માપદંડ લખવામાં આવ્યો હતો. પરિણામ અમારી જંગલી અપેક્ષાઓ કરતાં વધી ગયું. સૌથી વધુ લોકપ્રિય કેસોમાં - બધી ફાઇલોની સૉર્ટ કરેલી સૂચિ પર કર્સર મેળવવું અને આપેલ ડિરેક્ટરી માટે બધી ફાઇલોની સૉર્ટ કરેલી સૂચિ - LMDB SQLite કરતાં 10 ગણી ઝડપી હોવાનું બહાર આવ્યું. પસંદગી સ્પષ્ટ થઈ ગઈ.

2. LMDB પોઝિશનિંગ

LMDB એ ખૂબ જ નાની લાઇબ્રેરી છે (માત્ર 10K પંક્તિઓ) જે ડેટાબેઝના સૌથી નીચા મૂળભૂત સ્તર - સ્ટોરેજને લાગુ કરે છે.

ઉપરોક્ત રેખાકૃતિ દર્શાવે છે કે SQLite સાથે LMDB ની સરખામણી કરવી, જે ઉચ્ચ સ્તરનો પણ અમલ કરે છે, સામાન્ય રીતે કોર ડેટા સાથે SQLite કરતાં વધુ યોગ્ય નથી. સમાન સ્પર્ધકો - બર્કલેડીબી, લેવલડીબી, સોફિયા, રોક્સડીબી, વગેરે તરીકે સમાન સ્ટોરેજ એન્જિનને ટાંકવું વધુ વાજબી રહેશે. ત્યાં પણ વિકાસ છે જ્યાં LMDB SQLite માટે સ્ટોરેજ એન્જિન ઘટક તરીકે કાર્ય કરે છે. આવો પહેલો પ્રયોગ 2012માં થયો હતો ખર્ચ કર્યો LMDB દ્વારા હોવર્ડ ચુ. રિઝલ્ટ તે એટલું રસપ્રદ બન્યું કે તેની પહેલને OSS ઉત્સાહીઓ દ્વારા પસંદ કરવામાં આવી, અને વ્યક્તિમાં તેનું સાતત્ય જોવા મળ્યું. LumoSQL. જાન્યુઆરી 2020 માં, આ પ્રોજેક્ટના લેખક ડેન શીયરર હતા પ્રસ્તુત તે LinuxConfAu પર.

LMDB નો ઉપયોગ મુખ્યત્વે એપ્લીકેશન ડેટાબેસેસ માટે એન્જીન તરીકે થાય છે. પુસ્તકાલય તેના દેખાવને વિકાસકર્તાઓને આભારી છે OpenLDAP, જેઓ તેમના પ્રોજેક્ટના આધાર તરીકે બર્કલેડીબીથી ખૂબ જ અસંતુષ્ટ હતા. સાધારણ પુસ્તકાલયથી શરૂ કરીને બીટ્રી, હોવર્ડ ચુ અમારા સમયના સૌથી લોકપ્રિય વિકલ્પોમાંથી એક બનાવવા માટે સક્ષમ હતા. તેમણે તેમનો ખૂબ જ સરસ અહેવાલ આ વાર્તા તેમજ LMDB ની આંતરિક રચનાને સમર્પિત કર્યો. "ધી લાઈટનિંગ મેમરી-મેપ્ડ ડેટાબેઝ". સંગ્રહ સુવિધા પર વિજય મેળવવાનું એક સારું ઉદાહરણ લિયોનીદ યુરીયેવ (ઉર્ફ yleo) હાઈલોડ 2015 ખાતેના તેમના અહેવાલમાં હકારાત્મક ટેક્નોલોજીસમાંથી "LMDB એન્જિન એક ખાસ ચેમ્પિયન છે". તેમાં, તે ReOpenLDAP ના અમલીકરણના સમાન કાર્યના સંદર્ભમાં LMDB વિશે વાત કરે છે, અને LevelDB પહેલેથી જ તુલનાત્મક ટીકાને પાત્ર છે. અમલીકરણના પરિણામે, સકારાત્મક ટેક્નોલોજીઓ પાસે સક્રિયપણે વિકાસશીલ કાંટો પણ હતો MDBX ખૂબ જ સ્વાદિષ્ટ સુવિધાઓ, ઑપ્ટિમાઇઝેશન અને સાથે ભૂલ સુધારાઓ.

LMDB નો ઉપયોગ મોટાભાગે સ્ટોરેજ તરીકે થાય છે. ઉદાહરણ તરીકે, મોઝિલા ફાયરફોક્સ બ્રાઉઝર પસંદ કર્યું તે સંખ્યાબંધ જરૂરિયાતો માટે, અને આવૃત્તિ 9 થી શરૂ કરીને, Xcode પસંદ અનુક્રમણિકાઓ સંગ્રહિત કરવા માટે તેનું SQLite.

મોબાઈલ ડેવલપમેન્ટની દુનિયામાં પણ એન્જિને પોતાની ઓળખ બનાવી છે. તેના ઉપયોગના નિશાન હોઈ શકે છે શોધવા માટે ટેલિગ્રામ માટે iOS ક્લાયંટમાં. LinkedIn તેનાથી પણ આગળ વધ્યું અને તેના હોમગ્રોન ડેટા કેશીંગ ફ્રેમવર્ક રોકેટ ડેટા માટે ડિફોલ્ટ સ્ટોરેજ તરીકે LMDB પસંદ કર્યું, જે વિશે કહ્યું 2016 માં તેમના લેખમાં.

એલએમડીબી ઓરેકલના નિયંત્રણ હેઠળ આવ્યા પછી બર્કલેડીબી દ્વારા છોડવામાં આવેલા વિશિષ્ટ સ્થાનમાં સૂર્યમાં સ્થાન માટે સફળતાપૂર્વક લડત આપી રહ્યું છે. પુસ્તકાલય તેની ગતિ અને વિશ્વસનીયતા માટે પ્રિય છે, તેના સાથીઓની તુલનામાં પણ. જેમ તમે જાણો છો, ત્યાં કોઈ મફત લંચ નથી, અને હું LMDB અને SQLite વચ્ચે પસંદગી કરતી વખતે તમારે જે ટ્રેડ-ઓફનો સામનો કરવો પડશે તેના પર ભાર મૂકવા માંગુ છું. ઉપરોક્ત રેખાકૃતિ સ્પષ્ટપણે દર્શાવે છે કે કેવી રીતે વધેલી ઝડપ પ્રાપ્ત થાય છે. પ્રથમ, અમે ડિસ્ક સ્ટોરેજની ટોચ પર એબ્સ્ટ્રેક્શનના વધારાના સ્તરો માટે ચૂકવણી કરતા નથી. તે સ્પષ્ટ છે કે એક સારું આર્કિટેક્ચર હજી પણ તેમના વિના કરી શકતું નથી, અને તે અનિવાર્યપણે એપ્લિકેશન કોડમાં દેખાશે, પરંતુ તે વધુ સૂક્ષ્મ હશે. તેમાં એવી વિશેષતાઓ હશે નહીં કે જે ચોક્કસ એપ્લિકેશન માટે જરૂરી નથી, ઉદાહરણ તરીકે, SQL ભાષામાં પ્રશ્નો માટે સમર્થન. બીજું, ડિસ્ક સ્ટોરેજની વિનંતીઓ પર એપ્લિકેશન ઓપરેશન્સના મેપિંગને શ્રેષ્ઠ રીતે અમલમાં મૂકવું શક્ય બને છે. જો SQLite મારા કામમાં સરેરાશ એપ્લિકેશનની સરેરાશ આંકડાકીય જરૂરિયાતો પર આધારિત છે, તો પછી તમે, એપ્લિકેશન ડેવલપર તરીકે, મુખ્ય વર્કલોડ દૃશ્યોથી સારી રીતે વાકેફ છો. વધુ ઉત્પાદક સોલ્યુશન માટે, તમારે પ્રારંભિક સોલ્યુશનના વિકાસ માટે અને તેના અનુગામી સપોર્ટ બંને માટે વધેલી કિંમત ચૂકવવી પડશે.

3. LMDB ના ત્રણ થાંભલા

એલએમડીબીને પક્ષીની આંખથી જોયા પછી, વધુ ઊંડા જવાનો સમય હતો. આગલા ત્રણ વિભાગો મુખ્ય સ્તંભોના વિશ્લેષણ માટે સમર્પિત કરવામાં આવશે જેના પર સ્ટોરેજ આર્કિટેક્ચર છે:

ડિસ્ક સાથે કામ કરવા અને આંતરિક ડેટા સ્ટ્રક્ચરને સિંક્રનાઇઝ કરવા માટેની પદ્ધતિ તરીકે મેમરી-મેપ કરેલી ફાઇલો.
સંગ્રહિત ડેટાના માળખાના સંગઠન તરીકે B+-ટ્રી.
ACID ટ્રાન્ઝેક્શન પ્રોપર્ટીઝ અને મલ્ટીવર્ઝન પ્રદાન કરવાના અભિગમ તરીકે કૉપિ-ઑન-રાઇટ.

3.1. વ્હેલ #1. મેમરી-મેપ કરેલી ફાઇલો

મેમરી-મેપ કરેલી ફાઇલો એ એક મહત્વપૂર્ણ આર્કિટેક્ચરલ તત્વ છે કે તે રીપોઝીટરીના નામ પર પણ દેખાય છે. સંગ્રહિત માહિતીની ઍક્સેસના કેશીંગ અને સિંક્રનાઇઝેશનના મુદ્દાઓ સંપૂર્ણપણે ઓપરેટિંગ સિસ્ટમ પર છોડી દેવામાં આવે છે. LMDB પોતાની અંદર કોઈ કેશ ધરાવતું નથી. આ લેખક દ્વારા સભાન નિર્ણય છે, કારણ કે મેપ કરેલી ફાઇલોમાંથી સીધો ડેટા વાંચવાથી તમે એન્જિન અમલીકરણમાં ઘણા બધા ખૂણાઓ કાપી શકો છો. નીચે તેમાંથી કેટલાકની સંપૂર્ણ સૂચિથી દૂર છે.

સ્ટોરેજમાં ડેટાની સુસંગતતા જાળવવી જ્યારે ઘણી પ્રક્રિયાઓમાંથી તેની સાથે કામ કરતી વખતે ઓપરેટિંગ સિસ્ટમની જવાબદારી બને છે. આગળના વિભાગમાં, આ મિકેનિક્સ વિશે વિગતવાર અને ચિત્રો સાથે ચર્ચા કરવામાં આવી છે.
કેશની ગેરહાજરી ગતિશીલ ફાળવણી સાથે સંકળાયેલ ઓવરહેડમાંથી LMDBને સંપૂર્ણપણે દૂર કરે છે. વ્યવહારમાં ડેટા વાંચવાનો અર્થ એ છે કે વર્ચ્યુઅલ મેમરીમાં સાચા સરનામા પર પોઇન્ટર સેટ કરવું અને વધુ કંઈ નહીં. તે સાયન્સ ફિક્શન જેવું લાગે છે, પરંતુ સ્ટોરેજ સોર્સ કોડમાં કૉલોક માટેના તમામ કૉલ્સ સ્ટોરેજ કન્ફિગરેશન ફંક્શનમાં કેન્દ્રિત છે.
કેશની ગેરહાજરીનો અર્થ એ પણ છે કે તેમની ઍક્સેસના સિંક્રનાઇઝેશન સાથે સંકળાયેલા તાળાઓની ગેરહાજરી. વાચકો, જેમાંથી એક જ સમયે વાચકોની મનસ્વી સંખ્યા હોઈ શકે છે, તેઓ ડેટાના માર્ગ પર એક પણ મ્યુટેક્સનો સામનો કરતા નથી. આને કારણે, CPU ની સંખ્યાના આધારે રીડિંગ સ્પીડ આદર્શ રેખીય માપનીયતા ધરાવે છે. LMDB માં, માત્ર સંશોધિત કામગીરી સિંક્રનાઇઝ થાય છે. એક સમયે એક જ લેખક હોઈ શકે.
ન્યૂનતમ કેશીંગ અને સિંક્રનાઇઝેશન લોજિક બહુ-થ્રેડેડ વાતાવરણમાં કામ કરવા સાથે સંકળાયેલ અત્યંત જટિલ પ્રકારની ભૂલોને દૂર કરે છે. Usenix OSDI 2014 કોન્ફરન્સમાં બે રસપ્રદ ડેટાબેઝ અભ્યાસો હતા: "બધી ફાઇલ સિસ્ટમ્સ સમાન રીતે બનાવવામાં આવી નથી: ક્રેશ-સતત એપ્લિકેશનોની રચનાની જટિલતા પર" и "આનંદ અને નફા માટે ડેટાબેઝને ત્રાસ આપવો". તેમની પાસેથી તમે LMDB ની અભૂતપૂર્વ વિશ્વસનીયતા અને ACID ટ્રાન્ઝેક્શન પ્રોપર્ટીઝના લગભગ દોષરહિત અમલીકરણ વિશેની માહિતી મેળવી શકો છો, જે SQLite કરતા શ્રેષ્ઠ છે.
LMDB ની મિનિમલિઝમ તેના કોડની મશીન રજૂઆતને આગામી ઝડપની લાક્ષણિકતાઓ સાથે પ્રોસેસરના L1 કેશમાં સંપૂર્ણપણે સ્થિત થવા દે છે.

કમનસીબે, આઇઓએસમાં, મેમરી-મેપ કરેલી ફાઇલો સાથે, બધું આપણે ઇચ્છીએ તેટલું વાદળ રહિત નથી. તેમની સાથે સંકળાયેલ ખામીઓ વિશે વધુ સભાનપણે વાત કરવા માટે, ઑપરેટિંગ સિસ્ટમ્સમાં આ પદ્ધતિના અમલીકરણના સામાન્ય સિદ્ધાંતોને યાદ રાખવું જરૂરી છે.

મેમરી-મેપ કરેલી ફાઇલો વિશે સામાન્ય માહિતી

ચાલતી દરેક એપ્લિકેશન સાથે, ઓપરેટિંગ સિસ્ટમ પ્રક્રિયા તરીકે ઓળખાતી એન્ટિટીને સાંકળે છે. દરેક પ્રક્રિયાને સરનામાંની સંલગ્ન શ્રેણી ફાળવવામાં આવે છે જેમાં તે તેને કામ કરવા માટે જરૂરી બધું મૂકે છે. સૌથી નીચા સરનામાંઓ પર કોડ અને હાર્ડ-કોડેડ ડેટા અને સંસાધનો સાથેના વિભાગો છે. આગળ ડાયનેમિક એડ્રેસ સ્પેસનો વધતો બ્લોક આવે છે, જે આપણને ઢગલા નામથી જાણીતો છે. તે એકમોના સરનામાં ધરાવે છે જે પ્રોગ્રામના સંચાલન દરમિયાન દેખાય છે. ટોચ પર એપ્લિકેશન સ્ટેક દ્વારા ઉપયોગમાં લેવાતો મેમરી વિસ્તાર છે. તે કાં તો વધે છે અથવા સંકુચિત થાય છે; બીજા શબ્દોમાં કહીએ તો, તેનું કદ પણ ગતિશીલ પ્રકૃતિ ધરાવે છે. સ્ટેક અને હીપને એકબીજા સાથે દબાણ અને દખલ કરતા અટકાવવા માટે, તેઓ સરનામાંની જગ્યાના જુદા જુદા છેડા પર સ્થિત છે. ઉપર અને નીચે બે ગતિશીલ વિભાગો વચ્ચે એક છિદ્ર છે. પ્રક્રિયા સાથે વિવિધ સંસ્થાઓને સાંકળવા માટે ઓપરેટિંગ સિસ્ટમ આ મધ્યમ વિભાગમાં સરનામાંનો ઉપયોગ કરે છે. ખાસ કરીને, તે ડિસ્ક પરની ફાઇલ સાથે સરનામાંના ચોક્કસ સતત સેટને સાંકળી શકે છે. આવી ફાઇલને મેમરી-મેપ્ડ કહેવામાં આવે છે

પ્રક્રિયા માટે ફાળવેલ સરનામાંની જગ્યા વિશાળ છે. સૈદ્ધાંતિક રીતે, સરનામાંઓની સંખ્યા માત્ર પોઇન્ટરના કદ દ્વારા મર્યાદિત છે, જે સિસ્ટમની બીટ ક્ષમતા દ્વારા નક્કી કરવામાં આવે છે. જો ભૌતિક મેમરીને 1-થી-1 સાથે મેપ કરવામાં આવી હોય, તો પ્રથમ પ્રક્રિયા સમગ્ર રેમને ગબડશે, અને કોઈપણ મલ્ટિટાસ્કિંગની કોઈ વાત થશે નહીં.

જો કે, અમારા અનુભવ પરથી આપણે જાણીએ છીએ કે આધુનિક ઓપરેટિંગ સિસ્ટમ એકસાથે ઇચ્છિત હોય તેટલી પ્રક્રિયાઓ એક્ઝિક્યુટ કરી શકે છે. આ એ હકીકતને કારણે શક્ય છે કે તેઓ ફક્ત કાગળ પરની પ્રક્રિયાઓ માટે ઘણી બધી મેમરી ફાળવે છે, પરંતુ વાસ્તવમાં તેઓ મુખ્ય ભૌતિક મેમરીમાં ફક્ત તે જ ભાગ લોડ કરે છે જેની અહીં અને હવે માંગ છે. તેથી, પ્રક્રિયા સાથે સંકળાયેલ મેમરીને વર્ચ્યુઅલ કહેવામાં આવે છે.

ઓપરેટિંગ સિસ્ટમ વર્ચ્યુઅલ અને ભૌતિક મેમરીને ચોક્કસ કદના પૃષ્ઠોમાં ગોઠવે છે. જલદી વર્ચ્યુઅલ મેમરીના ચોક્કસ પૃષ્ઠની માંગ છે, ઑપરેટિંગ સિસ્ટમ તેને ભૌતિક મેમરીમાં લોડ કરે છે અને તેમને વિશિષ્ટ કોષ્ટકમાં મેળ ખાય છે. જો ત્યાં કોઈ મફત સ્લોટ્સ ન હોય, તો પહેલા લોડ કરેલા પૃષ્ઠોમાંથી એક ડિસ્ક પર કૉપિ કરવામાં આવે છે, અને માંગમાંનું એક તેનું સ્થાન લે છે. આ પ્રક્રિયા, જેના પર આપણે ટૂંક સમયમાં પાછા આવીશું, તેને સ્વેપિંગ કહેવામાં આવે છે. નીચેની આકૃતિ વર્ણવેલ પ્રક્રિયાને સમજાવે છે. તેના પર, સરનામાં 0 સાથેનું પૃષ્ઠ A લોડ કરવામાં આવ્યું હતું અને સરનામાં 4 સાથે મુખ્ય મેમરી પૃષ્ઠ પર મૂકવામાં આવ્યું હતું. આ હકીકત સેલ નંબર 0 માં પત્રવ્યવહાર કોષ્ટકમાં પ્રતિબિંબિત થઈ હતી.

મેમરીમાં મેપ કરેલી ફાઇલો સાથે વાર્તા બરાબર એ જ છે. તાર્કિક રીતે, તેઓ માનવામાં આવે છે કે સતત અને સંપૂર્ણ રીતે વર્ચ્યુઅલ સરનામાંની જગ્યામાં સ્થિત છે. જો કે, તેઓ પૃષ્ઠ દ્વારા અને માત્ર વિનંતી પર ભૌતિક મેમરી પૃષ્ઠ દાખલ કરે છે. આવા પૃષ્ઠોના ફેરફારને ડિસ્ક પરની ફાઇલ સાથે સિંક્રનાઇઝ કરવામાં આવે છે. આ રીતે, તમે ફક્ત મેમરીમાં બાઇટ સાથે કામ કરીને ફાઇલ I/O કરી શકો છો - બધા ફેરફારો ઑપરેટિંગ સિસ્ટમ કર્નલ દ્વારા ઑટોમૅટિક રીતે સ્રોત ફાઇલમાં સ્થાનાંતરિત થશે.
'
નીચેની છબી દર્શાવે છે કે વિવિધ પ્રક્રિયાઓમાંથી ડેટાબેઝ સાથે કામ કરતી વખતે LMDB તેની સ્થિતિને કેવી રીતે સિંક્રનાઇઝ કરે છે. એક જ ફાઇલમાં વિવિધ પ્રક્રિયાઓની વર્ચ્યુઅલ મેમરીને મેપ કરીને, અમે હકીકતમાં ઑપરેટિંગ સિસ્ટમને તેમની સરનામાંની જગ્યાઓના અમુક બ્લોક્સને એકબીજા સાથે સંક્રમિત રીતે સિંક્રનાઇઝ કરવા માટે ફરજ પાડીએ છીએ, જ્યાં LMDB દેખાય છે.
'

એક મહત્વપૂર્ણ સૂક્ષ્મતા એ છે કે LMDB, ડિફૉલ્ટ રૂપે, રાઇટ સિસ્ટમ કૉલ મિકેનિઝમ દ્વારા ડેટા ફાઇલમાં ફેરફાર કરે છે, અને ફાઇલને ફક્ત વાંચવા માટેના મોડમાં પ્રદર્શિત કરે છે. આ અભિગમના બે મહત્વપૂર્ણ પરિણામો છે.

પ્રથમ પરિણામ તમામ ઓપરેટિંગ સિસ્ટમો માટે સામાન્ય છે. તેનો સાર એ છે કે ખોટા કોડ દ્વારા ડેટાબેઝને અજાણતાં નુકસાન સામે રક્ષણ ઉમેરવું. જેમ તમે જાણો છો, પ્રક્રિયાની એક્ઝિક્યુટેબલ સૂચનાઓ તેના સરનામાંની જગ્યામાં ગમે ત્યાંથી ડેટા ઍક્સેસ કરવા માટે મફત છે. તે જ સમયે, જેમ આપણે હમણાં જ યાદ કર્યું છે, ફાઇલને વાંચવા-લેખવાની સ્થિતિમાં પ્રદર્શિત કરવાનો અર્થ એ છે કે કોઈપણ સૂચના તેને સુધારી શકે છે. જો તેણી ભૂલથી આ કરે છે, ઉદાહરણ તરીકે, અસ્તિત્વમાં ન હોય તેવા અનુક્રમણિકા પર વાસ્તવમાં એરે ઘટક પર ફરીથી લખવાનો પ્રયાસ કરે છે, તો તે આકસ્મિક રીતે આ સરનામાં પર મેપ કરેલી ફાઇલને બદલી શકે છે, જે ડેટાબેઝના ભ્રષ્ટાચાર તરફ દોરી જશે. જો ફાઇલ ફક્ત-રીડ-ઓન્લી મોડમાં પ્રદર્શિત થાય છે, તો અનુરૂપ સરનામાંની જગ્યા બદલવાનો પ્રયાસ સિગ્નલ સાથે પ્રોગ્રામને કટોકટી સમાપ્તિ તરફ દોરી જશે. SIGSEGV, અને ફાઇલ અકબંધ રહેશે.

બીજું પરિણામ પહેલેથી જ iOS માટે વિશિષ્ટ છે. ન તો લેખક કે અન્ય કોઈ સ્ત્રોત તેનો સ્પષ્ટ ઉલ્લેખ કરે છે, પરંતુ તેના વિના LMDB આ મોબાઈલ ઓપરેટિંગ સિસ્ટમ પર ચાલવા માટે યોગ્ય રહેશે નહીં. આગળનો વિભાગ તેના વિચારણા માટે સમર્પિત છે.

iOS માં મેમરી-મેપ કરેલી ફાઇલોની વિશિષ્ટતાઓ

WWDC ખાતે 2018 માં એક અદ્ભુત અહેવાલ હતો "iOS મેમરી ડીપ ડાઇવ". તે અમને કહે છે કે iOS માં, ભૌતિક મેમરીમાં સ્થિત તમામ પૃષ્ઠો 3 પ્રકારોમાંથી એક છે: ગંદા, સંકુચિત અને સ્વચ્છ.

સ્વચ્છ મેમરી એ પૃષ્ઠોનો સંગ્રહ છે જે ભૌતિક મેમરીમાંથી પીડારહિત રીતે અનલોડ કરી શકાય છે. તેઓ જે ડેટા ધરાવે છે તે તેના મૂળ સ્ત્રોતોમાંથી જરૂરિયાત મુજબ ફરીથી લોડ કરી શકાય છે. ફક્ત વાંચવા માટેની મેમરી-મેપ કરેલી ફાઇલો આ શ્રેણીમાં આવે છે. iOS કોઈપણ સમયે મેમરીમાંથી ફાઇલમાં મેપ કરેલા પૃષ્ઠોને અનલોડ કરવામાં ડરતું નથી, કારણ કે તેઓ ડિસ્ક પરની ફાઇલ સાથે સિંક્રનાઇઝ થવાની ખાતરી આપે છે.
'
બધા સંશોધિત પૃષ્ઠો ગંદા મેમરીમાં સમાપ્ત થાય છે, પછી ભલે તે મૂળ રૂપે ક્યાં સ્થિત હોય. ખાસ કરીને, તેમની સાથે સંકળાયેલ વર્ચ્યુઅલ મેમરીમાં લખીને સંશોધિત મેમરી-મેપ કરેલી ફાઇલોને આ રીતે વર્ગીકૃત કરવામાં આવશે. ધ્વજ સાથે LMDB ખોલી રહ્યું છે MDB_WRITEMAP, તેમાં ફેરફાર કર્યા પછી, તમે આને વ્યક્તિગત રીતે ચકાસી શકો છો

જલદી કોઈ એપ્લિકેશન ખૂબ જ ભૌતિક મેમરી લેવાનું શરૂ કરે છે, iOS તેને ગંદા પૃષ્ઠ કમ્પ્રેશનને આધિન કરે છે. ગંદા અને સંકુચિત પૃષ્ઠો દ્વારા કબજે કરાયેલ કુલ મેમરી એપ્લિકેશનની કહેવાતી મેમરી ફૂટપ્રિન્ટ બનાવે છે. એકવાર તે ચોક્કસ થ્રેશોલ્ડ મૂલ્ય સુધી પહોંચી જાય, OOM કિલર સિસ્ટમ ડિમન પ્રક્રિયા પછી આવે છે અને તેને બળજબરીથી સમાપ્ત કરે છે. ડેસ્કટોપ ઓપરેટિંગ સિસ્ટમ્સની સરખામણીમાં iOSની આ ખાસિયત છે. તેનાથી વિપરિત, ફિઝિકલ મેમરીમાંથી ડિસ્કમાં પૃષ્ઠોને સ્વેપ કરીને મેમરી ફૂટપ્રિન્ટને ઘટાડવું iOS માં પ્રદાન કરવામાં આવતું નથી. કારણો ફક્ત અનુમાન કરી શકાય છે. કદાચ સઘન રીતે પૃષ્ઠોને ડિસ્ક પર અને પાછળ ખસેડવાની પ્રક્રિયા મોબાઇલ ઉપકરણો માટે ખૂબ ઊર્જા-વપરાશ કરનારી છે, અથવા iOS એસએસડી ડ્રાઇવ્સ પર કોષોને ફરીથી લખવાના સંસાધનને બચાવે છે, અથવા કદાચ ડિઝાઇનર્સ સિસ્ટમના એકંદર પ્રદર્શનથી સંતુષ્ટ ન હતા, જ્યાં બધું જ છે. સતત અદલાબદલી. ભલે તે બની શકે, હકીકત એ હકીકત રહે છે.

સારા સમાચાર, પહેલાથી જ ઉલ્લેખિત છે, એ છે કે LMDB મૂળભૂત રીતે ફાઇલોને અપડેટ કરવા માટે mmap મિકેનિઝમનો ઉપયોગ કરતું નથી. આનો અર્થ એ છે કે પ્રદર્શિત ડેટાને iOS દ્વારા સ્વચ્છ મેમરી તરીકે વર્ગીકૃત કરવામાં આવે છે અને તે મેમરી ફૂટપ્રિન્ટમાં યોગદાન આપતું નથી. તમે VM ટ્રેકર નામના Xcode સાધનનો ઉપયોગ કરીને આને ચકાસી શકો છો. નીચેનો સ્ક્રીનશોટ ઓપરેશન દરમિયાન ક્લાઉડ એપ્લિકેશનની iOS વર્ચ્યુઅલ મેમરીની સ્થિતિ બતાવે છે. શરૂઆતમાં, તેમાં 2 LMDB દાખલા શરૂ કરવામાં આવ્યા હતા. પ્રથમને તેની ફાઇલ વર્ચ્યુઅલ મેમરીના 1GiB પર પ્રદર્શિત કરવાની મંજૂરી આપવામાં આવી હતી, બીજી - 512MiB. એ હકીકત હોવા છતાં કે બંને સ્ટોરેજ નિવાસી મેમરીની ચોક્કસ રકમ ધરાવે છે, તેમાંથી કોઈ પણ ગંદા કદનું યોગદાન આપતું નથી.

અને હવે ખરાબ સમાચારનો સમય છે. 64-બીટ ડેસ્કટોપ ઓપરેટિંગ સિસ્ટમમાં સ્વેપ મિકેનિઝમ માટે આભાર, દરેક પ્રક્રિયા તેના સંભવિત સ્વેપ માટે મફત હાર્ડ ડિસ્ક જગ્યા પરવાનગી આપે છે તેટલી વર્ચ્યુઅલ એડ્રેસ સ્પેસ રોકી શકે છે. iOS માં કમ્પ્રેશન સાથે સ્વેપને બદલવાથી સૈદ્ધાંતિક મહત્તમ ઘટાડો થાય છે. હવે તમામ જીવંત પ્રક્રિયાઓ મુખ્ય (રેમ વાંચો) મેમરીમાં ફિટ થવી જોઈએ, અને તે બધી જે બંધબેસતી નથી તેને સમાપ્ત કરવાની ફરજ પાડવી જોઈએ. આ ઉપરોક્ત મુજબ જણાવ્યું છે અહેવાલ, અને માં સત્તાવાર દસ્તાવેજીકરણ. પરિણામે, iOS mmap દ્વારા ફાળવણી માટે ઉપલબ્ધ મેમરીની માત્રાને ગંભીરપણે મર્યાદિત કરે છે. અહીં અહીં તમે આ સિસ્ટમ કોલનો ઉપયોગ કરીને વિવિધ ઉપકરણો પર ફાળવી શકાય તેવી મેમરીની માત્રાની પ્રયોગમૂલક મર્યાદા જોઈ શકો છો. સૌથી આધુનિક સ્માર્ટફોન મોડલ્સ પર, iOS 2 ગીગાબાઇટ્સ દ્વારા ઉદાર બન્યું છે, અને આઈપેડના ટોચના સંસ્કરણો પર - 4 દ્વારા. વ્યવહારમાં, અલબત્ત, તમારે સૌથી નીચા સપોર્ટેડ ડિવાઇસ મોડલ્સ પર ધ્યાન કેન્દ્રિત કરવું પડશે, જ્યાં બધું ખૂબ જ ઉદાસી છે. આનાથી પણ ખરાબ, VM ટ્રેકરમાં એપ્લિકેશનની મેમરી સ્થિતિ જોઈને, તમે જોશો કે LMDB એ મેમરી-મેપ્ડ હોવાનો દાવો કરતી એકમાત્ર વ્યક્તિથી દૂર છે. સિસ્ટમ એલોકેટર્સ, રિસોર્સ ફાઇલો, ઇમેજ ફ્રેમવર્ક અને અન્ય નાના શિકારીઓ દ્વારા સારા હિસ્સાને ખાઈ જાય છે.

ક્લાઉડમાં પ્રયોગોના પરિણામોના આધારે, અમે LMDB દ્વારા ફાળવેલ મેમરી માટે નીચેના સમાધાન મૂલ્યો પર આવ્યા: 384-બીટ ઉપકરણો માટે 32 મેગાબાઇટ્સ અને 768-બીટ ઉપકરણો માટે 64. આ વોલ્યુમનો ઉપયોગ થઈ ગયા પછી, કોઈપણ ફેરફાર કરવાની કામગીરી કોડ સાથે સમાપ્ત થવાનું શરૂ થાય છે MDB_MAP_FULL. અમે અમારા મોનિટરિંગમાં આવી ભૂલોનું અવલોકન કરીએ છીએ, પરંતુ તે એટલી નાની છે કે આ તબક્કે તેની અવગણના કરી શકાય છે.

સ્ટોરેજ દ્વારા વધુ પડતી મેમરી વપરાશ માટેનું એક અસ્પષ્ટ કારણ લાંબા ગાળાના વ્યવહારો હોઈ શકે છે. આ બે ઘટનાઓ કેવી રીતે જોડાયેલ છે તે સમજવા માટે, LMDB ના બાકીના બે સ્તંભોને ધ્યાનમાં લઈને અમને મદદ કરવામાં આવશે.

3.2. વ્હેલ #2. B+-વૃક્ષ

કી-વેલ્યુ સ્ટોરેજની ટોચ પર કોષ્ટકોનું અનુકરણ કરવા માટે, નીચેના ઑપરેશન્સ તેના API માં હાજર હોવા જોઈએ:

નવું તત્વ દાખલ કરી રહ્યું છે.
આપેલ કી વડે તત્વ શોધો.
એક તત્વ દૂર કરી રહ્યા છીએ.
કીના અંતરાલો પર તે ક્રમમાં પુનરાવર્તિત કરો.

સરળ ડેટા માળખું જે તમામ ચાર કામગીરીને સરળતાથી અમલમાં મૂકી શકે છે તે દ્વિસંગી શોધ વૃક્ષ છે. તેના દરેક નોડ્સ એક કીનું પ્રતિનિધિત્વ કરે છે જે ચાઈલ્ડ કીના સમગ્ર સબસેટને બે સબટ્રીઝમાં વિભાજિત કરે છે. ડાબામાં તે છે જે માતાપિતા કરતા નાના છે, અને જમણામાં મોટા છે. ક્લાસિક ટ્રી ટ્રાવર્સલ્સમાંથી એક દ્વારા કીનો ઓર્ડર કરેલ સેટ મેળવવો

દ્વિસંગી વૃક્ષોમાં બે મૂળભૂત ખામીઓ છે જે તેમને ડિસ્ક-આધારિત ડેટા સ્ટ્રક્ચર તરીકે અસરકારક બનવાથી અટકાવે છે. પ્રથમ, તેમના સંતુલનની ડિગ્રી અણધારી છે. વૃક્ષો મેળવવાનું નોંધપાત્ર જોખમ છે જેમાં વિવિધ શાખાઓની ઊંચાઈ મોટા પ્રમાણમાં અલગ હોઈ શકે છે, જે અપેક્ષિત છે તેની તુલનામાં શોધની અલ્ગોરિધમિક જટિલતાને નોંધપાત્ર રીતે વધુ ખરાબ કરે છે. બીજું, નોડ્સ વચ્ચેની ક્રોસ-લિંક્સની વિપુલતા મેમરીમાં સ્થાનિકતાના દ્વિસંગી વૃક્ષોને વંચિત કરે છે. ક્લોઝ નોડ્સ (તેમની વચ્ચેના જોડાણોની દ્રષ્ટિએ) વર્ચ્યુઅલ મેમરીમાં સંપૂર્ણપણે અલગ પૃષ્ઠો પર સ્થિત હોઈ શકે છે. પરિણામે, એક વૃક્ષમાં કેટલાક પડોશી ગાંઠોના એક સરળ ટ્રાવર્સલ માટે પણ તુલનાત્મક સંખ્યામાં પૃષ્ઠોની મુલાકાત લેવાની જરૂર પડી શકે છે. જ્યારે આપણે ઇન-મેમરી ડેટા સ્ટ્રક્ચર તરીકે બાઈનરી ટ્રીની અસરકારકતા વિશે વાત કરીએ ત્યારે પણ આ એક સમસ્યા છે, કારણ કે પ્રોસેસર કેશમાં પૃષ્ઠોને સતત ફેરવવું એ સસ્તો આનંદ નથી. જ્યારે ડિસ્કમાંથી નોડ્સ સાથે સંકળાયેલા પૃષ્ઠોને વારંવાર પુનઃપ્રાપ્ત કરવાની વાત આવે છે, ત્યારે પરિસ્થિતિ સંપૂર્ણપણે બની જાય છે દુ:ખદાયક.

B-વૃક્ષો, દ્વિસંગી વૃક્ષોની ઉત્ક્રાંતિ હોવાથી, પાછલા ફકરામાં ઓળખાયેલી સમસ્યાઓનું નિરાકરણ કરે છે. પ્રથમ, તેઓ સ્વ-સંતુલિત છે. બીજું, તેમના દરેક નોડ્સ ચાઈલ્ડ કીના સેટને 2 માં નહીં, પરંતુ M ઓર્ડર કરેલા સબસેટમાં વિભાજિત કરે છે, અને સંખ્યા M ઘણી મોટી હોઈ શકે છે, કેટલાક સો અથવા તો હજારોના ક્રમમાં.

આમ:

દરેક નોડમાં પહેલેથી જ ઓર્ડર કરેલી કીની મોટી સંખ્યા હોય છે અને વૃક્ષો ખૂબ ટૂંકા હોય છે.
વૃક્ષ મેમરીમાં સ્થાનના સ્થાનની મિલકત મેળવે છે, કારણ કે કી જે કિંમતમાં નજીક છે તે કુદરતી રીતે સમાન અથવા પડોશી ગાંઠો પર એકબીજાની બાજુમાં સ્થિત છે.
સર્ચ ઓપરેશન દરમિયાન ઝાડ નીચે ઉતરતી વખતે ટ્રાન્ઝિટ નોડની સંખ્યા ઓછી થાય છે.
શ્રેણી ક્વેરીઝ દરમિયાન વાંચવામાં આવતા લક્ષ્ય નોડ્સની સંખ્યા ઓછી થઈ છે, કારણ કે તેમાંના દરેકમાં પહેલેથી જ મોટી સંખ્યામાં ઓર્ડર કરેલી કી છે.

LMDB ડેટા સ્ટોર કરવા માટે B+ ટ્રી તરીકે ઓળખાતા B-ટ્રીની વિવિધતાનો ઉપયોગ કરે છે. ઉપરોક્ત આકૃતિ ત્રણ પ્રકારના ગાંઠો દર્શાવે છે જે તેમાં અસ્તિત્વ ધરાવે છે:

ટોચ પર રુટ છે. તે વેરહાઉસની અંદરના ડેટાબેઝની વિભાવના સિવાય બીજું કશું જ સાકાર કરતું નથી. એક LMDB દાખલાની અંદર, તમે ઘણા ડેટાબેસેસ બનાવી શકો છો જે મેપ કરેલ વર્ચ્યુઅલ એડ્રેસ સ્પેસ શેર કરે છે. તેમાંથી દરેક તેના પોતાના મૂળથી શરૂ થાય છે.
સૌથી નીચા સ્તરે પાંદડા છે. તેઓ અને માત્ર તેઓ જ ડેટાબેઝમાં સંગ્રહિત કી-વેલ્યુ જોડી ધરાવે છે. માર્ગ દ્વારા, આ B+-વૃક્ષોની ખાસિયત છે. જો નિયમિત બી-ટ્રી તમામ સ્તરોના નોડ્સમાં મૂલ્યના ભાગોને સંગ્રહિત કરે છે, તો B+ ભિન્નતા ફક્ત સૌથી નીચામાં જ છે. આ હકીકતને નિશ્ચિત કર્યા પછી, અમે આગળ LMDB માં વપરાતા વૃક્ષના પેટા પ્રકારને ફક્ત બી-ટ્રી કહીશું.
મૂળ અને પાંદડા વચ્ચે નેવિગેશનલ (બ્રાંચ) નોડ્સ સાથે 0 અથવા વધુ તકનીકી સ્તરો છે. તેમનું કાર્ય પાંદડા વચ્ચે ચાવીઓના સૉર્ટ કરેલ સમૂહને વિભાજીત કરવાનું છે.

ભૌતિક રીતે, નોડ્સ એ પૂર્વનિર્ધારિત લંબાઈની મેમરીના બ્લોક્સ છે. તેમનું કદ ઓપરેટિંગ સિસ્ટમમાં મેમરી પૃષ્ઠોના કદના બહુવિધ છે, જેની આપણે ઉપર ચર્ચા કરી છે. નોડ માળખું નીચે દર્શાવેલ છે. હેડરમાં મેટા માહિતી હોય છે, જેમાંથી સૌથી વધુ સ્પષ્ટ ઉદાહરણ તરીકે ચેકસમ છે. આગળ ઑફસેટ્સ વિશેની માહિતી આવે છે જેમાં ડેટા સાથેના કોષો સ્થિત છે. જો આપણે નેવિગેશન નોડ્સ વિશે વાત કરી રહ્યા હોઈએ તો ડેટા કાંતો કી હોઈ શકે છે, અથવા પાંદડાના કિસ્સામાં સંપૂર્ણ કી-વેલ્યુ જોડીઓ વિશે. તમે કાર્યમાં પૃષ્ઠોની રચના વિશે વધુ વાંચી શકો છો "ઉચ્ચ પ્રદર્શન કી-વેલ્યુ સ્ટોર્સનું મૂલ્યાંકન".

પૃષ્ઠ ગાંઠોની આંતરિક સામગ્રી સાથે વ્યવહાર કર્યા પછી, અમે આગળના સ્વરૂપમાં LMDB B-ટ્રીને સરળ રીતે રજૂ કરીશું.

નોડ્સવાળા પૃષ્ઠો ડિસ્ક પર ક્રમિક રીતે સ્થિત છે. ઉચ્ચ ક્રમાંકિત પૃષ્ઠો ફાઇલના અંત તરફ સ્થિત છે. કહેવાતા મેટા પૃષ્ઠમાં ઑફસેટ્સ વિશેની માહિતી છે જેના દ્વારા તમામ વૃક્ષોના મૂળ શોધી શકાય છે. ફાઇલ ખોલતી વખતે, માન્ય મેટા પેજની શોધમાં LMDB ફાઇલ પેજને પેજ દ્વારા અંતથી શરૂઆત સુધી સ્કેન કરે છે અને તેના દ્વારા હાલના ડેટાબેસેસ શોધે છે.

હવે, ડેટા ઓર્ગેનાઈઝેશનની તાર્કિક અને ભૌતિક રચનાનો ખ્યાલ રાખીને, આપણે LMDB ના ત્રીજા સ્તંભને ધ્યાનમાં લઈ શકીએ છીએ. તે તેની મદદથી છે કે તમામ સ્ટોરેજ ફેરફારો વ્યવહારિક રીતે અને એકબીજાથી અલગતામાં થાય છે, જે સમગ્ર ડેટાબેઝને મલ્ટીવર્ઝનની મિલકત આપે છે.

3.3. વ્હેલ #3. કોપી-ઓન-રાઈટ

કેટલાક બી-ટ્રી ઓપરેશનમાં તેના ગાંઠોમાં શ્રેણીબદ્ધ ફેરફારો કરવાનો સમાવેશ થાય છે. એક ઉદાહરણ નોડમાં નવી કી ઉમેરી રહ્યું છે જે તેની મહત્તમ ક્ષમતા સુધી પહોંચી ગયું છે. આ કિસ્સામાં, તે જરૂરી છે, પ્રથમ, નોડને બે ભાગમાં વિભાજિત કરવું, અને બીજું, તેના માતાપિતામાં નવા ઉભરતા ચાઇલ્ડ નોડની લિંક ઉમેરવી. આ પ્રક્રિયા સંભવિત રીતે ખૂબ જોખમી છે. જો કોઈ કારણોસર (ક્રેશ, પાવર આઉટેજ, વગેરે) શ્રેણીમાંથી ફેરફારોનો માત્ર એક ભાગ થાય છે, તો પછી વૃક્ષ અસંગત સ્થિતિમાં રહેશે.

ડેટાબેઝ ફોલ્ટ-ટોલરન્ટ બનાવવા માટેનો એક પરંપરાગત ઉકેલ એ છે કે બી-ટ્રીની બાજુમાં વધારાની ઑન-ડિસ્ક ડેટા સ્ટ્રક્ચર ઉમેરવું - એક ટ્રાન્ઝેક્શન લોગ, જેને રાઈટ-હેડ લોગ (WAL) તરીકે પણ ઓળખવામાં આવે છે. તે એક ફાઇલ છે જેના અંતે બી-ટ્રીમાં ફેરફાર કરતા પહેલા ઇચ્છિત કામગીરી સખત રીતે લખવામાં આવે છે. આમ, જો સ્વ-નિદાન દરમિયાન ડેટા ભ્રષ્ટાચાર મળી આવે, તો ડેટાબેઝ પોતાને વ્યવસ્થિત કરવા માટે લોગની સલાહ લે છે.

LMDB એ ફોલ્ટ ટોલરન્સ મિકેનિઝમ તરીકે એક અલગ પદ્ધતિ પસંદ કરી છે, જેને કોપી-ઓન-રાઈટ કહેવાય છે. તેનો સાર એ છે કે વર્તમાન પૃષ્ઠ પર ડેટા અપડેટ કરવાને બદલે, તે પહેલા તેની સંપૂર્ણ નકલ કરે છે અને નકલમાં તમામ ફેરફારો કરે છે.

આગળ, અપડેટ કરેલ ડેટા ઉપલબ્ધ થવા માટે, નોડની લિંકને બદલવી જરૂરી છે જે તેના પેરેંટ નોડમાં વર્તમાન બની ગયું છે. આ માટે તેમાં ફેરફાર કરવાની પણ જરૂર હોવાથી, તેની નકલ પણ અગાઉથી કરવામાં આવે છે. પ્રક્રિયા રુટ સુધી બધી રીતે વારંવાર ચાલુ રહે છે. બદલવા માટેની છેલ્લી વસ્તુ મેટા પેજ પરનો ડેટા છે

જો અપડેટ પ્રક્રિયા દરમિયાન અચાનક પ્રક્રિયા ક્રેશ થઈ જાય, તો કાં તો નવું મેટા પેજ બનાવવામાં આવશે નહીં, અથવા તે સંપૂર્ણપણે ડિસ્ક પર લખવામાં આવશે નહીં, અને તેનું ચેકસમ ખોટું હશે. આ બેમાંથી કોઈપણ કિસ્સામાં, નવા પૃષ્ઠો અગમ્ય હશે, પરંતુ જૂના પૃષ્ઠોને અસર થશે નહીં. આ ડેટા સુસંગતતા જાળવવા માટે આગળ લૉગ લખવાની LMDB ની જરૂરિયાતને દૂર કરે છે. હકીકતમાં, ઉપર વર્ણવેલ ડિસ્ક પર ડેટા સ્ટોરેજનું માળખું એકસાથે તેનું કાર્ય લે છે. સ્પષ્ટ ટ્રાન્ઝેક્શન લોગની ગેરહાજરી એ LMDB ની વિશેષતાઓમાંની એક છે જે ઉચ્ચ ડેટા વાંચવાની ઝડપ પૂરી પાડે છે.

પરિણામી ડિઝાઇન, જેને એપેન્ડ-ઓન્લી બી-ટ્રી કહેવાય છે, કુદરતી રીતે ટ્રાન્ઝેક્શન આઇસોલેશન અને મલ્ટિ-વર્ઝનિંગ પ્રદાન કરે છે. LMDB માં, દરેક ઓપન ટ્રાન્ઝેક્શન વર્તમાનમાં સંબંધિત વૃક્ષના મૂળ સાથે સંકળાયેલું છે. જ્યાં સુધી ટ્રાન્ઝેક્શન પૂર્ણ ન થાય ત્યાં સુધી, તેની સાથે સંકળાયેલા વૃક્ષના પૃષ્ઠોને ક્યારેય બદલવામાં આવશે નહીં અથવા ડેટાના નવા સંસ્કરણો માટે પુનઃઉપયોગ કરવામાં આવશે નહીં. આમ, તે સમયે સંબંધિત ડેટાના ચોક્કસ સેટ સાથે તમને ગમે ત્યાં સુધી તમે કામ કરી શકો છો. આ સમયે સ્ટોરેજ સક્રિયપણે અપડેટ થવાનું ચાલુ રહે તો પણ વ્યવહાર ખોલવામાં આવ્યો હતો. આ મલ્ટીવર્ઝનનો સાર છે, જે LMDB ને અમારા પ્રિયજનો માટે એક આદર્શ ડેટા સ્ત્રોત બનાવે છે UICollectionView. ટ્રાન્ઝેક્શન ખોલ્યા પછી, કંઈ બાકી ન રહેવાના ડરથી, વર્તમાન ડેટાને ઉતાવળથી કેટલાક ઇન-મેમરી સ્ટ્રક્ચરમાં પમ્પ કરીને એપ્લિકેશનની મેમરી ફૂટપ્રિન્ટ વધારવાની જરૂર નથી. આ લક્ષણ LMDB ને સમાન SQLite થી અલગ પાડે છે, જે આવા સંપૂર્ણ અલગતાની બડાઈ કરી શકતું નથી. બાદમાં બે વ્યવહારો ખોલ્યા પછી અને તેમાંથી એકમાં ચોક્કસ રેકોર્ડ કાઢી નાખ્યા પછી, બાકીના બીજા એકમાં સમાન રેકોર્ડ મેળવવાનું હવે શક્ય બનશે નહીં.

સિક્કાની ફ્લિપ બાજુ એ વર્ચ્યુઅલ મેમરીનો સંભવિતપણે નોંધપાત્ર રીતે વધુ વપરાશ છે. આ સ્લાઇડ બતાવે છે કે ડેટાબેઝનું માળખું કેવું દેખાશે જો તે ડેટાબેઝના વિવિધ સંસ્કરણોને જોતા 3 ઓપન રીડ ટ્રાન્ઝેક્શન સાથે એકસાથે સંશોધિત કરવામાં આવે. LMDB વર્તમાન વ્યવહારો સાથે સંકળાયેલા મૂળમાંથી પહોંચી શકાય તેવા નોડ્સનો પુનઃઉપયોગ કરી શકતું નથી, તેથી સ્ટોર પાસે મેમરીમાં બીજું ચોથું રુટ ફાળવવા અને તેના હેઠળ સંશોધિત પૃષ્ઠોને ફરીથી ક્લોન કરવા સિવાય કોઈ વિકલ્પ નથી.

અહીં મેમરી-મેપ કરેલી ફાઇલો પરનો વિભાગ યાદ કરવો ઉપયોગી થશે. એવું લાગે છે કે વર્ચ્યુઅલ મેમરીના વધારાના વપરાશથી અમને વધુ ચિંતા ન થવી જોઈએ, કારણ કે તે એપ્લિકેશનના મેમરી ફૂટપ્રિન્ટમાં ફાળો આપતું નથી. જો કે, તે જ સમયે, એ નોંધ્યું હતું કે iOS તેને ફાળવવામાં ખૂબ કંજૂસ છે, અને અમે સર્વર અથવા ડેસ્કટોપની જેમ, 1 ટેરાબાઇટનો LMDB પ્રદેશ પ્રદાન કરી શકતા નથી અને આ સુવિધા વિશે બિલકુલ વિચારી શકતા નથી. જો શક્ય હોય તો, તમારે વ્યવહારોનું જીવનકાળ શક્ય તેટલું ટૂંકું બનાવવાનો પ્રયાસ કરવો જોઈએ.

4. કી-વેલ્યુ API ની ટોચ પર ડેટા સ્કીમા ડિઝાઇન કરવી

ચાલો LMDB દ્વારા પ્રદાન કરવામાં આવેલ મૂળભૂત અમૂર્તતાઓને જોઈને અમારા API વિશ્લેષણની શરૂઆત કરીએ: પર્યાવરણ અને ડેટાબેસેસ, કી અને મૂલ્યો, વ્યવહારો અને કર્સર.

કોડ સૂચિઓ વિશે નોંધ

સાર્વજનિક LMDB API માંના તમામ કાર્યો તેમના કાર્યનું પરિણામ ભૂલ કોડના રૂપમાં પરત કરે છે, પરંતુ પછીની તમામ સૂચિઓમાં સંક્ષિપ્તતા ખાતર તેની ચકાસણી અવગણવામાં આવે છે. કાંટો C++ રેપર્સ lmdbxx, જેમાં ભૂલોને C++ અપવાદો તરીકે સાકાર કરવામાં આવે છે.

IOS અથવા macOS માટેના પ્રોજેક્ટ સાથે LMDB ને કનેક્ટ કરવાની સૌથી ઝડપી રીત તરીકે, હું મારા કોકોપોડનું સૂચન કરું છું 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;

કમ્પેરેટરનો ઉપયોગ કરીને, સ્ટોર ચાવીઓને ચડતા ક્રમમાં સૉર્ટ કરે છે. જો તમે તેને તમારી પોતાની સાથે બદલો નહીં, તો ડિફોલ્ટનો ઉપયોગ કરવામાં આવશે, જે તેને લેક્સિકોગ્રાફિક ક્રમમાં બાઇટ-બાય-બાઇટ સૉર્ટ કરે છે.

વ્યવહાર

ટ્રાન્ઝેક્શન માળખું વિગતવાર માં વર્ણવેલ છે અગાઉનો પ્રકરણ, તેથી અહીં હું તેમના મુખ્ય ગુણધર્મોને સંક્ષિપ્તમાં પુનરાવર્તન કરીશ:

તમામ મૂળભૂત ગુણધર્મોને સપોર્ટ કરે છે ACID: પરમાણુ, સુસંગતતા, અલગતા અને વિશ્વસનીયતા. હું મદદ કરી શકતો નથી પરંતુ નોંધ કરો કે macOS અને iOS પર ટકાઉપણુંના સંદર્ભમાં એક બગ છે જે MDBX માં ઠીક કરવામાં આવ્યો હતો. તમે તેમનામાં વધુ વાંચી શકો છો README.
મલ્ટિથ્રેડિંગનો અભિગમ "સિંગલ રાઇટર / બહુવિધ વાચકો" સ્કીમ દ્વારા વર્ણવવામાં આવ્યો છે. લેખકો એકબીજાને અવરોધે છે, પરંતુ વાચકોને અવરોધિત કરતા નથી. વાચકો લેખકો કે એકબીજાને અવરોધતા નથી.
નેસ્ટેડ વ્યવહારો માટે આધાર.
મલ્ટીવર્ઝન સપોર્ટ.

LMDB માં મલ્ટીવર્ઝન એટલું સારું છે કે હું તેને ક્રિયામાં દર્શાવવા માંગુ છું. નીચેના કોડમાંથી તમે જોઈ શકો છો કે દરેક વ્યવહાર ડેટાબેઝના બરાબર વર્ઝન સાથે કામ કરે છે જે તેને ખોલવામાં આવ્યો ત્યારે વર્તમાન હતો, ત્યારપછીના તમામ ફેરફારોથી સંપૂર્ણપણે અલગ થઈને. સ્ટોરેજની શરૂઆત કરવી અને તેમાં ટેસ્ટ રેકોર્ડ ઉમેરવા એ કંઈપણ રસપ્રદ નથી, તેથી આ ધાર્મિક વિધિઓ બગાડનાર હેઠળ છોડી દેવામાં આવે છે.

ટેસ્ટ એન્ટ્રી ઉમેરી રહ્યા છીએ

MDB_env *env;
MDB_dbi dbi;
MDB_txn *txn;

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

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

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

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

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

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

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

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

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

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

હું ભલામણ કરું છું કે તમે SQLite સાથે સમાન યુક્તિનો પ્રયાસ કરો અને જુઓ કે શું થાય છે.

મલ્ટીવર્ઝન iOS ડેવલપરના જીવનમાં ખૂબ જ સરસ લાભ લાવે છે. આ ગુણધર્મનો ઉપયોગ કરીને, તમે વપરાશકર્તા અનુભવની વિચારણાઓના આધારે, સ્ક્રીન સ્વરૂપો માટે ડેટા સ્રોતના અપડેટ દરને સરળતાથી અને કુદરતી રીતે સમાયોજિત કરી શકો છો. ઉદાહરણ તરીકે, ચાલો Mail.ru ક્લાઉડ એપ્લિકેશનની એક વિશેષતા લઈએ જેમ કે સિસ્ટમ મીડિયા ગેલેરીમાંથી સામગ્રી ઓટોલોડ કરવી. સારા કનેક્શન સાથે, ક્લાયંટ સર્વર પર સેકન્ડ દીઠ ઘણા ફોટા ઉમેરવા માટે સક્ષમ છે. જો તમે દરેક ડાઉનલોડ પછી અપડેટ કરો છો UICollectionView વપરાશકર્તાના ક્લાઉડમાં મીડિયા સામગ્રી સાથે, તમે આ પ્રક્રિયા દરમિયાન લગભગ 60 fps અને સરળ સ્ક્રોલિંગ ભૂલી શકો છો. વારંવાર સ્ક્રીન અપડેટ્સને રોકવા માટે, તમારે કોઈ રીતે તે દરને મર્યાદિત કરવાની જરૂર છે કે જેના પર ડેટા અંતર્ગતમાં ફેરફાર થાય છે UICollectionViewDataSource.

જો ડેટાબેઝ મલ્ટીવર્ઝનને સપોર્ટ કરતું નથી અને તમને ફક્ત વર્તમાન વર્તમાન સ્થિતિ સાથે કામ કરવાની મંજૂરી આપે છે, તો ડેટાનો સમય-સ્થિર સ્નેપશોટ બનાવવા માટે તમારે તેને અમુક ઇન-મેમરી ડેટા સ્ટ્રક્ચર અથવા અસ્થાયી કોષ્ટકમાં કૉપિ કરવાની જરૂર છે. આમાંથી કોઈપણ અભિગમ ખૂબ ખર્ચાળ છે. ઇન-મેમરી સ્ટોરેજના કિસ્સામાં, અમને મેમરીમાં બંને ખર્ચ મળે છે, જે બાંધવામાં આવેલી વસ્તુઓને સંગ્રહિત કરવાને કારણે થાય છે અને સમય જતાં, બિનજરૂરી ORM પરિવર્તનો સાથે સંકળાયેલા છે. અસ્થાયી કોષ્ટકની વાત કરીએ તો, આ એક વધુ ખર્ચાળ આનંદ છે, જે ફક્ત બિન-તુચ્છ કેસોમાં જ અર્થપૂર્ણ છે.

એલએમડીબીનું મલ્ટીવર્ઝન સોલ્યુશન સ્થિર ડેટા સ્ત્રોત જાળવવાની સમસ્યાને ખૂબ જ ભવ્ય રીતે હલ કરે છે. તે માત્ર એક વ્યવહાર અને વોઇલા ખોલવા માટે પૂરતું છે - જ્યાં સુધી અમે તેને પૂર્ણ ન કરીએ, ત્યાં સુધી ડેટા સેટ નિશ્ચિત થવાની ખાતરી આપવામાં આવે છે. તેની અપડેટ સ્પીડ માટેનો તર્ક હવે સંપૂર્ણ રીતે પ્રેઝન્ટેશન લેયરના હાથમાં છે, જેમાં નોંધપાત્ર સંસાધનોનો કોઈ ઓવરહેડ નથી.

કર્સર

કર્સર બી-ટ્રી ટ્રાવર્સલ દ્વારા કી-વેલ્યુ જોડી પર વ્યવસ્થિત રીતે પુનરાવર્તિત કરવા માટે એક પદ્ધતિ પ્રદાન કરે છે. તેમના વિના, ડેટાબેઝમાં કોષ્ટકોનું અસરકારક રીતે મોડેલ બનાવવું અશક્ય હશે, જે આપણે હવે ચાલુ કરીએ છીએ.

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 ના કિસ્સામાં ડેટાબેઝમાં નવા રેકોર્ડ દાખલ કરતી વખતે તેઓને સંપૂર્ણપણે ટાળી શકાય છે. સર્વરમાંથી ઇનકમિંગ બાઇટ એરે પ્રથમ સ્ટેક સ્ટ્રક્ચર્સમાં રૂપાંતરિત થાય છે, અને પછી તેને સ્ટોરેજમાં નજીવી રીતે ડમ્પ કરવામાં આવે છે. LMDB ની અંદર કોઈ ગતિશીલ ફાળવણી પણ નથી તે ધ્યાનમાં લેતા, તમે 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 // ...
}

જ્યાં સુધી ડેટાબેઝમાંની બધી કી એક જ પ્રકારની હોય ત્યાં સુધી, બિનશરતી રીતે તેમની બાઈટ રજૂઆતને એપ્લીકેશન કી સ્ટ્રક્ચરના પ્રકાર પર કાસ્ટ કરવી કાયદેસર છે. અહીં એક સૂક્ષ્મતા છે, પરંતુ તેની ચર્ચા નીચે "રીડિંગ રેકોર્ડ્સ" પેટા વિભાગમાં કરવામાં આવશે.

શ્રેણીબદ્ધ મૂલ્યો

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 મળે છે જે ખૂબ જ ઊંચી ડેટા રીડિંગ સ્પીડ લગભગ મફતમાં પ્રદાન કરે છે. અભિગમની તમામ સુંદરતા હોવા છતાં, તેની સાથે સંકળાયેલી ઘણી સુવિધાઓ યાદ રાખવી જરૂરી છે.

ફક્ત વાંચવા માટેના વ્યવહાર માટે, વેલ્યુ સ્ટ્રક્ચર તરફનો નિર્દેશક માત્ર વ્યવહાર બંધ ન થાય ત્યાં સુધી માન્ય રહેવાની ખાતરી આપવામાં આવે છે. અગાઉ નોંધ્યું છે તેમ, બી-ટ્રી પૃષ્ઠો કે જેના પર ઑબ્જેક્ટ સ્થિત છે, કૉપિ-ઑન-રાઇટ સિદ્ધાંતને આભારી છે, જ્યાં સુધી તેઓ ઓછામાં ઓછા એક વ્યવહાર દ્વારા સંદર્ભિત હોય ત્યાં સુધી યથાવત રહે છે. તે જ સમયે, તેમની સાથે સંકળાયેલ છેલ્લું ટ્રાન્ઝેક્શન પૂર્ણ થતાં જ, પૃષ્ઠોનો નવા ડેટા માટે ફરીથી ઉપયોગ કરી શકાય છે. જો ઑબ્જેક્ટ્સને જનરેટ કરેલા ટ્રાન્ઝેક્શનને ટકી રહેવા માટે તે જરૂરી હોય, તો તે હજુ પણ કૉપિ કરવાની રહેશે.
રીડરાઈટ ટ્રાન્ઝેક્શન માટે, પરિણામી વેલ્યુ સ્ટ્રક્ચર માટેનો નિર્દેશક ફક્ત પ્રથમ ફેરફાર કરવાની પ્રક્રિયા (ડેટા લખવા અથવા કાઢી નાખવા) સુધી માન્ય રહેશે.
માળખું હોવા છતાં 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 જેમ કે તેઓ મુખ્યત્વે પિતૃ નિર્દેશિકાના ID દ્વારા ઓર્ડર કરવામાં આવે છે. આમ, તકનીકી રીતે, ફોલ્ડરની સામગ્રીઓ પુનઃપ્રાપ્ત કરવાનું કાર્ય કર્સરને આપેલ ઉપસર્ગ સાથે કીના જૂથની ઉપરની સીમા પર મૂકવા અને પછી નીચલા સીમા પર પુનરાવર્તિત કરવા માટે નીચે આવે છે.

અપર બાઉન્ડ સીધું ક્રમિક શોધ દ્વારા શોધી શકાય છે. આ કરવા માટે, કર્સરને ડેટાબેઝમાં કીઓની સંપૂર્ણ સૂચિની શરૂઆતમાં મૂકવામાં આવે છે અને જ્યાં સુધી તેની નીચે પેરેન્ટ ડિરેક્ટરીના ઓળખકર્તા સાથેની કી દેખાય ત્યાં સુધી તેને વધુ વધારવામાં આવે છે. આ અભિગમમાં 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" સાથે ઉપસર્ગ છે, અને પ્લેસહોલ્ડર "પ્રોપનેમ" ને વધુ ચોક્કસ મૂલ્ય "જાહેર માહિતી" સાથે બદલી શકાય છે.

તમામ અનન્ય મેટાડેટા, સ્ટોર કરવા ખાતર કે જે નવું ટેબલ બનાવવામાં આવ્યું હતું, તે રેકોર્ડના મૂલ્યના ભાગમાં મૂકવામાં આવે છે. તે જ સમયે, તમે પહેલાથી જ મુખ્ય કોષ્ટકમાં સંગ્રહિત ફાઇલો અને ફોલ્ડર્સ વિશેના ડેટાને ડુપ્લિકેટ કરવા માંગતા નથી. તેના બદલે, "નોડ ID" અને "ટાઇમસ્ટેમ્પ" ફીલ્ડના રૂપમાં "P" કીમાં રીડન્ડન્ટ ડેટા ઉમેરવામાં આવે છે. તેમના માટે આભાર, તમે ઇન્ડેક્સ કી બનાવી શકો છો, જેમાંથી તમે પ્રાથમિક કી મેળવી શકો છો, જેમાંથી, અંતે, તમે નોડ મેટાડેટા મેળવી શકો છો.

નિષ્કર્ષ

અમે LMDB ના અમલીકરણના પરિણામોનું હકારાત્મક મૂલ્યાંકન કરીએ છીએ. તે પછી, એપ્લિકેશન ફ્રીઝની સંખ્યામાં 30% ઘટાડો થયો.

કરેલા કાર્યના પરિણામો iOS ટીમની બહાર પડઘો પાડે છે. હાલમાં, એન્ડ્રોઇડ એપ્લિકેશનમાં મુખ્ય "ફાઇલો" વિભાગોમાંથી એક પણ LMDB નો ઉપયોગ કરવા પર સ્વિચ કરી ગયો છે, અને અન્ય ભાગો માર્ગ પર છે. C ભાષા, જેમાં કી-વેલ્યુ સ્ટોર લાગુ કરવામાં આવે છે, શરૂઆતમાં C++ માં ક્રોસ-પ્લેટફોર્મ તેની આસપાસ એપ્લિકેશન ફ્રેમવર્ક બનાવવા માટે સારી મદદ હતી. એક કોડ જનરેટરનો ઉપયોગ પરિણામી C++ લાઇબ્રેરીને ઑબ્જેક્ટિવ-C અને કોટલિનમાં પ્લેટફોર્મ કોડ સાથે સીમલેસ રીતે કનેક્ટ કરવા માટે કરવામાં આવ્યો હતો. જીન્ની ડ્રૉપબૉક્સમાંથી, પરંતુ તે સંપૂર્ણપણે અલગ વાર્તા છે.

સોર્સ: www.habr.com

iOS એપ્લિકેશન્સમાં કી-વેલ્યુ ડેટાબેઝ LMDB ની તેજસ્વીતા અને ગરીબી