ഡാറ്റാബേസുകളെക്കുറിച്ച് കൂടുതൽ ഡവലപ്പർമാർ ഇത് അറിഞ്ഞിരിക്കണം

കുറിപ്പ്. വിവർത്തനം.: ഗൂഗിളിലെ പരിചയസമ്പന്നയായ എഞ്ചിനീയറാണ് ജാന ഡോഗൻ, നിലവിൽ ഗോയിൽ എഴുതിയ കമ്പനിയുടെ പ്രൊഡക്ഷൻ സേവനങ്ങളുടെ നിരീക്ഷണത്തിനായി പ്രവർത്തിക്കുന്നു. ഇംഗ്ലീഷ് സംസാരിക്കുന്ന പ്രേക്ഷകർക്കിടയിൽ വലിയ ജനപ്രീതി നേടിയ ഈ ലേഖനത്തിൽ, വലിയ/ആവശ്യമുള്ള ആപ്ലിക്കേഷനുകളുടെ ഡെവലപ്പർമാർക്ക് പരിഗണിക്കാൻ ഉപയോഗപ്രദമായ DBMS-കളെ (ചിലപ്പോൾ വിതരണം ചെയ്ത സിസ്റ്റങ്ങളെ പൊതുവായി) സംബന്ധിച്ച സുപ്രധാന സാങ്കേതിക വിശദാംശങ്ങൾ 17 പോയിന്റുകളായി അവർ ശേഖരിച്ചു.

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

1. 99,999% സമയവും നെറ്റ്‌വർക്ക് പ്രശ്‌നങ്ങൾ ഉണ്ടാക്കുന്നില്ലെങ്കിൽ നിങ്ങൾ ഭാഗ്യവാനാണ്.
2. ACID എന്നാൽ പലതരത്തിലുള്ള കാര്യങ്ങൾ അർത്ഥമാക്കുന്നു.
3. സ്ഥിരതയും ഒറ്റപ്പെടലും ഉറപ്പാക്കാൻ ഓരോ ഡാറ്റാബേസിനും അതിന്റേതായ സംവിധാനങ്ങളുണ്ട്.
4. സാധാരണമായത് നിലനിർത്താൻ പ്രയാസമുള്ളപ്പോൾ ശുഭാപ്തിവിശ്വാസമുള്ള തടയൽ രക്ഷാപ്രവർത്തനത്തിലേക്ക് വരുന്നു.
5. വൃത്തികെട്ട വായനയും ഡാറ്റ നഷ്‌ടവും കൂടാതെ മറ്റ് അപാകതകളും ഉണ്ട്.
6. ഡാറ്റാബേസും ഉപയോക്താവും എല്ലായ്പ്പോഴും പ്രവർത്തന ഗതിയിൽ യോജിക്കുന്നില്ല.
7. ആപ്ലിക്കേഷൻ-ലെവൽ ഷാർഡിംഗ് അപ്ലിക്കേഷന് പുറത്തേക്ക് നീക്കാൻ കഴിയും.
8. ഓട്ടോഇൻക്രിമെന്റിംഗ് അപകടകരമാണ്.
9. പഴകിയ ഡാറ്റ ഉപയോഗപ്രദമാകും കൂടാതെ ലോക്ക് ചെയ്യേണ്ടതില്ല.
10. ഏത് സമയ സ്രോതസ്സുകൾക്കും വികലങ്ങൾ സാധാരണമാണ്.
11. കാലതാമസത്തിന് നിരവധി അർത്ഥങ്ങളുണ്ട്.
12. ഒരു നിർദ്ദിഷ്ട ഇടപാടിനായി പ്രകടന ആവശ്യകതകൾ വിലയിരുത്തണം.
13. നെസ്റ്റഡ് ഇടപാടുകൾ അപകടകരമാണ്.
14. ഇടപാടുകൾ അപേക്ഷയുടെ അവസ്ഥയുമായി ബന്ധിപ്പിക്കരുത്.
15. ക്വറി പ്ലാനർമാർക്ക് ഡാറ്റാബേസുകളെക്കുറിച്ച് നിങ്ങൾക്ക് ധാരാളം കാര്യങ്ങൾ പറയാൻ കഴിയും.
16. ഓൺലൈൻ മൈഗ്രേഷൻ ബുദ്ധിമുട്ടാണ്, പക്ഷേ സാധ്യമാണ്.
17. ഡാറ്റാബേസിലെ ഗണ്യമായ വർദ്ധനവ് പ്രവചനാതീതമായ വർദ്ധനവിന് കാരണമാകുന്നു.

ഈ ലേഖനത്തിന്റെ മുമ്പത്തെ പതിപ്പിനെക്കുറിച്ചുള്ള ഫീഡ്‌ബാക്കിന് ഇമ്മാനുവൽ ഒഡെകെ, റെയിൻ ഹെൻ‌റിക്‌സ് എന്നിവരും മറ്റുള്ളവരും നന്ദി പറയാൻ ഞാൻ ആഗ്രഹിക്കുന്നു.

99,999% സമയവും നെറ്റ്‌വർക്ക് പ്രശ്‌നങ്ങൾ ഉണ്ടാക്കുന്നില്ലെങ്കിൽ നിങ്ങൾ ഭാഗ്യവാനാണ്.

