HighLoad++, Mikhail Tyulenev (MongoDB): കാര്യകാരണമായ സ്ഥിരത: സിദ്ധാന്തം മുതൽ പ്രാക്ടീസ് വരെ

അടുത്ത ഹൈലോഡ്++ കോൺഫറൻസ് 6 ഏപ്രിൽ 7, 2020 തീയതികളിൽ സെൻ്റ് പീറ്റേഴ്‌സ്ബർഗിൽ നടക്കും.
വിശദാംശങ്ങളും ടിക്കറ്റുകളും ബന്ധം. ഹൈലോഡ്++ സൈബീരിയ 2019. ഹാൾ "ക്രാസ്നോയാർസ്ക്". ജൂൺ 25, 12:00. തീസുകളും അവതരണം.

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

മിഖായേൽ ത്യുലെനെവ് (ഇനി മുതൽ MT എന്ന് വിളിക്കപ്പെടുന്നു): – ഞാൻ കാര്യകാരണമായ സ്ഥിരതയെക്കുറിച്ച് സംസാരിക്കും - ഇത് ഞങ്ങൾ മോംഗോഡിബിയിൽ പ്രവർത്തിച്ച ഒരു സവിശേഷതയാണ്. ഞാൻ ഒരു കൂട്ടം ഡിസ്ട്രിബ്യൂട്ടഡ് സിസ്റ്റങ്ങളിൽ ജോലി ചെയ്യുന്നു, ഞങ്ങൾ ഇത് ഏകദേശം രണ്ട് വർഷം മുമ്പ് ചെയ്തു.

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

അക്കാദമിക് റിസർച്ചിൻ്റെ ഉപഭോക്താക്കൾ എന്ന നിലയിൽ ഞങ്ങൾ അതിൽ നിന്ന് എന്തെങ്കിലും തയ്യാറാക്കുന്നത് എങ്ങനെയെന്ന് ഞാൻ സംസാരിക്കും, അത് ഉപയോഗിക്കാൻ സൗകര്യപ്രദവും സുരക്ഷിതവുമായ ഒരു റെഡിമെയ്ഡ് വിഭവമായി ഞങ്ങളുടെ ഉപയോക്താക്കൾക്ക് അവതരിപ്പിക്കാനാകും.

കാര്യകാരണമായ സ്ഥിരത. നമുക്ക് ആശയങ്ങൾ നിർവചിക്കാം

ആരംഭിക്കുന്നതിന്, കാര്യകാരണപരമായ സ്ഥിരത എന്താണെന്ന് പൊതുവായി പറയാൻ ഞാൻ ആഗ്രഹിക്കുന്നു. രണ്ട് കഥാപാത്രങ്ങളുണ്ട് - ലിയോനാർഡും പെന്നിയും (ടിവി സീരീസ് "ദി ബിഗ് ബാംഗ് തിയറി"):

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

വാസ്തവത്തിൽ, ഇവ ഡാറ്റാബേസിൻ്റെ വളരെ നിസ്സാരമല്ലാത്ത പ്രോപ്പർട്ടികൾ ആണ് - വളരെ കുറച്ച് ആളുകൾ അവരെ പിന്തുണയ്ക്കുന്നു. നമുക്ക് മോഡലുകളിലേക്ക് പോകാം.

സ്ഥിരത മോഡലുകൾ

ഡാറ്റാബേസുകളിലെ സ്ഥിരത മോഡൽ എന്താണ്? ഉപഭോക്താവിന് എന്ത് ഡാറ്റ സ്വീകരിക്കാമെന്നും ഏത് ക്രമത്തിലാണെന്നും ഒരു വിതരണം ചെയ്ത സിസ്റ്റം നൽകുന്ന ചില ഗ്യാരണ്ടികൾ ഇവയാണ്.

തത്വത്തിൽ, എല്ലാ സ്ഥിരത മോഡലുകളും പ്രവർത്തിക്കുന്ന ഒരു സിസ്റ്റവുമായി ഒരു ഡിസ്ട്രിബ്യൂഡ് സിസ്റ്റം എത്രത്തോളം സമാനമാണ്, ഉദാഹരണത്തിന്, ഒരു ലാപ്‌ടോപ്പിലെ ഒരു നോഡിൽ. ആയിരക്കണക്കിന് ജിയോ-ഡിസ്ട്രിബ്യൂട്ടഡ് "നോഡുകളിൽ" പ്രവർത്തിക്കുന്ന ഒരു സിസ്റ്റം ലാപ്‌ടോപ്പിന് സമാനമാണ്, അതിൽ ഈ എല്ലാ ഗുണങ്ങളും തത്വത്തിൽ യാന്ത്രികമായി നടപ്പിലാക്കുന്നു.

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

ശക്തമായ മോഡൽ

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

ഇത് ഡാറ്റാബേസിലെ എല്ലാ ഇവൻ്റുകളുടെയും ആഗോള ക്രമം സൃഷ്ടിക്കുന്നു. ഇത് വളരെ ശക്തമായ സ്ഥിരതയുള്ള വസ്തുവാണ്, ഇത് പൊതുവെ വളരെ ചെലവേറിയതാണ്. എന്നിരുന്നാലും, ഇത് വളരെ നന്നായി പിന്തുണയ്ക്കുന്നു. ഇത് വളരെ ചെലവേറിയതും മന്ദഗതിയിലുള്ളതുമാണ് - ഇത് വളരെ അപൂർവമായി മാത്രമേ ഉപയോഗിക്കുന്നുള്ളൂ. ഇതിനെ ഉയരാനുള്ള കഴിവ് എന്ന് വിളിക്കുന്നു.

സ്‌പാനറിൽ പിന്തുണയ്‌ക്കുന്ന മറ്റൊരു ശക്തമായ പ്രോപ്പർട്ടി ഉണ്ട് - ബാഹ്യ സ്ഥിരത എന്ന് വിളിക്കുന്നു. ഞങ്ങൾ അതിനെക്കുറിച്ച് കുറച്ച് കഴിഞ്ഞ് സംസാരിക്കും.

കൌശൽ

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

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

ഒടുവിൽ

മൂന്നാമത്തെ മോഡൽ ഈവൻ്റ് കൺസിസ്റ്റൻസിയാണ്. എല്ലാ വിതരണ സംവിധാനങ്ങളും പിന്തുണയ്‌ക്കുന്നത് ഇതാണ്, ഏറ്റവും കുറഞ്ഞ മാതൃക. അതിനർത്ഥം ഇനിപ്പറയുന്നവയാണ്: നമുക്ക് ഡാറ്റയിൽ ചില മാറ്റങ്ങൾ വരുമ്പോൾ, ചില ഘട്ടങ്ങളിൽ അവ സ്ഥിരത കൈവരിക്കുന്നു.

അത്തരമൊരു നിമിഷത്തിൽ അവൾ ഒന്നും പറയുന്നില്ല, അല്ലാത്തപക്ഷം അവൾ ബാഹ്യ സ്ഥിരതയായി മാറും - ഇത് തികച്ചും വ്യത്യസ്തമായ ഒരു കഥയായിരിക്കും. എന്നിരുന്നാലും, ഇത് വളരെ ജനപ്രിയമായ ഒരു മോഡലാണ്, ഏറ്റവും സാധാരണമാണ്. ഡിഫോൾട്ടായി, ഡിസ്ട്രിബ്യൂഡ് സിസ്റ്റങ്ങളുടെ എല്ലാ ഉപയോക്താക്കളും അന്തിമ സ്ഥിരത ഉപയോഗിക്കുന്നു.

ചില താരതമ്യ ഉദാഹരണങ്ങൾ നൽകാൻ ഞാൻ ആഗ്രഹിക്കുന്നു:

ഈ അമ്പുകൾ എന്താണ് അർത്ഥമാക്കുന്നത്?

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

CAP സിദ്ധാന്തം

