DBA ബോട്ട് ജോ. അനറ്റോലി സ്റ്റാൻസ്ലർ (Postgres.ai)

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

വീഡിയോ:

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

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

ഞങ്ങൾ സങ്കീർണ്ണമായ ഹൈ-ലോഡ് മൈഗ്രേഷനുകൾ വികസിപ്പിക്കുകയും നടത്തുകയും ചെയ്യുമ്പോൾ, നമ്മൾ സ്വയം ചോദ്യം ചോദിക്കുന്നു: "ഈ മൈഗ്രേഷൻ ആരംഭിക്കുമോ?". ഞങ്ങൾ അവലോകനം ഉപയോഗിക്കുന്നു, കൂടുതൽ പരിചയസമ്പന്നരായ സഹപ്രവർത്തകരുടെയും DBA വിദഗ്ധരുടെയും അറിവ് ഞങ്ങൾ ഉപയോഗിക്കുന്നു. അത് പറക്കുമോ ഇല്ലയോ എന്ന് അവർക്ക് പറയാം.

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

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

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

ഇത് വേദനിപ്പിക്കുന്നു, അത് ചെലവേറിയതാണ്. അത് ചെയ്യാതിരിക്കുന്നതാണ് നല്ലത്.

പിന്നെ എന്താണ് അതിനുള്ള ഏറ്റവും നല്ല മാർഗം?

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

ചില പിശകുകൾ നീക്കംചെയ്യാൻ ഇത് ഞങ്ങളെ അനുവദിക്കും, അതായത് അവ പ്രോഡിൽ ഉണ്ടാകുന്നത് തടയുന്നു.

എന്തൊക്കെയാണ് പ്രശ്നങ്ങൾ?

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

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

ഇത് മുമ്പത്തെ സമീപനത്തേക്കാൾ മികച്ചതാണ്, പക്ഷേ ഇപ്പോഴും ചില തരത്തിലുള്ള പിശക് ഉൽപാദനത്തിലേക്ക് പോകാനുള്ള ഉയർന്ന സാധ്യതയുണ്ട്.

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

ടെറാബൈറ്റിനേക്കാൾ വലിയ ഡാറ്റാബേസ് ആർക്കുണ്ട്? പകുതിയിലധികം മുറി.

ഓരോ ഡവലപ്പറിനും മെഷീനുകൾ സൂക്ഷിക്കുന്നത്, ഇത്രയും വലിയ ഉൽപ്പാദനം ഉണ്ടാകുമ്പോൾ, വളരെ ചെലവേറിയതാണെന്നും കൂടാതെ, ഇത് വളരെ സമയമെടുക്കുമെന്നും വ്യക്തമാണ്.

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

ഇൻഫ്രാസ്ട്രക്ചറിനുള്ളിൽ നിങ്ങൾ ഇത് ചെയ്താലും, മണിക്കൂറിൽ ഒരു ടെറാബൈറ്റ് ഡാറ്റ ഡൗൺലോഡ് ചെയ്യുന്നത് ഇതിനകം തന്നെ വളരെ നല്ലതാണ്. എന്നാൽ അവർ ലോജിക്കൽ ഡമ്പുകൾ ഉപയോഗിക്കുന്നു, അവർ ക്ലൗഡിൽ നിന്ന് പ്രാദേശികമായി ഡൗൺലോഡ് ചെയ്യുന്നു. അവർക്ക് മണിക്കൂറിൽ 200 ജിഗാബൈറ്റാണ് വേഗത. ലോജിക്കൽ ഡമ്പിൽ നിന്ന് തിരിയാനും സൂചികകൾ ചുരുട്ടാനും മറ്റും ഇനിയും സമയമെടുക്കും.

എന്നാൽ അവർ ഈ സമീപനം ഉപയോഗിക്കുന്നു, കാരണം ഇത് ഉൽപ്പന്നത്തെ വിശ്വസനീയമായി നിലനിർത്താൻ അനുവദിക്കുന്നു.

നമുക്ക് ഇവിടെ എന്ത് ചെയ്യാൻ കഴിയും? ടെസ്റ്റ് ബെഞ്ചുകൾ വിലകുറഞ്ഞതാക്കി ഓരോ ഡെവലപ്പർക്കും അവരവരുടെ ടെസ്റ്റ് ബെഞ്ച് നൽകാം.

ഇത് സാധ്യമാണ്.

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

യഥാർത്ഥ ഉദാഹരണം:

• ഡിബി - 4,5 ടെറാബൈറ്റ്.

• 30 സെക്കൻഡിനുള്ളിൽ നമുക്ക് സ്വതന്ത്രമായ പകർപ്പുകൾ ലഭിക്കും.

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

ഇത് മഹത്തരമാണ്. ഇവിടെ നമ്മൾ മാജിക്കിനെയും ഒരു സമാന്തര പ്രപഞ്ചത്തെയും കുറിച്ച് സംസാരിക്കുന്നു.

ഞങ്ങളുടെ കാര്യത്തിൽ, ഇത് OpenZFS സിസ്റ്റം ഉപയോഗിച്ചാണ് പ്രവർത്തിക്കുന്നത്.