ആധുനിക നെറ്റ്‌വർക്ക് സാങ്കേതികവിദ്യകൾ എത്രത്തോളം വിശ്വസനീയമാണെന്നും നെറ്റ്‌വർക്ക് പരാജയങ്ങൾ കാരണം സിസ്റ്റങ്ങൾ എത്ര തവണ തകരാറിലാണെന്നും ചോദ്യം അവശേഷിക്കുന്നു. ഈ പ്രശ്നത്തെക്കുറിച്ചുള്ള വിവരങ്ങൾ വിരളമാണ്, കൂടാതെ പ്രത്യേക നെറ്റ്‌വർക്കുകളും ഉപകരണങ്ങളും ഉദ്യോഗസ്ഥരും ഉള്ള വലിയ ഓർഗനൈസേഷനുകളാണ് ഗവേഷണം പലപ്പോഴും ആധിപത്യം പുലർത്തുന്നത്.

സ്പാനറിന് (Google-ന്റെ ആഗോളതലത്തിൽ വിതരണം ചെയ്ത ഡാറ്റാബേസ്) 99,999% ലഭ്യത നിരക്കിൽ, Google അവകാശപ്പെടുന്നു 7,6% പ്രശ്നങ്ങൾ നെറ്റ്‌വർക്കുമായി ബന്ധപ്പെട്ടതാണ്. അതേ സമയം, കമ്പനി അതിന്റെ പ്രത്യേക ശൃംഖലയെ ഉയർന്ന ലഭ്യതയുടെ "പ്രധാന സ്തംഭം" എന്ന് വിളിക്കുന്നു. പഠനം ബെയ്ലിസും കിംഗ്സ്ബറിയും, 2014-ൽ നടത്തിയ, ഒന്നിനെ വെല്ലുവിളിക്കുന്നു "വിതരണം ചെയ്ത കമ്പ്യൂട്ടിംഗിനെക്കുറിച്ചുള്ള തെറ്റിദ്ധാരണകൾ", 1994-ൽ പീറ്റർ ഡച്ച് രൂപപ്പെടുത്തിയത്. നെറ്റ്‌വർക്ക് ശരിക്കും വിശ്വസനീയമാണോ?

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

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

ACID എന്നാൽ വ്യത്യസ്തമായ ഒരുപാട് കാര്യങ്ങൾ അർത്ഥമാക്കുന്നു

ACID എന്നതിന്റെ ചുരുക്കെഴുത്ത് ആറ്റോമിസിറ്റി, കൺസിസ്റ്റൻസി, ഐസൊലേഷൻ, വിശ്വാസ്യത എന്നിവയെ സൂചിപ്പിക്കുന്നു. ഇടപാടുകളുടെ ഈ പ്രോപ്പർട്ടികൾ പരാജയങ്ങൾ, പിശകുകൾ, ഹാർഡ്‌വെയർ പരാജയങ്ങൾ മുതലായവയിൽ അവയുടെ സാധുത ഉറപ്പാക്കാൻ ഉദ്ദേശിച്ചുള്ളതാണ്. ACID അല്ലെങ്കിൽ സമാനമായ സ്കീമുകൾ ഇല്ലെങ്കിൽ, ആപ്ലിക്കേഷൻ ഡെവലപ്പർമാർക്ക് അവർ ഉത്തരവാദികൾ എന്താണെന്നും ഡാറ്റാബേസ് എന്തിനാണ് ഉത്തരവാദിയെന്നും തമ്മിൽ വേർതിരിച്ചറിയാൻ പ്രയാസമാണ്. മിക്ക റിലേഷണൽ ട്രാൻസാഷണൽ ഡാറ്റാബേസുകളും ACID കംപ്ലയിന്റ് ആയിരിക്കാൻ ശ്രമിക്കുന്നു, എന്നാൽ NoSQL പോലെയുള്ള പുതിയ സമീപനങ്ങൾ ACID ഇടപാടുകളില്ലാതെ നിരവധി ഡാറ്റാബേസുകൾക്ക് കാരണമായി, കാരണം അവ നടപ്പിലാക്കാൻ ചെലവേറിയതാണ്.

ഞാൻ ആദ്യമായി വ്യവസായത്തിൽ പ്രവേശിച്ചപ്പോൾ, ഞങ്ങളുടെ സാങ്കേതിക നേതാവ് ACID ആശയം എത്രത്തോളം പ്രസക്തമാണെന്ന് സംസാരിച്ചു. ശരിയായി പറഞ്ഞാൽ, ACID ഒരു കർശനമായ നടപ്പാക്കൽ മാനദണ്ഡത്തിന് പകരം ഒരു ഏകദേശ വിവരണമായി കണക്കാക്കപ്പെടുന്നു. ഒരു പ്രത്യേക വിഭാഗം പ്രശ്‌നങ്ങൾ ഉന്നയിക്കുന്നതിനാൽ (സാധ്യമായ പരിഹാരങ്ങളുടെ ഒരു ശ്രേണി നിർദ്ദേശിക്കുകയും ചെയ്യുന്നതിനാൽ) ഇന്ന് ഇത് കൂടുതലും ഉപയോഗപ്രദമാണെന്ന് ഞാൻ കാണുന്നു.

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

