NoSQL-ൽ ഡാറ്റയും സ്ഥിരതയും വിശ്വാസവും നഷ്ടപ്പെടാതെ കസാന്ദ്രയുടെ കണ്ണുകളിലേക്ക് എങ്ങനെ നോക്കാം

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

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

സിസ്റ്റത്തിന്റെ പ്രവർത്തന തത്വം ഇപ്രകാരമാണ്. കോളിന്റെ ഘടന വിവരിക്കുന്ന ഒരു പ്രത്യേക ഘടനയുള്ള ഫയലുകൾ ഇൻപുട്ടിൽ ഉൾപ്പെടുന്നു. ഈ ഘടന ഉചിതമായ നിരകളിൽ സംഭരിച്ചിട്ടുണ്ടെന്ന് ആപ്ലിക്കേഷൻ ഉറപ്പാക്കുന്നു. ഭാവിയിൽ, സബ്‌സ്‌ക്രൈബർമാർക്കുള്ള ട്രാഫിക് ഉപഭോഗത്തെക്കുറിച്ചുള്ള വിവരങ്ങൾ പ്രദർശിപ്പിക്കുന്നതിന് സേവ് ചെയ്ത കോളുകൾ ഉപയോഗിക്കുന്നു (നിരക്കുകൾ, കോളുകൾ, ബാലൻസ് ചരിത്രം).

എന്തുകൊണ്ടാണ് അവർ കസാന്ദ്രയെ തിരഞ്ഞെടുത്തതെന്ന് വ്യക്തമാണ് - അവൾ ഒരു മെഷീൻ ഗൺ പോലെ എഴുതുന്നു, എളുപ്പത്തിൽ അളക്കാവുന്നതും തെറ്റ് സഹിക്കുന്നതുമാണ്.

അതിനാൽ, ഇതാണ് അനുഭവം ഞങ്ങൾക്ക് നൽകിയത്

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

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

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

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

ടെസ്റ്റ് സോണുകളിലേക്ക് ഡാറ്റ കൈമാറുന്നതിൽ ഞങ്ങൾക്ക് ഒരു പ്രശ്നം നേരിട്ടു (പരീക്ഷയിലെ 5 നോഡുകൾ, പ്രോമിലെ 20 നോഡുകൾ). ഈ സാഹചര്യത്തിൽ, ഡംപ് ഉപയോഗിക്കാൻ കഴിയില്ല.

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

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

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

ഞങ്ങൾ എങ്ങനെ തീരുമാനിച്ചു

നോഡ് മുങ്ങുന്നത് തടയാൻ, SWAP പ്രവർത്തനരഹിതമാക്കി. ഇപ്പോൾ, മെമ്മറി കുറവാണെങ്കിൽ, നോഡ് താഴേക്ക് പോകണം, വലിയ ജിസി താൽക്കാലികമായി നിർത്തരുത്.

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

DataStax-ൽ നിന്ന് ഞങ്ങൾ പിന്തുണ വാങ്ങി. പെട്ടിയിലാക്കിയ കസാന്ദ്രയുടെ വികസനം ഇതിനകം അവസാനിച്ചു (അവസാനം പ്രതിജ്ഞാബദ്ധത 2018 ഫെബ്രുവരിയിലായിരുന്നു). അതേ സമയം, ഡാറ്റാസ്റ്റാക്സ് മികച്ച സേവനവും നിലവിലുള്ള ഐപി സൊല്യൂഷനുകൾക്കായി പരിഷ്കരിച്ചതും പൊരുത്തപ്പെടുത്തപ്പെട്ടതുമായ പരിഹാരങ്ങളും വാഗ്ദാനം ചെയ്യുന്നു.

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

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

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

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

ഞങ്ങളുടെ നിലവിലെ വിന്യാസ നയം റോൾബാക്കുകളില്ലാതെ പ്രവർത്തിക്കാൻ ഞങ്ങളെ അനുവദിക്കുന്നു. പ്രമോയ്‌ക്ക് മുമ്പ്, ഒരു നിർബന്ധിത പരീക്ഷണ ഓട്ടമുണ്ട്, അവിടെ ഒരു തെറ്റ് അത്ര ചെലവേറിയതല്ല. പരാജയപ്പെടുകയാണെങ്കിൽ, നിങ്ങൾക്ക് എല്ലായ്പ്പോഴും കേസ്സ്പേസ് ഉപേക്ഷിച്ച് മുഴുവൻ സ്കീമും തുടക്കം മുതൽ റോൾ ചെയ്യാം.

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

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