ഓപ്പൺസെഡ്എഫ്എസ് ഒരു കോപ്പി-ഓൺ-റൈറ്റ് ഫയൽ സിസ്റ്റമാണ്, അത് ബോക്സിന് പുറത്ത് സ്നാപ്പ്ഷോട്ടുകളും ക്ലോണുകളും പിന്തുണയ്ക്കുന്നു. ഇത് വിശ്വസനീയവും അളക്കാവുന്നതുമാണ്. അവൾ കൈകാര്യം ചെയ്യാൻ വളരെ എളുപ്പമാണ്. ഇത് അക്ഷരാർത്ഥത്തിൽ രണ്ട് ടീമുകളായി വിന്യസിക്കാവുന്നതാണ്.

മറ്റ് ഓപ്ഷനുകൾ ഉണ്ട്:

• എൽവിഎം,

• സംഭരണം (ഉദാഹരണത്തിന്, ശുദ്ധമായ സംഭരണം).

ഞാൻ പറയുന്ന ഡാറ്റാബേസ് ലാബ് മോഡുലാർ ആണ്. ഈ ഓപ്ഷനുകൾ ഉപയോഗിച്ച് നടപ്പിലാക്കാൻ കഴിയും. എന്നാൽ ഇപ്പോൾ, ഞങ്ങൾ OpenZFS-ൽ ശ്രദ്ധ കേന്ദ്രീകരിച്ചിരിക്കുന്നു, കാരണം LVM-ൽ പ്രത്യേകമായി പ്രശ്നങ്ങൾ ഉണ്ടായിരുന്നു.

ഇത് എങ്ങനെ പ്രവർത്തിക്കുന്നു? ഓരോ തവണയും ഞങ്ങൾ ഡാറ്റ മാറ്റുമ്പോൾ അത് പുനരാലേഖനം ചെയ്യുന്നതിനുപകരം, ഈ പുതിയ ഡാറ്റ ഒരു പുതിയ ഘട്ടത്തിൽ നിന്നുള്ളതാണ്, ഒരു പുതിയ സ്നാപ്പ്ഷോട്ട് എന്ന് അടയാളപ്പെടുത്തി ഞങ്ങൾ അത് സംരക്ഷിക്കുന്നു.

ഭാവിയിൽ, ഞങ്ങൾ റോൾബാക്ക് ചെയ്യണമെങ്കിൽ അല്ലെങ്കിൽ ഏതെങ്കിലും പഴയ പതിപ്പിൽ നിന്ന് ഒരു പുതിയ ക്ലോൺ നിർമ്മിക്കാൻ ആഗ്രഹിക്കുന്നുവെങ്കിൽ, ഞങ്ങൾ പറയും: "ശരി, ഇതുപോലെ അടയാളപ്പെടുത്തിയ ഡാറ്റയുടെ ഈ ബ്ലോക്കുകൾ ഞങ്ങൾക്ക് തരൂ."

ഈ ഉപയോക്താവ് അത്തരമൊരു ഡാറ്റാ സെറ്റിനൊപ്പം പ്രവർത്തിക്കും. അവൻ ക്രമേണ അവ മാറ്റും, സ്വന്തമായി സ്നാപ്പ്ഷോട്ടുകൾ ഉണ്ടാക്കും.

ഞങ്ങൾ ശാഖ ചെയ്യും. ഞങ്ങളുടെ കേസിലെ ഓരോ ഡവലപ്പർക്കും അവരുടേതായ ക്ലോൺ എഡിറ്റ് ചെയ്യാനുള്ള അവസരം ഉണ്ടായിരിക്കും, കൂടാതെ പങ്കിടുന്ന ഡാറ്റ എല്ലാവർക്കുമിടയിൽ പങ്കിടും.

വീട്ടിൽ അത്തരമൊരു സംവിധാനം വിന്യസിക്കുന്നതിന്, നിങ്ങൾ രണ്ട് പ്രശ്നങ്ങൾ പരിഹരിക്കേണ്ടതുണ്ട്:

• ആദ്യത്തേത് ഡാറ്റയുടെ ഉറവിടമാണ്, നിങ്ങൾ അത് എവിടെ നിന്ന് എടുക്കും. നിങ്ങൾക്ക് പ്രൊഡക്ഷൻ ഉപയോഗിച്ച് റെപ്ലിക്കേഷൻ സജ്ജീകരിക്കാം. നിങ്ങൾ കോൺഫിഗർ ചെയ്‌ത ബാക്കപ്പുകൾ നിങ്ങൾക്ക് ഇതിനകം ഉപയോഗിക്കാൻ കഴിയും, ഞാൻ പ്രതീക്ഷിക്കുന്നു. WAL-E, WAL-G അല്ലെങ്കിൽ ബാർമാൻ. നിങ്ങൾ RDS അല്ലെങ്കിൽ Cloud SQL പോലുള്ള ഏതെങ്കിലും തരത്തിലുള്ള ക്ലൗഡ് സൊല്യൂഷൻ ഉപയോഗിക്കുന്നുണ്ടെങ്കിൽ പോലും, നിങ്ങൾക്ക് ലോജിക്കൽ ഡംപുകൾ ഉപയോഗിക്കാം. എന്നാൽ ബാക്കപ്പുകൾ ഉപയോഗിക്കാൻ ഞങ്ങൾ ഇപ്പോഴും നിങ്ങളെ ഉപദേശിക്കുന്നു, കാരണം ഈ സമീപനത്തിലൂടെ നിങ്ങൾ ഫയലുകളുടെ ഭൗതിക ഘടനയും നിലനിർത്തും, ഇത് നിലവിലുള്ള പ്രശ്‌നങ്ങൾ പരിഹരിക്കുന്നതിന് നിങ്ങൾ ഉൽപ്പാദനത്തിൽ കാണുന്ന അളവുകളോട് കൂടുതൽ അടുക്കാൻ നിങ്ങളെ അനുവദിക്കും.