മോംഗോഡിബി എസിഐഡി ആവശ്യകതകൾ പാലിക്കുന്നുണ്ടോ എന്നതിനെക്കുറിച്ചുള്ള ചർച്ച പതിപ്പ് 4 പുറത്തിറങ്ങിയതിന് ശേഷവും തുടരുന്നു. MongoDB വളരെക്കാലമായി പിന്തുണയ്‌ക്കുന്നില്ല ലോഗിംഗ്, ഡിഫോൾട്ടായി ഡാറ്റ ഓരോ 60 സെക്കൻഡിലും ഒന്നിൽ കൂടുതൽ തവണ ഡിസ്കിൽ പ്രതിജ്ഞാബദ്ധമായിരുന്നെങ്കിലും. ഇനിപ്പറയുന്ന സാഹചര്യം സങ്കൽപ്പിക്കുക: ഒരു ആപ്ലിക്കേഷൻ രണ്ട് എഴുത്തുകൾ (w1, w2) പോസ്റ്റുചെയ്യുന്നു. MongoDB വിജയകരമായി w1 സംഭരിക്കുന്നു, എന്നാൽ ഒരു ഹാർഡ്‌വെയർ പരാജയം കാരണം w2 നഷ്‌ടമായി.

രംഗം ചിത്രീകരിക്കുന്ന ഡയഗ്രം. മോംഗോഡിബി ഡിസ്കിലേക്ക് ഡാറ്റ എഴുതുന്നതിന് മുമ്പ് ക്രാഷാകുന്നു

ഡിസ്കിലേക്ക് കമ്മിറ്റ് ചെയ്യുന്നത് ചെലവേറിയ പ്രക്രിയയാണ്. പതിവ് കമ്മിറ്റുകൾ ഒഴിവാക്കുന്നതിലൂടെ, ഡെവലപ്പർമാർ വിശ്വാസ്യതയുടെ ചെലവിൽ റെക്കോർഡിംഗ് പ്രകടനം മെച്ചപ്പെടുത്തുന്നു. MongoDB നിലവിൽ ലോഗിംഗിനെ പിന്തുണയ്‌ക്കുന്നു, എന്നാൽ ഓരോ 100ms ലും സ്ഥിരസ്ഥിതിയായി ലോഗുകൾ ക്യാപ്‌ചർ ചെയ്യപ്പെടുന്നതിനാൽ വൃത്തികെട്ട എഴുത്തുകൾ ഇപ്പോഴും ഡാറ്റയുടെ സമഗ്രതയെ ബാധിക്കും. അതായത്, അപകടസാധ്യത വളരെ കുറവാണെങ്കിലും ലോഗുകൾക്കും അവയിൽ അവതരിപ്പിച്ചിരിക്കുന്ന മാറ്റങ്ങൾക്കും സമാനമായ ഒരു സാഹചര്യം ഇപ്പോഴും സാധ്യമാണ്.

ഓരോ ഡാറ്റാബേസിനും അതിന്റേതായ സ്ഥിരതയും ഒറ്റപ്പെടൽ സംവിധാനവുമുണ്ട്

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

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

നിലവിലുള്ള കൺകറൻസി മോഡലുകളുടെയും അവ തമ്മിലുള്ള ബന്ധങ്ങളുടെയും അവലോകനം

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

SQL സ്റ്റാൻഡേർഡ് ഇനിപ്പറയുന്ന ഐസൊലേഷൻ ലെവലുകൾ പരാമർശിക്കുന്നു:

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

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

തന്നിരിക്കുന്ന ഡിബിഎംഎസിൽ ഐസൊലേഷൻ ലെവലുകൾക്കുള്ള പിന്തുണ പലപ്പോഴും പരസ്യപ്പെടുത്താറുണ്ട്, എന്നാൽ അതിന്റെ സ്വഭാവത്തെ സൂക്ഷ്മമായി പഠിച്ചാൽ മാത്രമേ യഥാർത്ഥത്തിൽ എന്താണ് സംഭവിക്കുന്നതെന്ന് വെളിപ്പെടുത്താൻ കഴിയൂ.

വ്യത്യസ്ത ഡിബിഎംഎസുകൾക്കായി വ്യത്യസ്ത ഐസൊലേഷൻ തലങ്ങളിലുള്ള കൺകറൻസി അപാകതകളുടെ അവലോകനം

മാർട്ടിൻ ക്ലെപ്പ്മാൻ തന്റെ പദ്ധതിയിൽ സന്യാസി വ്യത്യസ്‌ത ഐസൊലേഷൻ ലെവലുകൾ താരതമ്യം ചെയ്യുന്നു, കൺകറൻസി അപാകതകളെക്കുറിച്ച് സംസാരിക്കുന്നു, ഡാറ്റാബേസിന് ഒരു പ്രത്യേക ഐസൊലേഷൻ ലെവലിൽ പറ്റിനിൽക്കാൻ കഴിയുമോ എന്ന്. ഇൻസുലേഷൻ ലെവലിനെക്കുറിച്ച് ഡാറ്റാബേസ് ഡെവലപ്പർമാർ എത്ര വ്യത്യസ്തമായാണ് ചിന്തിക്കുന്നതെന്ന് ക്ലെപ്പ്മാന്റെ ഗവേഷണം കാണിക്കുന്നു.

സാധാരണമായത് നിലനിർത്താൻ പ്രയാസമുള്ളപ്പോൾ ശുഭാപ്തിവിശ്വാസമുള്ള തടയൽ രക്ഷാപ്രവർത്തനത്തിലേക്ക് വരുന്നു.

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

ശുഭാപ്തിവിശ്വാസമുള്ള ലോക്ക് ഒരു സ്ട്രിംഗ് വായിക്കുമ്പോൾ, അതിന്റെ പതിപ്പ്, ചെക്ക്സം അല്ലെങ്കിൽ അവസാന പരിഷ്ക്കരണ സമയം എന്നിവ കണക്കിലെടുക്കുന്ന ഒരു രീതിയാണ്. ഒരു എൻട്രി മാറ്റുന്നതിന് മുമ്പ് ആറ്റോമിക് പതിപ്പ് മാറ്റമൊന്നുമില്ലെന്ന് ഉറപ്പാക്കാൻ ഇത് നിങ്ങളെ അനുവദിക്കുന്നു:

UPDATE products
SET name = 'Telegraph receiver', version = 2
WHERE id = 1 AND version = 1

ഈ സാഹചര്യത്തിൽ, പട്ടിക അപ്ഡേറ്റ് ചെയ്യുന്നു products മറ്റൊരു ഓപ്പറേഷൻ മുമ്പ് ഈ വരിയിൽ മാറ്റങ്ങൾ വരുത്തിയാൽ അത് നടപ്പിലാക്കില്ല. ഈ വരിയിൽ മറ്റ് പ്രവർത്തനങ്ങളൊന്നും നടത്തിയില്ലെങ്കിൽ, ഒരു വരിയുടെ മാറ്റം സംഭവിക്കും, അപ്ഡേറ്റ് വിജയകരമാണെന്ന് നമുക്ക് പറയാം.

വൃത്തികെട്ട വായനയും ഡാറ്റ നഷ്‌ടവും കൂടാതെ മറ്റ് അപാകതകളും ഉണ്ട്

ഡാറ്റാ സ്ഥിരതയെക്കുറിച്ച് പറയുമ്പോൾ, വൃത്തികെട്ട വായനകൾക്കും ഡാറ്റ നഷ്‌ടത്തിനും ഇടയാക്കുന്ന റേസ് സാഹചര്യങ്ങളുടെ സാധ്യതയിലാണ് ശ്രദ്ധ കേന്ദ്രീകരിക്കുന്നത്. എന്നിരുന്നാലും, ഡാറ്റ അപാകതകൾ അവിടെ അവസാനിക്കുന്നില്ല.

അത്തരം അപാകതകളുടെ ഒരു ഉദാഹരണം റെക്കോർഡിംഗ് വികലമാണ് (തിരിവുകൾ എഴുതുക). വികലങ്ങൾ കണ്ടുപിടിക്കാൻ പ്രയാസമാണ്, കാരണം അവ സാധാരണയായി സജീവമായി തിരയാറില്ല. അവ വൃത്തികെട്ട വായനയോ ഡാറ്റ നഷ്‌ടമോ കാരണമല്ല, മറിച്ച് ഡാറ്റയിൽ സ്ഥാപിച്ചിട്ടുള്ള ലോജിക്കൽ നിയന്ത്രണങ്ങളുടെ ലംഘനമാണ്.

ഉദാഹരണത്തിന്, ഒരു ഓപ്പറേറ്റർ എല്ലായ്‌പ്പോഴും കോളിൽ ഉണ്ടായിരിക്കേണ്ട ഒരു മോണിറ്ററിംഗ് ആപ്ലിക്കേഷൻ നമുക്ക് പരിഗണിക്കാം:

BEGIN tx1;                      BEGIN tx2;
SELECT COUNT(*)
FROM operators
WHERE oncall = true;
0                               SELECT COUNT(*)
                                FROM operators
                                WHERE oncall = TRUE;
                                0
UPDATE operators                UPDATE operators
SET oncall = TRUE               SET oncall = TRUE
WHERE userId = 4;               WHERE userId = 2;
COMMIT tx1;                     COMMIT tx2;

മേൽപ്പറഞ്ഞ സാഹചര്യത്തിൽ, രണ്ട് ഇടപാടുകളും വിജയകരമായി നടത്തിയാൽ റെക്കോർഡ് അഴിമതി സംഭവിക്കും. വൃത്തികെട്ട വായനകളോ ഡാറ്റ നഷ്‌ടമോ ഇല്ലെങ്കിലും, ഡാറ്റയുടെ സമഗ്രത അപഹരിക്കപ്പെട്ടു: ഇപ്പോൾ രണ്ട് ആളുകളെ ഒരേ സമയം ഓൺ-കോൾ ആയി കണക്കാക്കുന്നു.

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

എന്താണ് ചെയ്യേണ്ടതെന്ന് ഡാറ്റാബേസും ഉപയോക്താവും എപ്പോഴും സമ്മതിക്കുന്നില്ല

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

വികസന സമയത്ത്, പ്രത്യേകിച്ച് നോൺ-ബ്ലോക്കിംഗ് ലൈബ്രറികളിൽ പ്രവർത്തിക്കുമ്പോൾ, മോശം ശൈലിയും കുറഞ്ഞ വായനാക്ഷമതയും ഇടപാടുകൾ ക്രമാനുഗതമായി നടപ്പിലാക്കുന്നുവെന്ന് ഉപയോക്താക്കളെ വിശ്വസിക്കാൻ ഇടയാക്കും, വാസ്തവത്തിൽ അവ ഏത് ക്രമത്തിലും ഡാറ്റാബേസിൽ എത്താം.

ഒറ്റനോട്ടത്തിൽ, ചുവടെയുള്ള പ്രോഗ്രാമിൽ, T1, T2 എന്നിവ തുടർച്ചയായി വിളിക്കപ്പെടുന്നു, എന്നാൽ ഈ ഫംഗ്‌ഷനുകൾ തടയുന്നില്ലെങ്കിൽ, ഫലം ഉടനടി ഫോമിൽ തിരികെ നൽകുക വാഗ്ദാനം ചെയ്യുന്നു, തുടർന്ന് കോളുകളുടെ ക്രമം അവർ ഡാറ്റാബേസിൽ പ്രവേശിച്ച നിമിഷങ്ങളാൽ നിർണ്ണയിക്കപ്പെടും:

ഫലം1 = T1() // യഥാർത്ഥ ഫലങ്ങൾ വാഗ്ദാനങ്ങളാണ്
ഫലം2 = T2()

ആറ്റോമിസിറ്റി ആവശ്യമാണെങ്കിൽ (അതായത്, ഒന്നുകിൽ എല്ലാ പ്രവർത്തനങ്ങളും പൂർത്തിയാക്കുകയോ അല്ലെങ്കിൽ നിർത്തലാക്കുകയോ വേണം) കൂടാതെ ക്രമം പ്രധാനമാണെങ്കിൽ, T1, T2 പ്രവർത്തനങ്ങൾ ഒരൊറ്റ ഇടപാടിനുള്ളിൽ നടത്തണം.

ആപ്ലിക്കേഷൻ-ലെവൽ ഷാർഡിംഗ് അപ്ലിക്കേഷന് പുറത്തേക്ക് നീക്കാൻ കഴിയും

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

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

ആപ്ലിക്കേഷൻ സെർവറുകൾ ഷാർഡിംഗ് സേവനത്തിൽ നിന്ന് വേർതിരിക്കുന്ന ഒരു ആർക്കിടെക്ചറിന്റെ ഉദാഹരണം

ഒരു പ്രത്യേക സേവനത്തിലേക്ക് ഷാർഡിംഗ് നീക്കുന്നത് ആപ്ലിക്കേഷനുകൾ വീണ്ടും വിന്യസിക്കാതെ തന്നെ വ്യത്യസ്ത ഷാർഡിംഗ് തന്ത്രങ്ങൾ ഉപയോഗിക്കാനുള്ള കഴിവ് വർദ്ധിപ്പിക്കുന്നു. വിറ്റെസ് ആപ്ലിക്കേഷൻ തലത്തിൽ അത്തരമൊരു ഷാർഡിംഗ് സിസ്റ്റത്തിന്റെ ഒരു ഉദാഹരണമാണ്. Vitess MySQL-ന് തിരശ്ചീനമായ ഷാർഡിംഗ് നൽകുകയും MySQL പ്രോട്ടോക്കോൾ വഴി ഇതിലേക്ക് കണക്റ്റുചെയ്യാൻ ക്ലയന്റുകളെ അനുവദിക്കുകയും ചെയ്യുന്നു. പരസ്പരം ഒന്നും അറിയാത്ത വ്യത്യസ്ത MySQL നോഡുകളായി സിസ്റ്റം ഡാറ്റയെ വിഭജിക്കുന്നു.

ഓട്ടോഇൻക്രിമെന്റിംഗ് അപകടകരമാണ്

പ്രാഥമിക കീകൾ സൃഷ്ടിക്കുന്നതിനുള്ള ഒരു പൊതു മാർഗമാണ് AUTOINCREMENT. ഐഡി ജനറേറ്ററുകളായി ഡാറ്റാബേസുകൾ ഉപയോഗിക്കുമ്പോൾ പലപ്പോഴും കേസുകളുണ്ട്, കൂടാതെ ഡാറ്റാബേസിൽ ഐഡന്റിഫയറുകൾ സൃഷ്ടിക്കാൻ രൂപകൽപ്പന ചെയ്ത പട്ടികകൾ അടങ്ങിയിരിക്കുന്നു. ഓട്ടോ-ഇൻക്രിമെന്റിംഗ് ഉപയോഗിച്ച് പ്രാഥമിക കീകൾ സൃഷ്ടിക്കുന്നത് അനുയോജ്യമല്ലാത്തതിന് നിരവധി കാരണങ്ങളുണ്ട്:

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

ഒരു സമീപനം തീരുമാനിക്കുന്നതിന് മുമ്പ്, ഇൻഡെക്സിംഗ്, പാർട്ടീഷനിംഗ്, ഷാർഡിംഗ് എന്നിവയിൽ യാന്ത്രിക-വർദ്ധന ഐഡികളുടെയും UUID-കളുടെയും സ്വാധീനം പരിഗണിക്കുക.

പഴകിയ ഡാറ്റ ഉപയോഗപ്രദമാകും കൂടാതെ ലോക്കിംഗ് ആവശ്യമില്ല

മൾട്ടിവേർഷൻ കൺകറൻസി കൺട്രോൾ (എംവിസിസി) മുകളിൽ സംക്ഷിപ്തമായി ചർച്ച ചെയ്ത പല സ്ഥിരത ആവശ്യകതകളും നടപ്പിലാക്കുന്നു. ചില ഡാറ്റാബേസുകൾ (ഉദാഹരണത്തിന്, പോസ്റ്റ്ഗ്രെസ്, സ്പാനർ) സ്നാപ്പ്ഷോട്ടുകൾ ഉപയോഗിച്ച് ഇടപാടുകൾ "ഫീഡ്" ചെയ്യാൻ MVCC ഉപയോഗിക്കുന്നു - ഡാറ്റാബേസിന്റെ പഴയ പതിപ്പുകൾ. സ്ഥിരത ഉറപ്പാക്കാൻ സ്‌നാപ്പ്‌ഷോട്ട് ഇടപാടുകൾ പരമ്പരയാക്കാനും കഴിയും. ഒരു പഴയ സ്നാപ്പ്ഷോട്ടിൽ നിന്ന് വായിക്കുമ്പോൾ, കാലഹരണപ്പെട്ട ഡാറ്റ വായിക്കുന്നു.