സ്ഥിരത, ലഭ്യത എന്നീ വാക്കുകൾ കാണുമ്പോൾ നിങ്ങളുടെ മനസ്സിലേക്ക് വരുന്നത് എന്താണ്? അത് ശരിയാണ് - CAP സിദ്ധാന്തം! ഇപ്പോൾ ഞാൻ മിഥ്യയെ ഇല്ലാതാക്കാൻ ആഗ്രഹിക്കുന്നു ... ഇത് ഞാനല്ല - ഇത് ഒരു അത്ഭുതകരമായ ലേഖനം എഴുതിയ മാർട്ടിൻ ക്ലെപ്പ്മാൻ ആണ്.

സ്ഥിരത, ലഭ്യത, പാർട്ടീഷനുകൾ: ഏതെങ്കിലും രണ്ടെണ്ണം എടുക്കുക, നിങ്ങൾക്ക് മൂന്ന് തിരഞ്ഞെടുക്കാൻ കഴിയില്ലെന്ന് 2000-കളിൽ രൂപപ്പെടുത്തിയ ഒരു തത്വമാണ് CAP സിദ്ധാന്തം. അത് ഒരു നിശ്ചിത തത്വമായിരുന്നു. കുറച്ച് വർഷങ്ങൾക്ക് ശേഷം ഗിൽബെർട്ടും ലിഞ്ചും ഇത് ഒരു സിദ്ധാന്തമായി തെളിയിച്ചു. പിന്നീട് ഇത് ഒരു മന്ത്രമായി ഉപയോഗിക്കാൻ തുടങ്ങി - സിസ്റ്റങ്ങളെ CA, CP, AP എന്നിങ്ങനെ വിഭജിക്കാൻ തുടങ്ങി.

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

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

ഇതെല്ലാം എന്തിനു വേണ്ടിയാണ്? മാത്രമല്ല, CAP സിദ്ധാന്തം കൃത്യമായി തെളിയിക്കപ്പെട്ട രൂപത്തിൽ പ്രായോഗികമായി ബാധകമല്ല, അപൂർവ്വമായി മാത്രമേ ഉപയോഗിക്കാറുള്ളൂ. സൈദ്ധാന്തിക രൂപത്തിൽ, അത് എങ്ങനെയെങ്കിലും എല്ലാം പരിമിതപ്പെടുത്തുന്നു. ഇത് അവബോധപൂർവ്വം ശരിയായ ഒരു പ്രത്യേക തത്ത്വമായി മാറുന്നു, പക്ഷേ പൊതുവെ തെളിയിക്കപ്പെട്ടിട്ടില്ല.

കാര്യകാരണമായ സ്ഥിരതയാണ് ഏറ്റവും ശക്തമായ മാതൃക

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

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

മോംഗോഡിബി ആന്തരിക അടുക്കള

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

മോംഗോഡിബി (ഇനി "മോംഗോഡിബി" എന്ന് വിളിക്കുന്നു) തിരശ്ചീന സ്കെയിലിംഗിനെ പിന്തുണയ്ക്കുന്ന ഒരു വിതരണ സംവിധാനമാണ്, അതായത് ഷാർഡിംഗ്; ഓരോ ഷാർഡിനുള്ളിലും ഇത് ഡാറ്റ റിഡൻഡൻസിയെ പിന്തുണയ്ക്കുന്നു, അതായത്, അനുകരണം.

മോംഗോഡിബിയിലെ (ഒരു റിലേഷണൽ ഡാറ്റാബേസല്ല) ഷാർഡിംഗ് ഓട്ടോമാറ്റിക് ബാലൻസിങ് നടത്തുന്നു, അതായത്, ഓരോ ഡോക്യുമെൻ്റുകളുടെയും (അല്ലെങ്കിൽ റിലേഷണൽ ഡാറ്റയുടെ അടിസ്ഥാനത്തിൽ "പട്ടിക") കഷണങ്ങളായി വിഭജിക്കപ്പെടുന്നു, കൂടാതെ സെർവർ അവയെ യാന്ത്രികമായി ഷാർഡുകൾക്കിടയിൽ നീക്കുന്നു.

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

മറ്റൊരു പ്രധാന കാര്യം: മോംഗോഡിബി ഒരൊറ്റ മാസ്റ്ററാണ്. ഒരു പ്രാഥമികം ഉണ്ട് - അതിൽ അടങ്ങിയിരിക്കുന്ന കീകളെ പിന്തുണയ്ക്കുന്ന റെക്കോർഡുകൾ ഇതിന് എടുക്കാം. നിങ്ങൾക്ക് മൾട്ടി-മാസ്റ്റർ റൈറ്റ് ചെയ്യാൻ കഴിയില്ല.

ഞങ്ങൾ 4.2 റിലീസ് ചെയ്തു - പുതിയ രസകരമായ കാര്യങ്ങൾ അവിടെ പ്രത്യക്ഷപ്പെട്ടു. പ്രത്യേകിച്ചും, അവർ ലൂസീൻ - സെർച്ച് - അതായത് എക്സിക്യൂട്ടബിൾ ജാവ നേരിട്ട് മോംഗോയിലേക്ക് തിരുകുകയും അവിടെ എലാസ്റ്റികയിലെ പോലെ തന്നെ ലുസീൻ വഴി തിരയലുകൾ നടത്തുകയും ചെയ്തു.

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

ചേരുവകൾ കാരണമായ സ്ഥിരത

ഈ വിഷയത്തിൽ പ്രസിദ്ധീകരിച്ച 230 ഓളം ലേഖനങ്ങൾ ഞാൻ കണക്കാക്കി - ലെസ്ലി ലാംപെർട്ടിൽ നിന്ന്. ഇപ്പോൾ എൻ്റെ ഓർമ്മയിൽ നിന്ന് ഈ മെറ്റീരിയലുകളുടെ ചില ഭാഗങ്ങൾ ഞാൻ നിങ്ങളെ അറിയിക്കും.

1970-കളിൽ എഴുതിയ ലെസ്ലി ലാംപെർട്ടിൻ്റെ ഒരു ലേഖനത്തിൽ നിന്നാണ് ഇതെല്ലാം ആരംഭിച്ചത്. നിങ്ങൾക്ക് കാണാനാകുന്നതുപോലെ, ഈ വിഷയത്തിൽ ചില ഗവേഷണങ്ങൾ ഇപ്പോഴും നടന്നുകൊണ്ടിരിക്കുന്നു. വിതരണം ചെയ്ത സിസ്റ്റങ്ങളുടെ വികസനവുമായി ബന്ധപ്പെട്ട് ഇപ്പോൾ കാര്യകാരണമായ സ്ഥിരത താൽപ്പര്യം അനുഭവിക്കുന്നു.

നിയന്ത്രണങ്ങൾ

എന്തൊക്കെ നിയന്ത്രണങ്ങളാണ് ഉള്ളത്? ഇത് യഥാർത്ഥത്തിൽ പ്രധാന പോയിൻ്റുകളിലൊന്നാണ്, കാരണം ഒരു ഉൽപാദന സംവിധാനം ഏർപ്പെടുത്തുന്ന നിയന്ത്രണങ്ങൾ അക്കാദമിക് ലേഖനങ്ങളിൽ നിലനിൽക്കുന്ന നിയന്ത്രണങ്ങളിൽ നിന്ന് വളരെ വ്യത്യസ്തമാണ്. അവ പലപ്പോഴും കൃത്രിമമാണ്.

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

പൊതുവേ, ഇതെല്ലാം നിയന്ത്രണങ്ങൾ ഏർപ്പെടുത്തുന്നു.

കാരണമായ സ്ഥിരത ഘടകങ്ങൾ