• രണ്ടാമത്തേത് നിങ്ങൾ എവിടെയാണ് ഡാറ്റാബേസ് ലാബ് ഹോസ്റ്റ് ചെയ്യാൻ ആഗ്രഹിക്കുന്നത്. അത് ക്ലൗഡ് ആകാം, അത് ഓൺ-പ്രെമൈസ് ആകാം. ZFS ഡാറ്റ കംപ്രഷനെ പിന്തുണയ്ക്കുന്നുവെന്ന് ഇവിടെ പറയേണ്ടത് പ്രധാനമാണ്. അത് വളരെ നന്നായി ചെയ്യുന്നു.

അത്തരം ഓരോ ക്ലോണിനും, അടിസ്ഥാനം ഉപയോഗിച്ച് ഞങ്ങൾ ചെയ്യുന്ന പ്രവർത്തനങ്ങളെ ആശ്രയിച്ച്, ഏതെങ്കിലും തരത്തിലുള്ള ദേവ് വളരുമെന്ന് സങ്കൽപ്പിക്കുക. ഇതിനായി, ദേവിന് ഇടവും ആവശ്യമാണ്. എന്നാൽ ഞങ്ങൾ 4,5 ടെറാബൈറ്റിന്റെ അടിസ്ഥാനം എടുത്തതിനാൽ, ZFS അതിനെ 3,5 ടെറാബൈറ്റിലേക്ക് ചുരുക്കും. ക്രമീകരണങ്ങൾ അനുസരിച്ച് ഇത് വ്യത്യാസപ്പെടാം. ഞങ്ങൾക്ക് ഇപ്പോഴും ഡെവലപ്പിനുള്ള ഇടമുണ്ട്.

അത്തരമൊരു സംവിധാനം വിവിധ കേസുകളിൽ ഉപയോഗിക്കാം.

• ഇവർ ഡെവലപ്പർമാരാണ്, അന്വേഷണ മൂല്യനിർണ്ണയത്തിനുള്ള ഡിബിഎകൾ, ഒപ്റ്റിമൈസേഷനായി.

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

• പിന്നെ മറ്റൊരു കേസ്. കമ്പനിക്ക് ഒരു അനലിറ്റിക്‌സ് സിസ്റ്റം സജ്ജീകരിച്ചിട്ടില്ലെങ്കിൽ, നമുക്ക് ഉൽപ്പന്ന അടിത്തറയുടെ ഒരു നേർത്ത ക്ലോൺ വേർതിരിച്ച് അനലിറ്റിക്‌സിൽ ഉപയോഗിക്കാവുന്ന നീണ്ട അന്വേഷണങ്ങൾക്കോ ​​പ്രത്യേക സൂചികകൾക്കോ ​​നൽകാം.

ഈ സമീപനത്തിലൂടെ:

1. പൂർണ്ണ വലുപ്പത്തിലുള്ള ഡാറ്റയിലെ എല്ലാ മാറ്റങ്ങളും ഞങ്ങൾ പരീക്ഷിച്ചതിനാൽ "പ്രോഡിൽ" പിശകുകളുടെ സാധ്യത കുറവാണ്.

2. ഞങ്ങൾക്ക് പരീക്ഷണ സംസ്കാരമുണ്ട്, കാരണം ഇപ്പോൾ നിങ്ങളുടെ സ്വന്തം നിലപാടിനായി മണിക്കൂറുകളോളം കാത്തിരിക്കേണ്ടതില്ല.

3. കൂടാതെ ഒരു തടസ്സവുമില്ല, പരീക്ഷകൾക്കിടയിൽ കാത്തിരിപ്പുമില്ല. നിങ്ങൾക്ക് ശരിക്കും പോയി പരിശോധിക്കാം. ഞങ്ങൾ വികസനം വേഗത്തിലാക്കുമ്പോൾ ഈ വഴി മികച്ചതായിരിക്കും.

• റീഫാക്‌ടറിംഗ് കുറവായിരിക്കും. കുറച്ച് ബഗുകൾ പ്രോഡിൽ അവസാനിക്കും. ഞങ്ങൾ അവ പിന്നീട് കുറച്ച് റീഫാക്‌ടർ ചെയ്യും.

• മാറ്റാനാകാത്ത മാറ്റങ്ങൾ നമുക്ക് തിരിച്ചെടുക്കാം. ഇത് സ്റ്റാൻഡേർഡ് സമീപനമല്ല.

1. ടെസ്റ്റ് ബെഞ്ചുകളുടെ വിഭവങ്ങൾ ഞങ്ങൾ പങ്കിടുന്നതിനാൽ ഇത് പ്രയോജനകരമാണ്.

ഇതിനകം നല്ലതാണ്, എന്നാൽ മറ്റെന്താണ് ത്വരിതപ്പെടുത്താൻ കഴിയുക?

അത്തരമൊരു സംവിധാനത്തിന് നന്ദി, അത്തരം പരിശോധനയിൽ പ്രവേശിക്കുന്നതിനുള്ള പരിധി നമുക്ക് വളരെയധികം കുറയ്ക്കാൻ കഴിയും.