അൽപ്പം പഴകിയ ഡാറ്റ വായിക്കുന്നത് ഉപയോഗപ്രദമാകും, ഉദാഹരണത്തിന്, ഡാറ്റയിൽ നിന്ന് അനലിറ്റിക്‌സ് സൃഷ്‌ടിക്കുമ്പോഴോ ഏകദേശ മൊത്ത മൂല്യങ്ങൾ കണക്കാക്കുമ്പോഴോ.

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

പസഫിക് സമുദ്രത്തിന്റെ മറുവശത്ത് ഏറ്റവും പുതിയ പതിപ്പ് ലഭ്യമാണെങ്കിലും, 5 സെക്കൻഡ് കാലഹരണപ്പെട്ട പ്രാദേശിക പകർപ്പിൽ നിന്നുള്ള ഡാറ്റ ആപ്ലിക്കേഷൻ സെർവർ വായിക്കുന്നു.

DBMS-കൾ പഴയ പതിപ്പുകൾ സ്വയമേവ ശുദ്ധീകരിക്കുകയും ചില സന്ദർഭങ്ങളിൽ, അഭ്യർത്ഥന പ്രകാരം ഇത് ചെയ്യാൻ നിങ്ങളെ അനുവദിക്കുകയും ചെയ്യുന്നു. ഉദാഹരണത്തിന്, Postgres ഉപയോക്താക്കളെ ചെയ്യാൻ അനുവദിക്കുന്നു VACUUM അഭ്യർത്ഥന പ്രകാരം, കൂടാതെ ആനുകാലികമായി ഈ പ്രവർത്തനം സ്വയമേവ നിർവഹിക്കുന്നു. ഒരു മണിക്കൂറിലധികം പഴക്കമുള്ള സ്‌നാപ്പ്‌ഷോട്ടുകൾ ഒഴിവാക്കാൻ സ്‌പാനർ ഒരു മാലിന്യ ശേഖരണം നടത്തുന്നു.

ഏത് സമയ സ്രോതസ്സുകളും വക്രീകരണത്തിന് വിധേയമാണ്

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

സിൻക്രൊണൈസേഷനായി എൻടിപി സെർവറുകൾ ഉപയോഗിക്കുന്നു, എന്നാൽ സമന്വയ പ്രക്രിയ തന്നെ നെറ്റ്‌വർക്ക് കാലതാമസത്തിന് വിധേയമാണ്. ഒരേ ഡാറ്റാ സെന്ററിൽ ഒരു NTP സെർവറുമായി സമന്വയിപ്പിക്കാൻ പോലും കുറച്ച് സമയമെടുക്കും. ഒരു പൊതു NTP സെർവറുമായി പ്രവർത്തിക്കുന്നത് ഇതിലും വലിയ വികലതയ്ക്ക് കാരണമാകുമെന്ന് വ്യക്തമാണ്.

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

ആപ്ലിക്കേഷനുകളും ഡാറ്റാബേസുകളും പലപ്പോഴും വ്യത്യസ്ത മെഷീനുകളിലാണ് (വ്യത്യസ്ത ഡാറ്റാ സെന്ററുകളിലല്ലെങ്കിൽ) സ്ഥിതി ചെയ്യുന്നത് സ്ഥിതി കൂടുതൽ വഷളാക്കുന്നു. അതിനാൽ, വ്യത്യസ്ത മെഷീനുകളിൽ വിതരണം ചെയ്യുന്ന ഡിബി നോഡുകളിൽ മാത്രമല്ല സമയം വ്യത്യാസപ്പെടും. ആപ്ലിക്കേഷൻ സെർവറിലും ഇത് വ്യത്യസ്തമായിരിക്കും.

Google TrueTime തികച്ചും വ്യത്യസ്തമായ ഒരു സമീപനമാണ് സ്വീകരിക്കുന്നത്. ഈ ദിശയിലുള്ള ഗൂഗിളിന്റെ പുരോഗതി ആറ്റോമിക്, ജിപിഎസ് ക്ലോക്കുകളിലേക്കുള്ള നിസ്സാരമായ പരിവർത്തനത്തിലൂടെ വിശദീകരിക്കപ്പെട്ടതായി മിക്ക ആളുകളും വിശ്വസിക്കുന്നു, എന്നാൽ ഇത് വലിയ ചിത്രത്തിന്റെ ഒരു ഭാഗം മാത്രമാണ്. TrueTime പ്രവർത്തിക്കുന്നത് ഇങ്ങനെയാണ്:

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

സ്പാനർ ഘടകങ്ങൾ TrueTime ഉപയോഗിക്കുന്നു, അവിടെ TT.now() ഒരു ഇടവേള നൽകുന്നു, അതിനാൽ നിലവിലെ സമയം ഒരു നിശ്ചിത പോയിന്റ് കടന്നുപോയെന്ന് ഉറപ്പുനൽകുന്ന ഘട്ടം വരെ സ്പാനർ ഉറങ്ങുന്നു.

നിലവിലെ സമയം നിർണ്ണയിക്കുന്നതിൽ കുറഞ്ഞ കൃത്യത അർത്ഥമാക്കുന്നത് സ്പാനർ പ്രവർത്തനങ്ങളുടെ കാലയളവിലെ വർദ്ധനവും പ്രകടനത്തിലെ കുറവുമാണ്. അതുകൊണ്ടാണ് പൂർണ്ണമായും കൃത്യമായ ഒരു വാച്ച് നേടുന്നത് അസാധ്യമാണെങ്കിലും സാധ്യമായ ഏറ്റവും ഉയർന്ന കൃത്യത നിലനിർത്തേണ്ടത് പ്രധാനമാണ്.