ഞാൻ ഇപ്പോൾ ചില ഘടകങ്ങളെക്കുറിച്ച് സംസാരിക്കും. പൊതുവെ കാര്യകാരണപരമായ സ്ഥിരത പരിഗണിക്കുകയാണെങ്കിൽ, നമുക്ക് ബ്ലോക്കുകൾ തിരഞ്ഞെടുക്കാം. ഒരു പ്രത്യേക ബ്ലോക്കിൽ പെടുന്ന സൃഷ്ടികളിൽ നിന്ന് ഞങ്ങൾ തിരഞ്ഞെടുത്തു: ഡിപൻഡൻസി ട്രാക്കിംഗ്, ക്ലോക്കുകൾ തിരഞ്ഞെടുക്കൽ, ഈ ക്ലോക്കുകൾ എങ്ങനെ പരസ്പരം സമന്വയിപ്പിക്കാം, ഞങ്ങൾ എങ്ങനെ സുരക്ഷ ഉറപ്പാക്കുന്നു - ഇത് ഞാൻ സംസാരിക്കുന്ന കാര്യങ്ങളുടെ ഏകദേശ രൂപരേഖയാണ്:

പൂർണ്ണ ആശ്രിത ട്രാക്കിംഗ്

എന്തുകൊണ്ട് അത് ആവശ്യമാണ്? അതിനാൽ ഡാറ്റ ആവർത്തിക്കുമ്പോൾ, ഓരോ റെക്കോർഡും, ഓരോ ഡാറ്റ മാറ്റവും അത് എന്ത് മാറ്റങ്ങളെ ആശ്രയിച്ചിരിക്കുന്നു എന്നതിനെക്കുറിച്ചുള്ള വിവരങ്ങൾ ഉൾക്കൊള്ളുന്നു. ഒരു റെക്കോർഡ് അടങ്ങിയിരിക്കുന്ന ഓരോ സന്ദേശത്തിലും മുമ്പത്തെ സന്ദേശങ്ങളെക്കുറിച്ചുള്ള വിവരങ്ങൾ അടങ്ങിയിരിക്കുമ്പോഴാണ് ആദ്യത്തേതും നിഷ്കളങ്കവുമായ മാറ്റം:

ഈ ഉദാഹരണത്തിൽ, ചുരുണ്ട ബ്രാക്കറ്റുകളിലെ നമ്പർ റെക്കോർഡ് നമ്പറുകളാണ്. ചിലപ്പോൾ മൂല്യങ്ങളുള്ള ഈ റെക്കോർഡുകൾ പൂർണ്ണമായും കൈമാറ്റം ചെയ്യപ്പെടുന്നു, ചിലപ്പോൾ ചില പതിപ്പുകൾ കൈമാറ്റം ചെയ്യപ്പെടുന്നു. ഓരോ മാറ്റത്തിലും മുമ്പത്തേതിനെക്കുറിച്ചുള്ള വിവരങ്ങൾ അടങ്ങിയിരിക്കുന്നു എന്നതാണ് ഏറ്റവും പ്രധാന കാര്യം (വ്യക്തമായും ഇതെല്ലാം അതിൽ തന്നെ വഹിക്കുന്നു).

എന്തുകൊണ്ടാണ് ഈ സമീപനം (മുഴുവൻ ട്രാക്കിംഗ്) ഉപയോഗിക്കേണ്ടെന്ന് ഞങ്ങൾ തീരുമാനിച്ചത്? വ്യക്തമായും, ഈ സമീപനം അപ്രായോഗികമാണ്: ഒരു സോഷ്യൽ നെറ്റ്‌വർക്കിലേക്കുള്ള ഏത് മാറ്റവും ആ സോഷ്യൽ നെറ്റ്‌വർക്കിലെ എല്ലാ മുൻ മാറ്റങ്ങളെയും ആശ്രയിച്ചിരിക്കുന്നു, ഓരോ അപ്‌ഡേറ്റിലും Facebook അല്ലെങ്കിൽ VKontakte കൈമാറുന്നു. എന്നിരുന്നാലും, ഫുൾ ഡിപൻഡൻസി ട്രാക്കിംഗിനെക്കുറിച്ച് ധാരാളം ഗവേഷണങ്ങൾ നടക്കുന്നുണ്ട് - ഇവ പ്രീ-സോഷ്യൽ നെറ്റ്‌വർക്കുകളാണ്; ചില സാഹചര്യങ്ങളിൽ ഇത് ശരിക്കും പ്രവർത്തിക്കുന്നു.

വ്യക്തമായ ഡിപൻഡൻസി ട്രാക്കിംഗ്

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

റെക്കോർഡ് 5 എന്നത് 1, 2, 3, 4 റെക്കോർഡുകളെ ആശ്രയിച്ചിരിക്കുന്നുവെന്ന് അവൾ കാണുന്നു - അതനുസരിച്ച്, മുമ്പത്തെ എല്ലാ മാറ്റങ്ങളും ഡാറ്റാബേസിലൂടെ കടന്നുപോകുമ്പോൾ, പെന്നിയുടെ ആക്‌സസ് തീരുമാനം വരുത്തിയ മാറ്റങ്ങളിലേക്ക് ക്ലയൻ്റിന് ആക്‌സസ് ലഭിക്കുന്നതിന് മുമ്പ് അവൾ കാത്തിരിക്കുന്നു.

ഇത് ഞങ്ങൾക്ക് അനുയോജ്യമല്ല, കാരണം ഇപ്പോഴും വളരെയധികം വിവരങ്ങൾ ഉണ്ട്, അത് കാര്യങ്ങൾ മന്ദഗതിയിലാക്കും. മറ്റൊരു സമീപനമുണ്ട്...

ലാംപോർട്ട് ക്ലോക്ക്

അവർ വളരെ പ്രായമുള്ളവരാണ്. ലാംപോർട്ട് ക്ലോക്ക് എന്നാൽ ഈ ഡിപൻഡൻസികൾ ഒരു സ്കെലാർ ഫംഗ്ഷനിലേക്ക് മടക്കിക്കളയുന്നു, അതിനെ ലാംപോർട്ട് ക്ലോക്ക് എന്ന് വിളിക്കുന്നു.

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

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

ഫീഡിലെ കൌണ്ടർ സമയം യുക്തിപരമായി എങ്ങനെ വർദ്ധിക്കുന്നുവെന്ന് നിങ്ങൾ കാണുന്നു:

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

* ചിലപ്പോൾ അവർ പറയുന്നത് ബിക്ക് മുമ്പാണ് എ സംഭവിച്ചത്, അതായത് ബിക്ക് മുമ്പ് എ സംഭവിച്ചു - ഇത് പൊതുവായി സംഭവിച്ച മുഴുവൻ സംഭവങ്ങളെയും ഭാഗികമായി ക്രമീകരിക്കുന്ന ഒരു നിശ്ചിത ബന്ധമാണ്.

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

വെക്റ്റർ ക്ലോക്ക്

ലാംപോർട്ട് ക്ലോക്കിൻ്റെ ലോജിക്കൽ വികസനം വെക്റ്റർ ക്ലോക്ക് ആണ്. ഇവിടെയുള്ള ഓരോ നോഡിലും അതിൻ്റേതായ പ്രത്യേക ക്ലോക്ക് അടങ്ങിയിരിക്കുന്നു, അവ ഒരു വെക്റ്ററായി കൈമാറ്റം ചെയ്യപ്പെടുന്നു എന്നതിൽ അവ വ്യത്യാസപ്പെട്ടിരിക്കുന്നു.
ഈ സാഹചര്യത്തിൽ, വെക്റ്ററിൻ്റെ സീറോത്ത് സൂചിക ഫീഡിന് ഉത്തരവാദിയാണെന്ന് നിങ്ങൾ കാണുന്നു, കൂടാതെ വെക്റ്ററിൻ്റെ ആദ്യ സൂചിക സുഹൃത്തുക്കൾക്കുള്ളതാണ് (ഈ നോഡുകളിൽ ഓരോന്നും). ഇപ്പോൾ അവ വർദ്ധിക്കും: എഴുതുമ്പോൾ "ഫീഡിൻ്റെ" പൂജ്യം സൂചിക വർദ്ധിക്കുന്നു - 1, 2, 3:

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