യഥാർത്ഥ പൂർണ്ണ വലുപ്പത്തിലുള്ള ഡാറ്റയിലേക്ക് ആക്‌സസ് ലഭിക്കുന്നതിന് ഒരു ഡെവലപ്പർ വിദഗ്ദ്ധനാകേണ്ട ഒരു ദുഷിച്ച വൃത്തം ഇപ്പോൾ ഉണ്ട്. അത്തരം പ്രവേശനം അവനെ വിശ്വസിക്കണം.

പക്ഷേ അത് ഇല്ലെങ്കിൽ എങ്ങനെ വളരും. എന്നാൽ നിങ്ങൾക്ക് വളരെ ചെറിയ ടെസ്റ്റ് ഡാറ്റ മാത്രമേ ലഭ്യമായിട്ടുള്ളൂ എങ്കിലോ? അപ്പോൾ നിങ്ങൾക്ക് യഥാർത്ഥ അനുഭവം ലഭിക്കില്ല.

ഈ സർക്കിളിൽ നിന്ന് എങ്ങനെ പുറത്തുകടക്കും? ഏത് തലത്തിലുമുള്ള ഡെവലപ്പർമാർക്ക് സൗകര്യപ്രദമായ ആദ്യ ഇന്റർഫേസ് എന്ന നിലയിൽ, ഞങ്ങൾ സ്ലാക്ക് ബോട്ട് തിരഞ്ഞെടുത്തു. എന്നാൽ ഇത് മറ്റേതെങ്കിലും ഇന്റർഫേസ് ആകാം.

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

കൂടാതെ സ്ലാക്ക് ബോക്‌സിന് പുറത്ത് സഹകരണത്തിനുള്ള അവസരങ്ങളും നൽകുന്നു. ഇതൊരു ചാനൽ മാത്രമായതിനാൽ, അത്തരം ഒരു അഭ്യർത്ഥനയ്‌ക്കായുള്ള ത്രെഡിൽ തന്നെ നിങ്ങൾക്ക് ഈ അഭ്യർത്ഥന ചർച്ച ചെയ്യാൻ ആരംഭിക്കാം, നിങ്ങളുടെ സഹപ്രവർത്തകരെയും കമ്പനിക്കുള്ളിലെ DBA-കളെയും പിംഗ് ചെയ്യുക.

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

എന്നാൽ ഈ പരിശോധനകൾ വിശ്വസനീയമാകണമെങ്കിൽ, നിങ്ങൾ എങ്ങനെയെങ്കിലും ഈ പ്രശ്നം പരിഹരിക്കേണ്ടതുണ്ട്.

പ്രധാന കാര്യം ഒരേ ഡാറ്റയാണെന്ന് വ്യക്തമാണ്. എന്നാൽ ഞങ്ങൾക്ക് ഇതിനകം ഉണ്ട്. ഞങ്ങൾ ഒരേ കോൺഫിഗറേഷൻ നേടാൻ ആഗ്രഹിക്കുന്നു. ഏതാണ്ട് സമാനമായ ഒരു കോൺഫിഗറേഷൻ നമുക്ക് നൽകാം.

ഉൽപ്പാദനത്തിലെ അതേ ഹാർഡ്‌വെയർ ഉണ്ടായിരിക്കുന്നത് രസകരമായിരിക്കും, പക്ഷേ ഇത് വ്യത്യസ്തമായിരിക്കാം.

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

കോൺഫിഗറേഷനിൽ നിങ്ങൾ വ്യക്തമാക്കുന്ന വലുപ്പത്തെ ആശ്രയിച്ച് പോസ്റ്റ്‌ഗ്രെസ് ആരംഭിക്കുമ്പോൾ പങ്കിട്ട ബഫർ കാഷെ അനുവദിക്കുന്നത് ശ്രദ്ധിക്കേണ്ടതാണ്.

രണ്ടാമത്തെ കാഷെ ലഭ്യമായ എല്ലാ സ്ഥലവും ഉപയോഗിക്കുന്നു.

ഒരു മെഷീനിൽ ഞങ്ങൾ നിരവധി ക്ലോണുകൾ നിർമ്മിക്കുമ്പോൾ, ഞങ്ങൾ ക്രമേണ മെമ്മറി നിറയ്ക്കുന്നതായി മാറുന്നു. ഒരു നല്ല രീതിയിൽ, മെഷീനിൽ ലഭ്യമായ മൊത്തം മെമ്മറിയുടെ 25% ആണ് പങ്കിട്ട ബഫർ കാഷെ.

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

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

ഉദാഹരണത്തിന്, ഞങ്ങൾക്ക് പ്രോഡിൽ ഒരു വലിയ കാഷെ ഉണ്ടെങ്കിൽ, ഒരു സൂചിക ഉപയോഗിക്കാൻ Postgres തിരഞ്ഞെടുക്കും. ഇല്ലെങ്കിൽ, SeqScan ഉണ്ടാകും. നമ്മുടെ പദ്ധതികൾ പൊരുത്തപ്പെടുന്നില്ലെങ്കിൽ എന്തായിരിക്കും പ്രയോജനം?

എന്നാൽ ഇവിടെ ഞങ്ങൾ നിഗമനത്തിലെത്തി, വാസ്തവത്തിൽ Postgres-ലെ പ്ലാൻ പ്ലാനിലെ പങ്കിട്ട ബഫറിൽ വ്യക്തമാക്കിയിരിക്കുന്ന നിർദ്ദിഷ്ട വലുപ്പത്തെ ആശ്രയിക്കുന്നില്ല, അത് ഫലപ്രദമായ_cache_size-നെ ആശ്രയിച്ചിരിക്കുന്നു.

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

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