തൽഫലമായി, ഇപ്പോൾ EACH_QUORUM എഴുതുന്നതിനുള്ള സ്ഥിരത തലത്തിൽ നിർത്തി, വായിക്കാൻ - LOCAL_QUORUM

ഹ്രസ്വമായ ഇംപ്രഷനുകളും നിഗമനങ്ങളും

പ്രവർത്തന പിന്തുണയുടെയും കൂടുതൽ വികസനത്തിനുള്ള സാധ്യതകളുടെയും വീക്ഷണകോണിൽ നിന്ന് ഫലമായുണ്ടാകുന്ന പരിഹാരം വിലയിരുത്തുന്നതിന്, അത്തരമൊരു വികസനം മറ്റെവിടെ പ്രയോഗിക്കാമെന്ന് ചിന്തിക്കാൻ ഞങ്ങൾ തീരുമാനിച്ചു.

ബാറ്റിൽ നിന്നുതന്നെ, തുടർന്ന് “അതു സൗകര്യമുള്ളപ്പോൾ പണമടയ്ക്കുക” (ഞങ്ങൾ വിവരങ്ങൾ C*-ലേക്ക് ലോഡ് ചെയ്യുന്നു, സ്പാർക്ക് സ്ക്രിപ്റ്റുകൾ ഉപയോഗിച്ച് കണക്കുകൂട്ടൽ), ക്ലെയിമുകളുടെ കണക്കെടുപ്പ്, പ്രദേശം പ്രകാരമുള്ള സംയോജനം, റോളുകൾ സംഭരിക്കുക, റോളിനെ അടിസ്ഥാനമാക്കി ഉപയോക്തൃ ആക്‌സസ് അവകാശങ്ങൾ കണക്കാക്കൽ എന്നിവ പോലുള്ള പ്രോഗ്രാമുകൾക്കായി ഡാറ്റ സ്‌കോറിംഗ് മാട്രിക്സ്.

നിങ്ങൾക്ക് കാണാനാകുന്നതുപോലെ, ശേഖരം വിശാലവും വൈവിധ്യപൂർണ്ണവുമാണ്. ഞങ്ങൾ NoSQL-നെ പിന്തുണയ്ക്കുന്നവരുടെ/എതിരാളികളുടെ ക്യാമ്പ് തിരഞ്ഞെടുക്കുകയാണെങ്കിൽ, ഞങ്ങൾ പിന്തുണക്കുന്നവരോടൊപ്പം ചേരും, കാരണം ഞങ്ങൾക്ക് ഞങ്ങളുടെ നേട്ടങ്ങൾ ലഭിച്ചതിനാൽ, ഞങ്ങൾ പ്രതീക്ഷിച്ചിടത്ത് കൃത്യമായി.

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

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

ഉദാഹരണത്തിന്, കസാന്ദ്രയുടെ അപ്‌ഡേറ്റുകൾ സമയബന്ധിതമായി ട്രാക്ക് ചെയ്യുകകാരണം ഞങ്ങൾക്ക് ലഭിച്ച ചില പ്രശ്‌നങ്ങൾ നേരത്തെ തന്നെ അറിയുകയും പരിഹരിച്ചതുമാണ്.

ഡാറ്റാബേസും സ്പാർക്കും ഒരേ നോഡുകളിൽ ഇടരുത് (അല്ലെങ്കിൽ അനുവദനീയമായ വിഭവ ഉപയോഗത്തിന്റെ അളവ് കൊണ്ട് കർശനമായി വിഭജിക്കുക), കാരണം സ്പാർക്കിന് പ്രതീക്ഷിച്ചതിലും കൂടുതൽ OP കഴിക്കാൻ കഴിയും, കൂടാതെ ഞങ്ങളുടെ ലിസ്റ്റിൽ നിന്ന് പ്രശ്‌ന നമ്പർ 1 വേഗത്തിൽ ലഭിക്കും.

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

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

മോശം അല്ല TTL അറ്റാച്ചുചെയ്യാനും കാലഹരണപ്പെട്ട ഡാറ്റ വൃത്തിയാക്കാനും ഉടനടി നൽകുക.

കസാന്ദ്രയിൽ നിന്ന് ഡാറ്റ ഡൗൺലോഡ് ചെയ്യുമ്പോൾ ആപ്ലിക്കേഷൻ ലോജിക് FETCH തത്വത്തിൽ പ്രവർത്തിക്കണം, അങ്ങനെ എല്ലാ വരികളും ഒരേസമയം മെമ്മറിയിലേക്ക് ലോഡുചെയ്യില്ല, പക്ഷേ ബാച്ചുകളായി തിരഞ്ഞെടുക്കപ്പെടുന്നു.

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

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

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

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