ഞങ്ങൾക്ക് 10 ആയിരം ഷാർഡുകൾ ഉണ്ടെങ്കിൽ, ഞങ്ങൾ അത് കംപ്രസ്സുചെയ്യുകയോ മറ്റെന്തെങ്കിലും കൊണ്ടുവരികയോ ചെയ്താലും 10 ആയിരം ഘടകങ്ങൾ കൈമാറാൻ കഴിയില്ല - പേലോഡ് ഈ മുഴുവൻ വെക്റ്ററിൻ്റെ അളവിനേക്കാൾ നിരവധി മടങ്ങ് ചെറുതായിരിക്കും. അതിനാൽ, ഞങ്ങളുടെ ഹൃദയവും പല്ലും കടിച്ചുകീറി, ഞങ്ങൾ ഈ സമീപനം ഉപേക്ഷിച്ച് മറ്റൊന്നിലേക്ക് നീങ്ങി.

സ്പാനർ ട്രൂടൈം. ആറ്റോമിക് ക്ലോക്ക്

സ്പാനറിനെക്കുറിച്ച് ഒരു കഥയുണ്ടാകുമെന്ന് ഞാൻ പറഞ്ഞു. ഇത് 21-ാം നൂറ്റാണ്ടിൽ നിന്നുള്ള ഒരു രസകരമായ കാര്യമാണ്: ആറ്റോമിക് ക്ലോക്കുകൾ, ജിപിഎസ് സമന്വയം.

എന്താണ് ആശയം? "സ്പാനർ" എന്നത് അടുത്തിടെ ആളുകൾക്ക് ലഭ്യമായ ഒരു Google സിസ്റ്റമാണ് (അവർ അതിൽ SQL ചേർത്തു). ഓരോ ഇടപാടിനും കുറച്ച് സമയ സ്റ്റാമ്പ് ഉണ്ട്. സമയം സമന്വയിപ്പിച്ചതിനാൽ*, ഓരോ ഇവൻ്റിനും ഒരു പ്രത്യേക സമയം നൽകാം - ആറ്റോമിക് ക്ലോക്കുകൾക്ക് ഒരു കാത്തിരിപ്പ് സമയമുണ്ട്, അതിനുശേഷം മറ്റൊരു സമയം "സംഭവിക്കുമെന്ന്" ഉറപ്പുനൽകുന്നു.

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

* ലാംപാർട്ട് ക്ലോക്കുകളുടെ പ്രധാന പ്രശ്നം ഇതാണ് - വിതരണം ചെയ്ത സിസ്റ്റങ്ങളിൽ അവ ഒരിക്കലും സിൻക്രണസ് അല്ല. അവയ്ക്ക് വ്യതിചലിക്കാൻ കഴിയും; NTP-യിൽ പോലും, അവ ഇപ്പോഴും നന്നായി പ്രവർത്തിക്കുന്നില്ല. "സ്പാനറിന്" ഒരു ആറ്റോമിക് ക്ലോക്കും സമന്വയവും മൈക്രോസെക്കൻഡുകളാണെന്ന് തോന്നുന്നു.

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

ഹൈബ്രിഡ് ക്ലോക്ക്

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

• ആദ്യത്തേത് യുണിക്സ് യുഗമാണ് ("കമ്പ്യൂട്ടർ ലോകത്തിൻ്റെ തുടക്കം" മുതൽ എത്ര സെക്കൻ്റുകൾ കടന്നുപോയി).
• രണ്ടാമത്തേത് കുറച്ച് ഇൻക്രിമെൻ്റ് ആണ്, കൂടാതെ 32-ബിറ്റ് സൈൻ ചെയ്യാത്ത ഒരു ഇൻ്റ്

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

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

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

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

ക്ലോക്ക് സിൻക്രൊണൈസേഷൻ

ശാസ്ത്രീയ സാഹിത്യത്തിൽ വിവരിച്ചിരിക്കുന്ന നിരവധി സിൻക്രൊണൈസേഷൻ രീതികളുണ്ട്. നമുക്ക് രണ്ട് വ്യത്യസ്ത ഷാർഡുകൾ ഉള്ളപ്പോൾ ഞാൻ സിൻക്രൊണൈസേഷനെക്കുറിച്ചാണ് സംസാരിക്കുന്നത്. ഒരു റെപ്ലിക്ക സെറ്റ് ഉണ്ടെങ്കിൽ, ഒരു സിൻക്രൊണൈസേഷൻ്റെ ആവശ്യമില്ല: ഇതൊരു "സിംഗിൾ മാസ്റ്റർ" ആണ്; ഞങ്ങൾക്ക് ഒരു ഒപ്ലോഗ് ഉണ്ട്, അതിൽ എല്ലാ മാറ്റങ്ങളും ഉൾപ്പെടുന്നു - ഈ സാഹചര്യത്തിൽ, എല്ലാം ഇതിനകം തന്നെ “ഓപ്ലോഗ്” ൽ തന്നെ ക്രമീകരിച്ചിരിക്കുന്നു. എന്നാൽ നമുക്ക് രണ്ട് വ്യത്യസ്ത ഷാർഡുകൾ ഉണ്ടെങ്കിൽ, സമയ സമന്വയം ഇവിടെ പ്രധാനമാണ്. ഇവിടെയാണ് വെക്റ്റർ ക്ലോക്ക് കൂടുതൽ സഹായിച്ചത്! പക്ഷേ ഞങ്ങൾക്ക് അവയില്ല.

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

യഥാർത്ഥ സമയം തീർച്ചയായും ഒരു അത്ഭുതകരമായ കാര്യമാണ്. പക്ഷേ, വീണ്ടും, ഇത് ഒരുപക്ഷേ ഭാവിയാണ്... അറ്റ്ലസിൽ ഇത് ഇതിനകം ചെയ്യാൻ കഴിയുമെങ്കിലും, ഇതിനകം തന്നെ ഫാസ്റ്റ് "ആമസോൺ" സമയ സമന്വയം ഉണ്ട്. എന്നാൽ ഇത് എല്ലാവർക്കും ലഭ്യമാകില്ല.

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

എങ്ങനെയാണ് എല്ലാം ഒരുമിച്ച് പ്രവർത്തിക്കുന്നത്?

ഇത് കുറച്ച് എളുപ്പമാക്കാൻ ഞാൻ ഇവിടെ ഒരു റെപ്ലിക്ക സെറ്റ് നോക്കുകയാണ്. പ്രൈമറി, സെക്കണ്ടറി എന്നിവയുണ്ട്. സെക്കൻഡറി പകർപ്പെടുക്കൽ നടത്തുന്നു, എല്ലായ്പ്പോഴും പ്രാഥമികവുമായി പൂർണ്ണമായും സമന്വയിപ്പിക്കപ്പെടുന്നില്ല.

ഒരു നിശ്ചിത സമയ മൂല്യമുള്ള "പ്രൈമറി" എന്നതിലേക്ക് ഒരു ഉൾപ്പെടുത്തൽ സംഭവിക്കുന്നു. ഇത് പരമാവധി ആണെങ്കിൽ ഈ ഇൻസേർട്ട് ആന്തരിക എണ്ണം 11 വർദ്ധിപ്പിക്കുന്നു. അല്ലെങ്കിൽ അത് ക്ലോക്ക് മൂല്യങ്ങൾ പരിശോധിക്കുകയും ക്ലോക്ക് മൂല്യങ്ങൾ കൂടുതലാണെങ്കിൽ ക്ലോക്കിലേക്ക് സമന്വയിപ്പിക്കുകയും ചെയ്യും. സമയത്തിനനുസരിച്ച് ക്രമീകരിക്കാൻ ഇത് നിങ്ങളെ അനുവദിക്കുന്നു.

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