എന്നാൽ ഇത് സമയത്തെ ബാധിച്ചേക്കാം. സമയക്രമം അനുസരിച്ച് ഞങ്ങൾ ചോദ്യങ്ങൾ ഒപ്റ്റിമൈസ് ചെയ്യുന്നു, എന്നാൽ സമയം പല ഘടകങ്ങളെ ആശ്രയിച്ചിരിക്കുന്നു എന്നത് പ്രധാനമാണ്:

• ഇത് നിലവിൽ ഉൽപ്പന്നത്തിലുള്ള ലോഡിനെ ആശ്രയിച്ചിരിക്കുന്നു.

• ഇത് മെഷീന്റെ സവിശേഷതകളെ ആശ്രയിച്ചിരിക്കുന്നു.

ഇതൊരു പരോക്ഷ പാരാമീറ്ററാണ്, എന്നാൽ വാസ്തവത്തിൽ ഫലം ലഭിക്കുന്നതിന് ഈ അന്വേഷണം വായിക്കുന്ന ഡാറ്റയുടെ അളവ് അനുസരിച്ച് നമുക്ക് കൃത്യമായി ഒപ്റ്റിമൈസ് ചെയ്യാൻ കഴിയും.

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

ജോ പ്രത്യേകമായി ഒപ്റ്റിമൈസ് ചെയ്തിരിക്കുന്നത് എങ്ങനെയെന്ന് നോക്കാം.

ഒരു യഥാർത്ഥ സിസ്റ്റത്തിൽ നിന്ന് ഒരു അഭ്യർത്ഥന എടുക്കാം. ഈ സാഹചര്യത്തിൽ, ഡാറ്റാബേസ് 1 ടെറാബൈറ്റ് ആണ്. കൂടാതെ 10-ലധികം ലൈക്കുകളുള്ള പുതിയ പോസ്റ്റുകളുടെ എണ്ണം കണക്കാക്കാൻ ഞങ്ങൾ ആഗ്രഹിക്കുന്നു.

ഞങ്ങൾ ചാനലിലേക്ക് ഒരു സന്ദേശം എഴുതുകയാണ്, ഞങ്ങൾക്കായി ഒരു ക്ലോൺ വിന്യസിച്ചിട്ടുണ്ട്. അത്തരമൊരു അഭ്യർത്ഥന 2,5 മിനിറ്റിനുള്ളിൽ പൂർത്തിയാകുമെന്ന് ഞങ്ങൾ കാണും. ഇതാണ് നമ്മൾ ആദ്യം ശ്രദ്ധിക്കുന്നത്.

പ്ലാനിന്റെയും മെട്രിക്സിന്റെയും അടിസ്ഥാനത്തിൽ ബി ജോ നിങ്ങൾക്ക് സ്വയമേവയുള്ള ശുപാർശകൾ കാണിക്കും.

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

എന്താണ് സംഭവിച്ചതെന്ന് നമുക്ക് സൂക്ഷ്മമായി പരിശോധിക്കാം. വാസ്തവത്തിൽ, ഫയൽ കാഷെയിൽ നിന്നോ ഡിസ്കിൽ നിന്നോ ഞങ്ങൾ ഏകദേശം ഒന്നര ജിഗാബൈറ്റ് ഡാറ്റ വായിച്ചതായി ഞങ്ങൾ കാണുന്നു. ഇത് നല്ലതല്ല, കാരണം ഞങ്ങൾക്ക് 142 വരികൾ മാത്രമാണ് ലഭിച്ചത്.

കൂടാതെ, ഞങ്ങൾക്ക് ഇവിടെ ഒരു സൂചിക സ്കാൻ ഉണ്ടെന്ന് തോന്നുന്നു, അത് വേഗത്തിൽ പ്രവർത്തിക്കേണ്ടതായിരുന്നു, പക്ഷേ ഞങ്ങൾ വളരെയധികം ലൈനുകൾ ഫിൽട്ടർ ചെയ്തതിനാൽ (ഞങ്ങൾക്ക് അവ കണക്കാക്കേണ്ടതുണ്ട്), അന്വേഷണം സാവധാനത്തിൽ പ്രവർത്തിച്ചു.

അന്വേഷണത്തിലെ വ്യവസ്ഥകളും സൂചികയിലെ വ്യവസ്ഥകളും ഭാഗികമായി പൊരുത്തപ്പെടാത്തതിനാൽ ഇത് പ്ലാനിൽ സംഭവിച്ചു.

സൂചിക കൂടുതൽ കൃത്യമാക്കാൻ ശ്രമിക്കാം, അതിനുശേഷം അന്വേഷണ നിർവ്വഹണം എങ്ങനെ മാറുന്നുവെന്ന് നോക്കാം.

ഇൻഡക്‌സ് സൃഷ്‌ടിക്കുന്നതിന് വളരെയധികം സമയമെടുത്തു, എന്നാൽ ഇപ്പോൾ ഞങ്ങൾ അന്വേഷണം പരിശോധിച്ച് 2,5 മിനിറ്റിന് പകരം സമയം 156 മില്ലിസെക്കൻഡ് മാത്രമാണെന്ന് കാണുന്നു, അത് മതിയാകും. ഞങ്ങൾ 6 മെഗാബൈറ്റ് ഡാറ്റ മാത്രമേ വായിക്കൂ.