കാലതാമസത്തിന് നിരവധി അർത്ഥങ്ങളുണ്ട്

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

ഒരു നിർദ്ദിഷ്ട ഇടപാടിനായി പ്രകടന ആവശ്യകതകൾ വിലയിരുത്തണം

ചിലപ്പോൾ ഒരു DBMS-ന്റെ പ്രകടന സവിശേഷതകളും അതിന്റെ പരിമിതികളും എഴുതുന്നത്/വായന ത്രൂപുട്ട്, ലേറ്റൻസി എന്നിവയുടെ അടിസ്ഥാനത്തിൽ വ്യക്തമാക്കിയിട്ടുണ്ട്. ഇത് പ്രധാന സിസ്റ്റം പാരാമീറ്ററുകളുടെ പൊതുവായ ഒരു അവലോകനം നൽകുന്നു, എന്നാൽ ഒരു പുതിയ DBMS-ന്റെ പ്രകടനം വിലയിരുത്തുമ്പോൾ, കൂടുതൽ സമഗ്രമായ ഒരു സമീപനം, നിർണ്ണായക പ്രവർത്തനങ്ങൾ (ഓരോ അന്വേഷണത്തിനും കൂടാതെ/അല്ലെങ്കിൽ ഇടപാടുകൾക്കും) പ്രത്യേകം വിലയിരുത്തുക എന്നതാണ്. ഉദാഹരണങ്ങൾ:

• ടേബിൾ X-ലേക്ക് (50 ദശലക്ഷം വരികളുള്ള) ഒരു പുതിയ വരി ചേർക്കുമ്പോൾ, നിർദ്ദിഷ്ട നിയന്ത്രണങ്ങളും അനുബന്ധ പട്ടികകളിൽ റോ പാഡിംഗും ഉപയോഗിച്ച് ത്രൂപുട്ടും ലേറ്റൻസിയും എഴുതുക.
• ഒരു നിശ്ചിത ഉപയോക്താവിന്റെ സുഹൃത്തുക്കളുടെ സുഹൃത്തുക്കളുടെ ശരാശരി എണ്ണം 500 ആയിരിക്കുമ്പോൾ പ്രദർശിപ്പിക്കുന്നതിലെ കാലതാമസം.
• ഒരു മണിക്കൂറിൽ X എൻട്രികൾ ഉപയോഗിച്ച് ഉപയോക്താവ് മറ്റ് 100 ഉപയോക്താക്കളെ പിന്തുടരുമ്പോൾ, ഒരു ഉപയോക്താവിന്റെ ചരിത്രത്തിൽ നിന്ന് മികച്ച 500 എൻട്രികൾ വീണ്ടെടുക്കുന്നതിനുള്ള കാലതാമസം.

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

ഓരോ പ്രവർത്തനത്തിനും അളവുകൾ ശേഖരിക്കുമ്പോൾ ഉയർന്ന കാർഡിനാലിറ്റിയെക്കുറിച്ച് അറിഞ്ഞിരിക്കുക. ഉയർന്ന പവർ ഡീബഗ്ഗിംഗ് ഡാറ്റ നേടുന്നതിന് ലോഗുകൾ, ഇവന്റ് ശേഖരണം അല്ലെങ്കിൽ വിതരണം ചെയ്ത ട്രെയ്‌സിംഗ് ഉപയോഗിക്കുക. ലേഖനത്തിൽ "ലേറ്റൻസി ഡീബഗ് ചെയ്യണോ?» കാലതാമസം വരുത്തുന്ന ഡീബഗ്ഗിംഗ് രീതികൾ നിങ്ങൾക്ക് പരിചയപ്പെടാം.

നെസ്റ്റഡ് ഇടപാടുകൾ അപകടകരമാണ്

എല്ലാ ഡിബിഎംഎസും നെസ്റ്റഡ് ഇടപാടുകളെ പിന്തുണയ്ക്കുന്നില്ല, എന്നാൽ അവ ചെയ്യുമ്പോൾ, അത്തരം ഇടപാടുകൾ അപ്രതീക്ഷിത പിശകുകൾക്ക് കാരണമാകും, അത് എല്ലായ്പ്പോഴും കണ്ടെത്താൻ എളുപ്പമല്ല (അതായത്, ഏതെങ്കിലും തരത്തിലുള്ള അപാകതകൾ ഉണ്ടെന്ന് വ്യക്തമാണ്).

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

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

with newTransaction():
   Accounts.create("609-543-222")
   with newTransaction():
       Accounts.create("775-988-322")
       throw Rollback();

മുകളിലെ കോഡിന്റെ ഔട്ട്പുട്ട് എന്തായിരിക്കും? ഇത് രണ്ട് ഇടപാടുകളും പിൻവലിക്കുമോ, അതോ ഉള്ളിലുള്ളത് മാത്രമാണോ? നമുക്കായി ഇടപാടുകൾ സൃഷ്ടിക്കുന്നത് ഉൾക്കൊള്ളുന്ന ലൈബ്രറികളുടെ ഒന്നിലധികം ലെയറുകളെ ഞങ്ങൾ ആശ്രയിക്കുകയാണെങ്കിൽ എന്ത് സംഭവിക്കും? അത്തരം കേസുകൾ തിരിച്ചറിയാനും മെച്ചപ്പെടുത്താനും നമുക്ക് കഴിയുമോ?