ഗവേഷണ സമയത്ത് ഈ സന്ദേശം എങ്ങനെ വ്യാഖ്യാനിക്കുമെന്ന് പൂർണ്ണമായും വ്യക്തമല്ല എന്നതാണ് ഇതിന് കാരണം. ഇത് "Oplog" ൽ പ്രതിഫലിച്ചില്ലെങ്കിൽ, അത് ഒരു തരത്തിലും വ്യാഖ്യാനിക്കില്ലെന്നും സിസ്റ്റത്തിൻ്റെ അവസ്ഥയിലെ മാറ്റം "Oplog"-ലെ ഒരു എൻട്രി മാത്രമാണെന്നും ഞങ്ങൾക്ക് ഉറപ്പായും അറിയാം. ഇത് ഞങ്ങൾക്ക് എല്ലാം ലളിതമാക്കുന്നു: മോഡൽ അത് ലളിതമാക്കുന്നു, കൂടാതെ ഒരു പകർപ്പ് സെറ്റിനുള്ളിൽ ഇത് സംഘടിപ്പിക്കാൻ ഞങ്ങളെ അനുവദിക്കുന്നു, കൂടാതെ മറ്റ് ഉപയോഗപ്രദമായ കാര്യങ്ങളും.

"Oplog"-ലേക്ക് ഇതിനകം എഴുതിയ മൂല്യം തിരികെ നൽകി - "Oplog"-ൽ ഇതിനകം തന്നെ ഈ മൂല്യം അടങ്ങിയിരിക്കുന്നുവെന്നും അതിൻ്റെ സമയം 12 ആണെന്നും ഞങ്ങൾക്കറിയാം. ഇപ്പോൾ, മറ്റൊരു നോഡിൽ നിന്ന് (സെക്കൻഡറി) വായന ആരംഭിക്കുന്നു, അത് ClusterTime-ന് ശേഷം കൈമാറുന്നു. സന്ദേശം. അദ്ദേഹം പറയുന്നു: "കുറഞ്ഞത് 12-ന് ശേഷമോ പന്ത്രണ്ട് സമയത്തോ സംഭവിച്ചതെല്ലാം എനിക്ക് ആവശ്യമാണ്" (മുകളിലുള്ള ചിത്രം കാണുക).

ഇതിനെയാണ് കോസൽ എ കൺസിസ്റ്റൻ്റ് (CAT) എന്ന് വിളിക്കുന്നത്. സിദ്ധാന്തത്തിൽ അത്തരമൊരു ആശയം ഉണ്ട്, ഇത് സമയത്തിൻ്റെ ചില ഭാഗമാണ്, അത് അതിൽ തന്നെ സ്ഥിരതയുള്ളതാണ്. ഈ സാഹചര്യത്തിൽ, സമയം 12 ൽ നിരീക്ഷിച്ച സിസ്റ്റത്തിൻ്റെ അവസ്ഥ ഇതാണ് എന്ന് നമുക്ക് പറയാം.

ഇപ്പോൾ ഇവിടെ ഇതുവരെ ഒന്നുമില്ല, കാരണം പ്രൈമറിയിൽ നിന്നുള്ള ഡാറ്റ പകർത്താൻ നിങ്ങൾക്ക് സെക്കൻഡറി ആവശ്യമുള്ളപ്പോൾ ഇത്തരത്തിലുള്ള സാഹചര്യം അനുകരിക്കുന്നു. അവൻ കാത്തിരിക്കുന്നു ... ഇപ്പോൾ ഡാറ്റ എത്തി - അവൻ ഈ മൂല്യങ്ങൾ തിരികെ നൽകുന്നു.

ഏതാണ്ട് അങ്ങനെയാണ് എല്ലാം പ്രവർത്തിക്കുന്നത്. ഏതാണ്ട്.

"ഏതാണ്ട്" എന്താണ് അർത്ഥമാക്കുന്നത്? ഇതെല്ലാം എങ്ങനെ പ്രവർത്തിക്കുന്നുവെന്ന് വായിച്ച് മനസ്സിലാക്കിയ ഒരാൾ ഉണ്ടെന്ന് കരുതുക. ഓരോ തവണയും ക്ലസ്റ്റർ ടൈം സംഭവിക്കുമ്പോൾ, അത് ആന്തരിക ലോജിക്കൽ ക്ലോക്ക് അപ്ഡേറ്റ് ചെയ്യുന്നു, തുടർന്ന് അടുത്ത എൻട്രി ഒന്നായി വർദ്ധിക്കുന്നു. ഈ പ്രവർത്തനം 20 വരികൾ എടുക്കുന്നു. ഈ വ്യക്തി ഏറ്റവും വലിയ 64-ബിറ്റ് നമ്പർ, മൈനസ് ഒന്ന് ട്രാൻസ്മിറ്റ് ചെയ്യുന്നുവെന്ന് പറയാം.

എന്തുകൊണ്ട് "മൈനസ് ഒന്ന്"? ആന്തരിക ക്ലോക്ക് ഈ മൂല്യത്തിലേക്ക് മാറ്റിസ്ഥാപിക്കപ്പെടുമെന്നതിനാൽ (വ്യക്തമായും, ഇത് സാധ്യമായ ഏറ്റവും വലുതും നിലവിലെ സമയത്തേക്കാൾ വലുതുമാണ്), തുടർന്ന് "ഓപ്ലോഗ്" എന്നതിൽ ഒരു എൻട്രി സംഭവിക്കും, കൂടാതെ ക്ലോക്ക് മറ്റൊരു യൂണിറ്റ് വർദ്ധിപ്പിക്കും - കൂടാതെ ഇതിനകം ഉണ്ടാകും പരമാവധി മൂല്യം (എല്ലാ യൂണിറ്റുകളും ഉണ്ട്, മറ്റെവിടെയും പോകാനില്ല) , unsaint ints).

ഇതിനുശേഷം സിസ്റ്റം ഒന്നിനും അപ്രാപ്യമാകുമെന്ന് വ്യക്തമാണ്. ഇത് അൺലോഡ് ചെയ്യാനും വൃത്തിയാക്കാനും മാത്രമേ കഴിയൂ - ധാരാളം മാനുവൽ ജോലികൾ. പൂർണ്ണ ലഭ്യത:

മാത്രമല്ല, ഇത് മറ്റെവിടെയെങ്കിലും ആവർത്തിക്കുകയാണെങ്കിൽ, മുഴുവൻ ക്ലസ്റ്ററും താഴേക്ക് വീഴുന്നു. ആർക്കും വളരെ വേഗത്തിലും എളുപ്പത്തിലും സംഘടിപ്പിക്കാൻ കഴിയുന്ന തികച്ചും അസ്വീകാര്യമായ സാഹചര്യം! അതിനാൽ, ഈ നിമിഷം ഏറ്റവും പ്രധാനപ്പെട്ട ഒന്നായി ഞങ്ങൾ കണക്കാക്കി. അത് എങ്ങനെ തടയാം?

ക്ലസ്റ്റർ ടൈം സൈൻ ചെയ്യുക എന്നതാണ് ഞങ്ങളുടെ വഴി

സന്ദേശത്തിൽ (നീല വാചകത്തിന് മുമ്പ്) ഇത് ഇങ്ങനെയാണ് കൈമാറുന്നത്. എന്നാൽ ഞങ്ങൾ ഒരു ഒപ്പ് (നീല വാചകം) സൃഷ്ടിക്കാൻ തുടങ്ങി:

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

ഈ കേസിൽ കാര്യകാരണപരമായ സ്ഥിരത ഉപയോഗിക്കുന്നത് എന്താണ് അർത്ഥമാക്കുന്നത്? ആഫ്റ്റർക്ലസ്റ്റർടൈം പാരാമീറ്റർ കാണിക്കുന്നതിനാണ് ഇത്. ഇത് കൂടാതെ, അത് എന്തായാലും മൂല്യങ്ങൾ കൈമാറും. പതിപ്പ് 3.6 മുതൽ ഗോസിപ്പിംഗ് എല്ലായ്പ്പോഴും പ്രവർത്തിക്കുന്നു.

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