ഇപ്പോൾ ഞങ്ങൾ സൂചിക മാത്രം സ്കാൻ ഉപയോഗിക്കുന്നു.

മറ്റൊരു പ്രധാന കഥ, കൂടുതൽ മനസ്സിലാക്കാവുന്ന രീതിയിൽ പ്ലാൻ അവതരിപ്പിക്കാൻ ഞങ്ങൾ ആഗ്രഹിക്കുന്നു എന്നതാണ്. ഫ്ലേം ഗ്രാഫുകൾ ഉപയോഗിച്ച് ഞങ്ങൾ ദൃശ്യവൽക്കരണം നടപ്പിലാക്കിയിട്ടുണ്ട്.

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

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

തീർച്ചയായും, എല്ലാവർക്കും explain.depesz.com അറിയാം. ഈ ദൃശ്യവൽക്കരണത്തിന്റെ ഒരു നല്ല സവിശേഷത, ഞങ്ങൾ ടെക്സ്റ്റ് പ്ലാൻ സംരക്ഷിക്കുകയും ചില അടിസ്ഥാന പാരാമീറ്ററുകൾ ഒരു ടേബിളിൽ ഇടുകയും ചെയ്യുന്നു, അതുവഴി നമുക്ക് അടുക്കാൻ കഴിയും.

ഈ വിഷയം ഇതുവരെ പരിശോധിച്ചിട്ടില്ലാത്ത ഡെവലപ്പർമാരും വിശദീകരിക്കുന്നു.depesz.com ഉപയോഗിക്കുന്നു, കാരണം ഏതൊക്കെ മെട്രിക്‌സുകളാണ് പ്രധാനമെന്നും അല്ലാത്തതെന്നും കണ്ടെത്തുന്നത് അവർക്ക് എളുപ്പമാണ്.

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

സഹകരണം

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

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

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

ഇവിടെയാണ് ഞാൻ അവസാനിപ്പിക്കുന്നത്. നന്ദി!

ചോദ്യങ്ങൾ

ഹലോ! റിപ്പോർട്ടിന് നന്ദി! വളരെ രസകരമാണ്, പ്രത്യേകിച്ച് എനിക്ക്, കാരണം കുറച്ച് മുമ്പ് ഞാൻ ഇതേ പ്രശ്നം പരിഹരിച്ചു. അങ്ങനെ എനിക്ക് കുറേ ചോദ്യങ്ങളുണ്ട്. എനിക്ക് അതിന്റെ ഒരു ഭാഗമെങ്കിലും ലഭിക്കുമെന്ന് പ്രതീക്ഷിക്കുന്നു.

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

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

അതെ, എനിക്ക് ഒരു കൂട്ടമായ ചോദ്യമുണ്ട്. അതായത്, ഈ മൊഡ്യൂളുകളുടെ ജീവിത ചക്രം നിങ്ങൾ എങ്ങനെ ഉറപ്പാക്കും? ഞങ്ങൾക്ക് ഈ പ്രശ്നവും ഒരു പ്രത്യേക കഥയും ഉണ്ട്. ഇത് എങ്ങനെ സംഭവിക്കുന്നു?

ഓരോ ക്ലോണിനും ചില ttl ഉണ്ട്. അടിസ്ഥാനപരമായി, ഞങ്ങൾക്ക് ഒരു നിശ്ചിത ttl ഉണ്ട്.

ഒരു രഹസ്യമല്ലെങ്കിൽ എന്ത്?

1 മണിക്കൂർ, അതായത് നിഷ്ക്രിയ - 1 മണിക്കൂർ. അത് ഉപയോഗിച്ചില്ലെങ്കിൽ, ഞങ്ങൾ അത് അടിച്ചു. എന്നാൽ ഇവിടെ അതിശയിക്കാനൊന്നുമില്ല, കാരണം നമുക്ക് നിമിഷങ്ങൾക്കുള്ളിൽ ക്ലോണിനെ ഉയർത്താൻ കഴിയും. നിങ്ങൾക്ക് വീണ്ടും ആവശ്യമുണ്ടെങ്കിൽ, ദയവായി.

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

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

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

നിക്കോളായ് സമോഖ്വലോവ്: ഞാൻ കൂടുതൽ അഭിപ്രായം പറയട്ടെ? എന്റെ പേര് നിക്കോളായ്, ഞങ്ങൾ അനറ്റോലിയോടൊപ്പം പ്രവർത്തിക്കുന്നു. സംഭരണം മികച്ചതാണെന്ന് ഞാൻ സമ്മതിക്കുന്നു. ഞങ്ങളുടെ ചില ഉപഭോക്താക്കൾക്ക് ശുദ്ധമായ സംഭരണവും മറ്റും ഉണ്ട്.

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