ഒന്നിലധികം പ്രവർത്തനങ്ങളുള്ള ഒരു ഡാറ്റ ലെയർ സങ്കൽപ്പിക്കുക (ഉദാ. newAccount) ഇതിനകം തന്നെ സ്വന്തം ഇടപാടുകളിൽ നടപ്പിലാക്കിയിട്ടുണ്ട്. സ്വന്തം ഇടപാടിൽ പ്രവർത്തിക്കുന്ന ഉയർന്ന തലത്തിലുള്ള ബിസിനസ് ലോജിക്കിന്റെ ഭാഗമായി നിങ്ങൾ അവ പ്രവർത്തിപ്പിച്ചാൽ എന്ത് സംഭവിക്കും? ഈ കേസിൽ ഒറ്റപ്പെടലും സ്ഥിരതയും എന്തായിരിക്കും?

function newAccount(id string) {
  with newTransaction():
      Accounts.create(id)
}

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

function newAccount(id string) {
   Accounts.create(id)
}
// In main application:
with newTransaction():
   // Read some data from database for configuration.
   // Generate an ID from the ID service.
   Accounts.create(id)
   Uploads.create(id) // create upload queue for the user.

ഇടപാടുകൾ അപേക്ഷയുടെ അവസ്ഥയുമായി ബന്ധിപ്പിക്കരുത്

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

var seq int64
with newTransaction():
    newSeq := atomic.Increment(&seq)
    Entries.query(newSeq)
    // Other operations...

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

ക്വറി പ്ലാനർമാർക്ക് ഒരു ഡാറ്റാബേസിനെക്കുറിച്ച് നിങ്ങളോട് ധാരാളം കാര്യങ്ങൾ പറയാൻ കഴിയും

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

SELECT * FROM articles where author = "rakyll" order by title;

ഫലങ്ങൾ രണ്ട് തരത്തിൽ വീണ്ടെടുക്കാം:

• മുഴുവൻ ടേബിൾ സ്കാൻ: നിങ്ങൾക്ക് പട്ടികയിലെ ഓരോ എൻട്രിയും നോക്കാനും ലേഖനങ്ങൾ പൊരുത്തപ്പെടുന്ന രചയിതാവിന്റെ പേര് നൽകാനും കഴിയും, തുടർന്ന് അവ ഓർഡർ ചെയ്യാവുന്നതാണ്.
• സൂചിക സ്കാൻ: പൊരുത്തപ്പെടുന്ന ഐഡികൾ കണ്ടെത്താനും ആ വരികൾ നേടാനും തുടർന്ന് ഓർഡർ ചെയ്യാനും നിങ്ങൾക്ക് ഒരു സൂചിക ഉപയോഗിക്കാം.

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

അന്വേഷണ പ്ലാനർ അവതരിപ്പിക്കുന്ന ചില മെട്രിക്കുകൾ ശബ്ദത്തിന് വിധേയമായേക്കാം (പ്രത്യേകിച്ച് ലേറ്റൻസി അല്ലെങ്കിൽ സിപിയു സമയം കണക്കാക്കുമ്പോൾ). നിർവ്വഹണ പാത കണ്ടെത്തുന്നതിനും ട്രാക്കുചെയ്യുന്നതിനുമുള്ള ടൂളുകളാണ് ഷെഡ്യൂളർമാർക്കുള്ള നല്ലൊരു കൂട്ടിച്ചേർക്കൽ. അത്തരം പ്രശ്നങ്ങൾ കണ്ടുപിടിക്കാൻ അവർ നിങ്ങളെ അനുവദിക്കുന്നു (അയ്യോ, എല്ലാ DBMS-കളും അത്തരം ഉപകരണങ്ങൾ നൽകുന്നില്ല).

ഓൺലൈൻ മൈഗ്രേഷൻ ബുദ്ധിമുട്ടാണ്, പക്ഷേ സാധ്യമാണ്

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

വ്യത്യസ്ത ഓൺലൈൻ മൈഗ്രേഷൻ മോഡലുകളുണ്ട്. അവയിലൊന്ന് ഇതാ:

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

കൂടുതൽ വിവരങ്ങൾക്ക്, ബന്ധപ്പെടാൻ ഞാൻ ശുപാർശ ചെയ്യുന്നു ലേഖനം, ഈ മോഡലിനെ അടിസ്ഥാനമാക്കിയുള്ള സ്ട്രൈപ്പിന്റെ മൈഗ്രേഷൻ തന്ത്രത്തെ വിശദീകരിക്കുന്നു.

ഡാറ്റാബേസിലെ ഗണ്യമായ വർദ്ധനവ് പ്രവചനാതീതമായ വർദ്ധനവിന് കാരണമാകുന്നു

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

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

പങ്ക് € |

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

പി.എസ്

ഞങ്ങളുടെ ബ്ലോഗിലും വായിക്കുക:

• «ഡാറ്റാബേസുകളും കുബർനെറ്റുകളും (അവലോകനവും വീഡിയോ റിപ്പോർട്ടും)";
• «വിതരണം ചെയ്‌ത ട്രെയ്‌സിംഗ്: ഞങ്ങൾ എല്ലാം തെറ്റാണ് ചെയ്തത്";
• «സർവീസ് മെഷ്: ഏറ്റവും ചൂടേറിയ സാങ്കേതികവിദ്യയെക്കുറിച്ച് ഓരോ സോഫ്റ്റ്‌വെയർ എഞ്ചിനീയറും അറിഞ്ഞിരിക്കേണ്ട കാര്യങ്ങൾ".

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