വേഗം ചെയ്യൂ!

ഇത് വളരെ ലളിതമായ കാര്യമാണ്, പക്ഷേ ട്രിക്ക് രസകരമാണ് - ഞാൻ അത് പങ്കിടും, ഒരുപക്ഷേ ആരെങ്കിലും താൽപ്പര്യപ്പെട്ടേക്കാം.
ഒപ്പിട്ട ഡാറ്റ സംഭരിക്കുന്ന ഒരു ഹാഷ് ഞങ്ങളുടെ പക്കലുണ്ട്. എല്ലാ ഡാറ്റയും കാഷെയിലൂടെ കടന്നുപോകുന്നു. കാഷെ നിശ്ചിത സമയത്തെ അടയാളപ്പെടുത്തുന്നില്ല, പക്ഷേ ശ്രേണി. ചില മൂല്യങ്ങൾ എത്തുമ്പോൾ, ഞങ്ങൾ ഒരു ശ്രേണി സൃഷ്ടിക്കുകയും അവസാന 16 ബിറ്റുകൾ മറയ്ക്കുകയും ഈ മൂല്യത്തിൽ ഒപ്പിടുകയും ചെയ്യുന്നു:

അത്തരമൊരു ഒപ്പ് ലഭിക്കുന്നതിലൂടെ, ഞങ്ങൾ സിസ്റ്റം (താരതമ്യേന) 65 ആയിരം തവണ വേഗത്തിലാക്കുന്നു. ഇത് മികച്ച രീതിയിൽ പ്രവർത്തിക്കുന്നു: ഞങ്ങൾ പരീക്ഷണങ്ങൾ നടത്തിയപ്പോൾ, തുടർച്ചയായ അപ്ഡേറ്റ് ഉള്ളപ്പോൾ സമയം 10 ​​ആയിരം മടങ്ങ് കുറഞ്ഞു. അവർ ഭിന്നതയിലായിരിക്കുമ്പോൾ, ഇത് പ്രവർത്തിക്കുന്നില്ല എന്നത് വ്യക്തമാണ്. എന്നാൽ മിക്ക പ്രായോഗിക കേസുകളിലും ഇത് പ്രവർത്തിക്കുന്നു. സിഗ്നേച്ചറിനൊപ്പം റേഞ്ച് സിഗ്നേച്ചറും കൂട്ടിച്ചേർത്തത് സുരക്ഷാ പ്രശ്നം പരിഹരിച്ചു.

നമ്മൾ എന്താണ് പഠിച്ചത്?

ഇതിൽ നിന്ന് നമ്മൾ പഠിച്ച പാഠങ്ങൾ:

• ഞങ്ങൾക്ക് മെറ്റീരിയലുകൾ, കഥകൾ, ലേഖനങ്ങൾ എന്നിവ വായിക്കേണ്ടതുണ്ട്, കാരണം ഞങ്ങൾക്ക് ധാരാളം രസകരമായ കാര്യങ്ങൾ ഉണ്ട്. ഞങ്ങൾ ചില ഫീച്ചറുകളിൽ പ്രവർത്തിക്കുമ്പോൾ (പ്രത്യേകിച്ച് ഇപ്പോൾ, ഞങ്ങൾ ഇടപാടുകൾ നടത്തുമ്പോൾ, മുതലായവ), നമ്മൾ വായിക്കുകയും മനസ്സിലാക്കുകയും വേണം. ഇതിന് സമയമെടുക്കും, പക്ഷേ ഇത് യഥാർത്ഥത്തിൽ വളരെ ഉപയോഗപ്രദമാണ്, കാരണം അത് നമ്മൾ എവിടെയാണെന്ന് വ്യക്തമാക്കുന്നു. ഞങ്ങൾ പുതിയതൊന്നും കൊണ്ടുവരാൻ തോന്നിയില്ല - ഞങ്ങൾ ചേരുവകൾ എടുത്തു.

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

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

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

ഞാൻ ഇത് അവസാനിപ്പിക്കാം. നന്ദി!

ചോദ്യങ്ങൾ

പ്രേക്ഷകരിൽ നിന്നുള്ള ചോദ്യം (ഇനി മുതൽ ബി എന്ന് വിളിക്കുന്നു): – നന്ദി, മിഖായേൽ, റിപ്പോർട്ടിന്! സമയത്തെക്കുറിച്ചുള്ള വിഷയം രസകരമാണ്. നിങ്ങൾ ഗോസിപ്പിംഗ് ഉപയോഗിക്കുന്നു. ഓരോരുത്തർക്കും അവരവരുടെ സമയമുണ്ടെന്നും എല്ലാവർക്കും അവരുടെ പ്രാദേശിക സമയം അറിയാമെന്നും അവർ പറഞ്ഞു. ഞാൻ മനസ്സിലാക്കിയതുപോലെ, ഞങ്ങൾക്ക് ഒരു ഡ്രൈവർ ഉണ്ട് - ഡ്രൈവർമാരുള്ള ധാരാളം ക്ലയൻ്റുകളുണ്ടാകും, ക്വറി-പ്ലാനർമാരും, ഷാർഡുകളും ഉണ്ടാകാം... നമുക്ക് പെട്ടെന്ന് ഒരു പൊരുത്തക്കേട് ഉണ്ടായാൽ സിസ്റ്റം എന്ത് ചെയ്യും: അത് ഒരു വ്യക്തിക്ക് വേണ്ടിയാണെന്ന് ആരെങ്കിലും തീരുമാനിക്കുന്നു. ഒരു മിനിറ്റ് മുന്നോട്ട്, ആരെങ്കിലും ഒരു മിനിറ്റ് പിന്നിൽ? നമ്മൾ എവിടെ ചെന്നെത്തും?

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

വി: - അവർ എങ്ങനെ സമന്വയിപ്പിക്കുകയും ഒരു ലോജിക്കൽ സമയം തിരഞ്ഞെടുക്കുകയും ചെയ്യുന്നുവെന്ന് അറിയാൻ ഞാൻ ആഗ്രഹിച്ചു?

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

വി: - ഇതിന് ശേഷം നെറ്റ്‌വർക്കിൽ എവിടെയെങ്കിലും നഷ്ടപ്പെട്ട മറ്റ് ചില സംഭവങ്ങൾ അവനിലേക്ക് വന്നാലോ?

എംടി: – ഒരൊറ്റ മാസ്റ്ററായതിനാൽ അവർ വീണ്ടും വരാത്ത വിധത്തിലാണ് ഷാർഡ് രൂപകൽപ്പന ചെയ്തിരിക്കുന്നത്. അവൻ ഇതിനകം സൈൻ അപ്പ് ചെയ്തിട്ടുണ്ടെങ്കിൽ, അവർ വരില്ല, പിന്നീട് വരും. എന്തെങ്കിലും എവിടെയെങ്കിലും കുടുങ്ങിപ്പോയത് സംഭവിക്കില്ല, പിന്നെ അവൻ എഴുതുന്നില്ല, തുടർന്ന് ഈ സംഭവങ്ങൾ വരുന്നു - കാര്യകാരണപരമായ സ്ഥിരത തകർന്നിരിക്കുന്നു. അവൻ എഴുതാതിരിക്കുമ്പോൾ, അവരെല്ലാം അടുത്തതായി വരണം (അവൻ അവർക്കായി കാത്തിരിക്കും).