എന്നാൽ ZFS എല്ലാവർക്കും ലഭ്യമാണ്. DelPhix ഇതിനകം മതി, അവർക്ക് 300 ക്ലയന്റുകളുണ്ട്. ഇതിൽ, ഫോർച്യൂൺ 100 ന് 50 ക്ലയന്റുകളാണുള്ളത്, അതായത് അവർ നാസയെ ലക്ഷ്യം വച്ചുള്ളതാണ്. അതുകൊണ്ടാണ് ഞങ്ങൾക്ക് ഒരു ഓപ്പൺ സോഴ്സ് കോർ ഉള്ളത്. ഓപ്പൺ സോഴ്‌സ് അല്ലാത്ത ഒരു ഇന്റർഫേസ് ഭാഗം ഞങ്ങൾക്കുണ്ട്. ഇതാണ് ഞങ്ങൾ കാണിക്കുന്ന പ്ലാറ്റ്ഫോം. എന്നാൽ അത് എല്ലാവർക്കും പ്രാപ്യമായിരിക്കണമെന്ന് ഞങ്ങൾ ആഗ്രഹിക്കുന്നു. എല്ലാ പരീക്ഷകരും ലാപ്‌ടോപ്പുകളിൽ ഊഹിക്കുന്നത് നിർത്താൻ ഒരു വിപ്ലവം നടത്താൻ ഞങ്ങൾ ആഗ്രഹിക്കുന്നു. നമ്മൾ SELECT എന്ന് എഴുതണം, അത് പതുക്കെയാണെന്ന് ഉടൻ തന്നെ കാണണം. DBA അതിനെക്കുറിച്ച് നിങ്ങളോട് പറയുന്നതിനായി കാത്തിരിക്കുന്നത് നിർത്തുക. ഇവിടെയാണ് പ്രധാന ലക്ഷ്യം. നാമെല്ലാവരും ഇതിലേക്ക് വരുമെന്ന് ഞാൻ കരുതുന്നു. എല്ലാവർക്കും ലഭിക്കാൻ വേണ്ടിയാണ് ഞങ്ങൾ ഇത് ഉണ്ടാക്കുന്നത്. അതിനാൽ ZFS, കാരണം അത് എല്ലായിടത്തും ലഭ്യമാകും. പ്രശ്‌നങ്ങൾ പരിഹരിച്ചതിനും ഓപ്പൺ സോഴ്‌സ് ലൈസൻസ് മുതലായവയ്‌ക്കും കമ്മ്യൂണിറ്റിക്ക് നന്ദി.*

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

രണ്ടാമത്തെ ചോദ്യം സ്റ്റാൻഡുകളുടെ പൊരുത്തക്കേടിനെക്കുറിച്ചാണ്. എനിക്ക് ഇവിടെ ZFS ഉണ്ടെന്നും എല്ലാം രസകരമാണെന്നും പറയാം, എന്നാൽ പ്രോഡിലെ ക്ലയന്റിന് ZFS ഇല്ല, പക്ഷേ ext4, ഉദാഹരണത്തിന്. ഈ സാഹചര്യത്തിൽ എങ്ങനെ?

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

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

എനിക്ക് രണ്ട് ചോദ്യങ്ങളുണ്ട്. ഇത് വളരെ രസകരമായ കാര്യമാണ്. ക്രെഡിറ്റ് കാർഡ് നമ്പറുകൾ പോലെയുള്ള പ്രൊഡക്ഷൻ ഡാറ്റ നിർണായകമായ കേസുകൾ ഉണ്ടായിട്ടുണ്ടോ? ഇതിനകം എന്തെങ്കിലും തയ്യാറാണോ അതോ ഒരു പ്രത്യേക ചുമതലയാണോ? രണ്ടാമത്തെ ചോദ്യം - MySQL-ന് ഇതുപോലൊന്ന് ഉണ്ടോ?

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

MySQL-നെ കുറിച്ച്. ഡിസ്കിൽ സ്റ്റേറ്റ് സംഭരിക്കുന്ന എന്തിനും ഈ സിസ്റ്റം ഉപയോഗിക്കാം. ഞങ്ങൾ പോസ്റ്റ്‌ഗ്രെസ് ചെയ്യുന്നതിനാൽ, ഞങ്ങൾ ഇപ്പോൾ പോസ്റ്റ്‌ഗ്രേസിനായി എല്ലാ ഓട്ടോമേഷനും ആദ്യം ചെയ്യുന്നു. ഒരു ബാക്കപ്പിൽ നിന്ന് ഡാറ്റ ലഭിക്കുന്നത് ഓട്ടോമേറ്റ് ചെയ്യാൻ ഞങ്ങൾ ആഗ്രഹിക്കുന്നു. ഞങ്ങൾ Postgres ശരിയായി കോൺഫിഗർ ചെയ്യുന്നു. പ്ലാനുകൾ എങ്ങനെ പൊരുത്തപ്പെടുത്താമെന്ന് ഞങ്ങൾക്കറിയാം.

എന്നാൽ സിസ്റ്റം വിപുലീകരിക്കാൻ കഴിയുന്നതിനാൽ, ഇത് MySQL-നും ഉപയോഗിക്കാം. കൂടാതെ അത്തരം ഉദാഹരണങ്ങളുണ്ട്. Yandex ന് സമാനമായ ഒരു കാര്യമുണ്ട്, പക്ഷേ അവർ അത് എവിടെയും പ്രസിദ്ധീകരിക്കില്ല. Yandex.Metrica ഉള്ളിൽ അവർ അത് ഉപയോഗിക്കുന്നു. MySQL നെ കുറിച്ച് ഒരു കഥ മാത്രമേയുള്ളൂ. എന്നാൽ സാങ്കേതികവിദ്യകൾ ഒന്നുതന്നെയാണ്, ZFS.

റിപ്പോർട്ടിന് നന്ദി! എനിക്കും ഒന്നുരണ്ടു ചോദ്യങ്ങളുണ്ട്. അനലിറ്റിക്‌സിന് ക്ലോണിംഗ് ഉപയോഗിക്കാമെന്ന് നിങ്ങൾ സൂചിപ്പിച്ചു, ഉദാഹരണത്തിന് അവിടെ അധിക സൂചികകൾ നിർമ്മിക്കാൻ. ഇത് എങ്ങനെ പ്രവർത്തിക്കുന്നു എന്നതിനെക്കുറിച്ച് കുറച്ചുകൂടി പറയാമോ?