വി: - ക്യൂകളെക്കുറിച്ച് എനിക്ക് നിരവധി ചോദ്യങ്ങളുണ്ട്. നിർവ്വഹിക്കേണ്ട പ്രവർത്തനങ്ങളുടെ ഒരു പ്രത്യേക ക്യൂ ഉണ്ടെന്ന് കാര്യകാരണമായ സ്ഥിരത അനുമാനിക്കുന്നു. ഞങ്ങളുടെ പാക്കേജുകളിലൊന്ന് അപ്രത്യക്ഷമായാൽ എന്ത് സംഭവിക്കും? ഇതാ 10, 11... 12 അപ്രത്യക്ഷമായി, മറ്റെല്ലാവരും അത് യാഥാർത്ഥ്യമാകാൻ കാത്തിരിക്കുകയാണ്. പെട്ടെന്ന് ഞങ്ങളുടെ കാർ മരിച്ചു, ഞങ്ങൾക്ക് ഒന്നും ചെയ്യാൻ കഴിയില്ല. എക്സിക്യൂട്ട് ചെയ്യുന്നതിനുമുമ്പ് കുമിഞ്ഞുകൂടുന്ന ക്യൂവിൻ്റെ പരമാവധി നീളമുണ്ടോ? ഏതെങ്കിലും ഒരു സംസ്ഥാനം നഷ്ടപ്പെടുമ്പോൾ എന്ത് മാരകമായ പരാജയമാണ് സംഭവിക്കുന്നത്? മാത്രവുമല്ല, മുമ്പത്തെ അവസ്ഥയുണ്ടെന്ന് എഴുതിയാൽ, എങ്ങനെയെങ്കിലും അതിൽ നിന്ന് ആരംഭിക്കേണ്ടതുണ്ടോ? പക്ഷേ അവർ അവനെ തള്ളിക്കളഞ്ഞില്ല!

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

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

വി: - ഞങ്ങൾക്കായി ഷെർഡിംഗ് നടത്തുന്ന ഒരു ഉദാഹരണം ഞങ്ങൾ സൃഷ്ടിക്കുമ്പോൾ (യഥാക്രമം യജമാനനല്ല, അടിമയാണ്), അത് സ്വന്തം മെഷീൻ്റെ യുണിക്സ് സമയത്തെയോ "യജമാനൻ്റെ" സമയത്തെയോ ആശ്രയിക്കുന്നു; ഇത് ആദ്യമായി അല്ലെങ്കിൽ ഇടയ്ക്കിടെ സമന്വയിപ്പിക്കുന്നുണ്ടോ?

എംടി: - ഞാൻ ഇപ്പോൾ വ്യക്തമാക്കും. ഷാർഡ് (അതായത് തിരശ്ചീന പാർട്ടീഷൻ) - അവിടെ എപ്പോഴും ഒരു പ്രാഥമികം ഉണ്ട്. ഒരു ഷാർഡിന് ഒരു "യജമാനൻ" ഉണ്ടായിരിക്കാം, കൂടാതെ പകർപ്പുകളും ഉണ്ടാകാം. എന്നാൽ ഷാർഡ് എല്ലായ്‌പ്പോഴും റെക്കോർഡിംഗിനെ പിന്തുണയ്ക്കുന്നു, കാരണം അത് ചില ഡൊമെയ്‌നുകളെ പിന്തുണയ്ക്കണം (ഷാർഡിന് പ്രാഥമികമുണ്ട്).

വി: - അപ്പോൾ എല്ലാം "യജമാനനെ" മാത്രം ആശ്രയിച്ചിരിക്കുന്നു? മാസ്റ്റർ സമയം എപ്പോഴും ഉപയോഗിക്കുന്നുണ്ടോ?

എംടി: - അതെ. നിങ്ങൾക്ക് ആലങ്കാരികമായി പറയാൻ കഴിയും: "മാസ്റ്റർ" എന്നതിലേക്ക്, "ഓപ്ലോഗ്" എന്നതിലേക്ക് ഒരു എൻട്രി സംഭവിക്കുമ്പോൾ ക്ലോക്ക് ടിക്ക് ചെയ്യുന്നു.

വി: - ഞങ്ങൾക്ക് കണക്റ്റുചെയ്യുന്ന ഒരു ക്ലയൻ്റ് ഉണ്ട്, സമയത്തെക്കുറിച്ച് ഒന്നും അറിയേണ്ടതില്ലേ?

എംടി: - നിങ്ങൾ ഒന്നും അറിയേണ്ടതില്ല! ക്ലയൻ്റിൽ ഇത് എങ്ങനെ പ്രവർത്തിക്കുന്നു എന്നതിനെക്കുറിച്ച് നമ്മൾ സംസാരിക്കുകയാണെങ്കിൽ: ക്ലയൻ്റ് കാര്യകാരണമായ സ്ഥിരത ഉപയോഗിക്കാൻ ആഗ്രഹിക്കുമ്പോൾ, അവൻ ഒരു സെഷൻ തുറക്കേണ്ടതുണ്ട്. ഇപ്പോൾ എല്ലാം ഉണ്ട്: സെഷനിലെ ഇടപാടുകൾ, ഒരു അവകാശം വീണ്ടെടുക്കുക... ഒരു സെഷൻ എന്നത് ക്ലയൻ്റുമായി സംഭവിക്കുന്ന ലോജിക്കൽ ഇവൻ്റുകൾ ക്രമപ്പെടുത്തുന്നതാണ്.

അവൻ ഈ സെഷൻ തുറന്ന് അവിടെ തനിക്ക് കാര്യകാരണ സ്ഥിരത വേണമെന്ന് പറഞ്ഞാൽ (സെഷൻ സ്ഥിരസ്ഥിതിയായി കാര്യകാരണ സ്ഥിരതയെ പിന്തുണയ്ക്കുന്നുവെങ്കിൽ), എല്ലാം സ്വയമേവ പ്രവർത്തിക്കുന്നു. ഡ്രൈവർ ഈ സമയം ഓർമ്മിക്കുകയും ഒരു പുതിയ സന്ദേശം ലഭിക്കുമ്പോൾ അത് വർദ്ധിപ്പിക്കുകയും ചെയ്യുന്നു. ഡാറ്റ തിരികെ നൽകിയ സെർവറിൽ നിന്ന് മുമ്പത്തേത് എന്ത് പ്രതികരണമാണ് നൽകിയതെന്ന് ഇത് ഓർക്കുന്നു. അടുത്ത അഭ്യർത്ഥനയിൽ afterCluster ("ഇതിനേക്കാൾ വലിയ സമയം") അടങ്ങിയിരിക്കും.

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

വി: - കമ്പ്യൂട്ട് സയൻസിൻ്റെ ഒരു പുതിയ ലെയർ - CRDT (സംഘർഷരഹിതമായ ആവർത്തന ഡാറ്റ തരങ്ങൾ) ഡാറ്റ തരങ്ങൾ - അന്തിമ സ്ഥിരത എന്ന വിഷയവുമായി ശക്തമായി ബന്ധപ്പെട്ടിരിക്കുന്നു. ഈ തരത്തിലുള്ള ഡാറ്റ ഡാറ്റാബേസിലേക്ക് സംയോജിപ്പിക്കുന്നത് നിങ്ങൾ പരിഗണിച്ചിട്ടുണ്ടോ, അതിനെക്കുറിച്ച് നിങ്ങൾക്ക് എന്ത് പറയാൻ കഴിയും?

എംടി: - നല്ല ചോദ്യം! CRDT പൊരുത്തക്കേടുകൾ എഴുതുന്നതിൽ അർത്ഥമുണ്ട്: മോംഗോഡിബിയിൽ, സിംഗിൾ മാസ്റ്റർ.