സ്റ്റാൻഡുകളുടെ സമാനത, പ്ലാനുകളുടെ സമാനത എന്നിവയെക്കുറിച്ചുള്ള രണ്ടാമത്തെ ചോദ്യം ഞാൻ ഉടൻ ചോദിക്കും. പോസ്റ്റ്‌ഗ്രേസ് ശേഖരിച്ച സ്ഥിതിവിവരക്കണക്കുകളും പ്ലാൻ ആശ്രയിച്ചിരിക്കുന്നു. ഈ പ്രശ്നം നിങ്ങൾ എങ്ങനെ പരിഹരിക്കും?

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

ശരി, കുറച്ച് മിനിറ്റ് നിർത്താൻ ഭയങ്കരമല്ലാത്ത ഒരു നേർത്ത ക്ലോൺ ഉണ്ടാക്കാം. അനലിറ്റിക്‌സ് വായിക്കുന്നത് കൂടുതൽ സുഖകരമാക്കുന്നതിന്, ഡാറ്റയിൽ ഞങ്ങൾക്ക് താൽപ്പര്യമുള്ള കോളങ്ങൾക്കായി ഞങ്ങൾ സൂചികകൾ ചേർക്കും.

ഓരോ തവണയും സൂചിക സൃഷ്ടിക്കപ്പെടുമോ?

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

സ്ഥിതിവിവരക്കണക്കുകളെക്കുറിച്ചുള്ള ചോദ്യത്തിന്, ഞങ്ങൾ ഒരു ബാക്കപ്പിൽ നിന്ന് പുനഃസ്ഥാപിക്കുകയാണെങ്കിൽ, ഞങ്ങൾ പകർത്തൽ നടത്തുകയാണെങ്കിൽ, ഞങ്ങളുടെ സ്ഥിതിവിവരക്കണക്കുകൾ സമാനമായിരിക്കും. ഞങ്ങൾക്ക് മുഴുവൻ ഫിസിക്കൽ ഡാറ്റാ ഘടനയും ഉള്ളതിനാൽ, അതായത്, എല്ലാ സ്ഥിതിവിവരക്കണക്കുകൾക്കൊപ്പം ഡാറ്റയും ഞങ്ങൾ കൊണ്ടുവരും.

ഇവിടെ മറ്റൊരു പ്രശ്നമുണ്ട്. നിങ്ങൾ ഒരു ക്ലൗഡ് സൊല്യൂഷൻ ഉപയോഗിക്കുകയാണെങ്കിൽ, അവിടെ ലോജിക്കൽ ഡമ്പുകൾ മാത്രമേ ലഭ്യമാകൂ, കാരണം Google, Amazon എന്നിവ നിങ്ങളെ ഒരു ഫിസിക്കൽ കോപ്പി എടുക്കാൻ അനുവദിക്കുന്നില്ല. ഒരു പ്രശ്നം ഉണ്ടാകും.

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

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

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

അപ്‌ഡേറ്റ് ഒരു അധിക ലെയറായി നടക്കുമെന്ന് ഇത് മാറുന്നു, ഈ ലെയറിനെ അടിസ്ഥാനമാക്കി എല്ലാ പുതിയ ചിത്രങ്ങളും ഇതിനകം തന്നെ പോകും, ​​അല്ലേ?

മുമ്പത്തെ പകർപ്പുകളിൽ നിന്നുള്ള മുൻ പാളികളിൽ നിന്ന്.

മുമ്പത്തെ പാളികൾ വീഴും, പക്ഷേ അവ പഴയ ലെയറിനെ പരാമർശിക്കും, അപ്‌ഡേറ്റിൽ ലഭിച്ച അവസാന ലെയറിൽ നിന്ന് അവർ പുതിയ ചിത്രങ്ങൾ എടുക്കുമോ?

പൊതുവേ, അതെ.

അപ്പോൾ ഒരു അനന്തരഫലമായി നമുക്ക് ഒരു അത്തിപ്പഴം വരെ പാളികൾ ഉണ്ടാകും. കാലക്രമേണ അവ കംപ്രസ് ചെയ്യേണ്ടതുണ്ടോ?

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

ഹലോ, റിപ്പോർട്ടിന് നന്ദി! ജോയെക്കുറിച്ചുള്ള ചോദ്യം. ഉപഭോക്താവ് എല്ലാവർക്കും ഡാറ്റയിലേക്ക് ആക്‌സസ് നൽകാൻ ആഗ്രഹിക്കുന്നില്ലെന്ന് നിങ്ങൾ പറഞ്ഞു. കൃത്യമായി പറഞ്ഞാൽ, ഒരു വ്യക്തിക്ക് വിശദമാക്കൽ വിശകലനത്തിന്റെ ഫലം ഉണ്ടെങ്കിൽ, അയാൾക്ക് ഡാറ്റ പരിശോധിക്കാം.

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

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

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

എനിക്ക് ഈ പാളി ആവശ്യമില്ല, പക്ഷേ എനിക്ക് അത്തരമൊരു അവസരം ആവശ്യമാണ്.

അപ്പോൾ അതെ, അത് ചെയ്യാൻ കഴിയും.

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