വി: - എനിക്ക് devops-ൽ നിന്ന് ഒരു ചോദ്യമുണ്ട്. യഥാർത്ഥ ലോകത്ത്, ബൈസൻ്റൈൻ പരാജയം സംഭവിക്കുമ്പോൾ അത്തരം ജെസ്യൂട്ട് സാഹചര്യങ്ങളുണ്ട്, കൂടാതെ സംരക്ഷിത പരിധിക്കുള്ളിലെ ദുഷ്ടന്മാർ പ്രോട്ടോക്കോളിലേക്ക് കുത്താൻ തുടങ്ങുകയും ക്രാഫ്റ്റ് പാക്കേജുകൾ ഒരു പ്രത്യേക രീതിയിൽ അയയ്ക്കുകയും ചെയ്യണോ?

എംടി: - പരിധിക്കുള്ളിലെ ദുഷ്ടന്മാർ ഒരു ട്രോജൻ കുതിരയെപ്പോലെയാണ്! പരിധിക്കുള്ളിലെ ദുഷ്ടന്മാർക്ക് ധാരാളം മോശമായ കാര്യങ്ങൾ ചെയ്യാൻ കഴിയും.

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

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

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

വി: - സംരക്ഷിത ചുറ്റളവിൽ, സെർവറിനെ പൂർണ്ണമായി നശിപ്പിക്കുന്നതിനായി സെർവറിനായി ആരെങ്കിലും അപ്രതീക്ഷിത പ്രോട്ടോക്കോളുകൾ സൃഷ്ടിക്കാൻ ശ്രമിച്ചു, നിങ്ങൾ ഭാഗ്യവാനാണെങ്കിൽ, മുഴുവൻ ക്ലസ്റ്ററും... അത് എപ്പോഴെങ്കിലും "നല്ലത്" ലഭിക്കുമോ?

എംടി: "ഞാൻ അത്തരം കാര്യങ്ങളെക്കുറിച്ച് കേട്ടിട്ടില്ല." ഈ രീതിയിൽ നിങ്ങൾക്ക് ഒരു സെർവർ ക്രാഷ് ചെയ്യാൻ കഴിയുമെന്നത് രഹസ്യമല്ല. ഉള്ളിൽ പരാജയപ്പെടുക, പ്രോട്ടോക്കോളിൽ നിന്നുള്ളവരായിരിക്കുക, സന്ദേശത്തിൽ ഇതുപോലെ എന്തെങ്കിലും എഴുതാൻ കഴിയുന്ന അംഗീകൃത ഉപയോക്താവ്... സത്യത്തിൽ, ഇത് അസാധ്യമാണ്, കാരണം അത് ഇപ്പോഴും സ്ഥിരീകരിക്കപ്പെടും. ഈ പ്രാമാണീകരണം ആവശ്യമില്ലാത്ത ഉപയോക്താക്കൾക്ക് അപ്രാപ്തമാക്കാൻ കഴിയും - അപ്പോൾ അതാണ് അവരുടെ പ്രശ്നം; അവർ, ഏകദേശം പറഞ്ഞാൽ, മതിലുകൾ സ്വയം നശിപ്പിച്ചു, നിങ്ങൾക്ക് ആനയെ അവിടെ തള്ളാം, അത് ചവിട്ടിമെതിക്കും ... എന്നാൽ പൊതുവേ, നിങ്ങൾക്ക് ഒരു റിപ്പയർ ആയി വേഷം കെട്ടാം, വന്ന് അത് പുറത്തെടുക്കാം!

വി: - റിപ്പോർട്ടിന് നന്ദി. സെർജി (Yandex). റെപ്ലിക്ക സെറ്റിലെ വോട്ടിംഗ് അംഗങ്ങളുടെ എണ്ണം പരിമിതപ്പെടുത്തുന്ന ഒരു സ്ഥിരാങ്കം മോങ്ങിൽ ഉണ്ട്, ഈ സ്ഥിരാങ്കം 7 (ഏഴ്) ആണ്. എന്തുകൊണ്ടാണ് ഇത് സ്ഥിരമായിരിക്കുന്നത്? എന്തുകൊണ്ടാണ് ഇത് ഒരുതരം പരാമീറ്റർ അല്ലാത്തത്?

എംടി: - ഞങ്ങൾക്ക് 40 നോഡുകളുള്ള റെപ്ലിക്ക സെറ്റുകൾ ഉണ്ട്. എപ്പോഴും ഭൂരിപക്ഷമുണ്ട്. ഏത് പതിപ്പാണെന്ന് എനിക്കറിയില്ല...

വി: - Replica Set-ൽ നിങ്ങൾക്ക് വോട്ട് ചെയ്യാത്ത അംഗങ്ങളെ പ്രവർത്തിപ്പിക്കാം, എന്നാൽ പരമാവധി 7 വോട്ടിംഗ് അംഗങ്ങളുണ്ട്. ഞങ്ങളുടെ Replica Set 3 ഡാറ്റാ സെൻ്ററുകളിൽ വ്യാപിച്ചിട്ടുണ്ടെങ്കിൽ ഈ സാഹചര്യത്തിൽ ഷട്ട്ഡൗൺ എങ്ങനെ അതിജീവിക്കാം? ഒരു ഡാറ്റാ സെൻ്റർ എളുപ്പത്തിൽ ഓഫ് ചെയ്യാം, മറ്റൊരു മെഷീൻ വീഴാം.

എംടി: - ഇത് ഇതിനകം റിപ്പോർട്ടിൻ്റെ പരിധിക്കപ്പുറമാണ്. ഇതൊരു പൊതുവായ ചോദ്യമാണ്. ഒരുപക്ഷെ അതിനെക്കുറിച്ച് പിന്നീട് പറയാം.

ചില പരസ്യങ്ങൾ 🙂

ഞങ്ങളോടൊപ്പം താമസിച്ചതിന് നന്ദി. ഞങ്ങളുടെ ലേഖനങ്ങൾ നിങ്ങൾക്ക് ഇഷ്ടമാണോ? കൂടുതൽ രസകരമായ ഉള്ളടക്കം കാണാൻ ആഗ്രഹിക്കുന്നുണ്ടോ? ഒരു ഓർഡർ നൽകി അല്ലെങ്കിൽ സുഹൃത്തുക്കൾക്ക് ശുപാർശ ചെയ്തുകൊണ്ട് ഞങ്ങളെ പിന്തുണയ്ക്കുക, $4.99 മുതൽ ഡെവലപ്പർമാർക്കുള്ള ക്ലൗഡ് VPS, എൻട്രി ലെവൽ സെർവറുകളുടെ ഒരു അദ്വിതീയ അനലോഗ്, നിങ്ങൾക്കായി ഞങ്ങൾ കണ്ടുപിടിച്ചതാണ്: VPS (KVM) E5-2697 v3 (6 കോറുകൾ) 10GB DDR4 480GB SSD 1Gbps-നെക്കുറിച്ചുള്ള മുഴുവൻ സത്യവും $19 മുതൽ അല്ലെങ്കിൽ എങ്ങനെ ഒരു സെർവർ പങ്കിടാം? (RAID1, RAID10 എന്നിവയ്‌ക്കൊപ്പം 24 കോറുകൾ വരെയും 40GB DDR4 വരെയും ലഭ്യമാണ്).

ആംസ്റ്റർഡാമിലെ Equinix Tier IV ഡാറ്റാ സെന്ററിൽ Dell R730xd 2 മടങ്ങ് വിലക്കുറവാണോ? ഇവിടെ മാത്രം 2 x Intel TetraDeca-Core Xeon 2x E5-2697v3 2.6GHz 14C 64GB DDR4 4x960GB SSD 1Gbps 100 TV $199 മുതൽ നെതർലാൻഡിൽ! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - $99 മുതൽ! കുറിച്ച് വായിക്കുക ഇൻഫ്രാസ്ട്രക്ചർ കോർപ്പറേഷൻ എങ്ങനെ നിർമ്മിക്കാം. ഒരു പൈസയ്ക്ക് 730 യൂറോ വിലയുള്ള Dell R5xd E2650-4 v9000 സെർവറുകൾ ഉപയോഗിക്കുന്ന ക്ലാസ്?

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