പ്രിയ ഇല്ലാതാക്കുക. നിക്കോളായ് സമോഖ്വലോവ് (Postgres.ai)

വിദൂര ഭാവിയിൽ എന്നെങ്കിലും, അനാവശ്യ ഡാറ്റ സ്വയമേവ നീക്കംചെയ്യുന്നത് ഒരു DBMS-ന്റെ പ്രധാന ജോലികളിലൊന്നായിരിക്കും [1]. ഇതിനിടയിൽ, വിലകുറഞ്ഞ സ്റ്റോറേജ് സിസ്റ്റങ്ങളിലേക്ക് അനാവശ്യ ഡാറ്റ ഇല്ലാതാക്കുന്നതിനോ നീക്കുന്നതിനോ നമ്മൾ തന്നെ ശ്രദ്ധിക്കേണ്ടതുണ്ട്. ദശലക്ഷക്കണക്കിന് വരികൾ ഇല്ലാതാക്കാൻ നിങ്ങൾ തീരുമാനിച്ചുവെന്നിരിക്കട്ടെ. വളരെ ലളിതമായ ഒരു ജോലി, പ്രത്യേകിച്ചും അവസ്ഥ അറിയുകയും അനുയോജ്യമായ ഒരു സൂചികയുണ്ടെങ്കിൽ. "പട്ടിക 1-ൽ നിന്ന് ഇല്ലാതാക്കുക എവിടെ col1 = :മൂല്യം" - എന്തായിരിക്കും ലളിതമായത്, അല്ലേ?

വീഡിയോ:

• ആദ്യ വർഷം മുതൽ, അതായത് 2007 മുതൽ ഞാൻ ഹൈലോഡ് പ്രോഗ്രാം കമ്മിറ്റിയിൽ ഉണ്ട്.

• ഞാൻ 2005 മുതൽ പോസ്റ്റ്ഗ്രേസിനൊപ്പമാണ്. പല പദ്ധതികളിലും ഉപയോഗിച്ചു.

• ഗ്രൂപ്പ് 2007 മുതൽ RuPostges-ലും ഉണ്ട്.

• മീറ്റപ്പിൽ 2100+ പങ്കാളികളായി ഞങ്ങൾ വളർന്നു. ന്യൂയോർക്ക് കഴിഞ്ഞാൽ ലോകത്തിലെ രണ്ടാമത്തെ സ്ഥാനമാണിത്, വളരെക്കാലം മുമ്പ് സാൻ ഫ്രാൻസിസ്കോയെ മറികടന്നു.

• ഞാൻ കുറേ വർഷങ്ങളായി കാലിഫോർണിയയിൽ താമസിക്കുന്നു. വലിയ കമ്പനികൾ ഉൾപ്പെടെയുള്ള അമേരിക്കൻ കമ്പനികളിലാണ് ഞാൻ കൂടുതലും പ്രവർത്തിക്കുന്നത്. അവർ സജീവ Postgres ഉപയോക്താക്കളാണ്. എല്ലാത്തരം രസകരമായ കാര്യങ്ങളും അവിടെ ഉയർന്നുവരുന്നു.

https://postgres.ai/ - ഇത് എന്റെ കമ്പനിയാണ്. വികസന മാന്ദ്യങ്ങൾ ഇല്ലാതാക്കുന്ന ടാസ്‌ക്കുകൾ ഓട്ടോമേറ്റ് ചെയ്യുന്ന ബിസിനസ്സിലാണ് ഞങ്ങൾ.

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

https://www.seagate.com/files/www-content/our-story/trends/files/idc-seagate-dataage-whitepaper.pdf

ഞാൻ അടുത്തിടെ ലോസ് ഏഞ്ചൽസിലെ വിഎൽഡിബിയിലായിരുന്നു. ഏറ്റവും വലിയ ഡാറ്റാബേസ് കോൺഫറൻസാണിത്. ഭാവിയിൽ DBMS-കൾ സംഭരിക്കുക മാത്രമല്ല, ഡാറ്റ സ്വയമേവ ഇല്ലാതാക്കുകയും ചെയ്യുമെന്ന് ഒരു റിപ്പോർട്ട് ഉണ്ടായിരുന്നു. ഇതൊരു പുതിയ വിഷയമാണ്.

ലോകത്ത് കൂടുതൽ കൂടുതൽ ഡാറ്റയുണ്ട്, സെറ്റാബൈറ്റുകൾ 1 പെറ്റാബൈറ്റുകളാണ്. ഇപ്പോൾ ലോകത്ത് 000 സെറ്റാബൈറ്റിലധികം ഡാറ്റ സംഭരിച്ചിട്ടുണ്ടെന്ന് ഇതിനകം തന്നെ കണക്കാക്കപ്പെട്ടിരിക്കുന്നു. അവയിൽ കൂടുതൽ കൂടുതൽ ഉണ്ട്.

https://vldb2019.github.io/files/VLDB19-keynote-2-slides.pdf

പിന്നെ എന്ത് ചെയ്യണം? അത് ഇല്ലാതാക്കേണ്ടതുണ്ടെന്ന് വ്യക്തമാണ്. രസകരമായ ഈ റിപ്പോർട്ടിന്റെ ലിങ്ക് ഇതാ. എന്നാൽ ഇതുവരെ ഡിബിഎംഎസിൽ ഇത് നടപ്പാക്കിയിട്ടില്ല.

പണം എണ്ണാൻ അറിയുന്നവർക്ക് രണ്ടു കാര്യങ്ങൾ വേണം. ഞങ്ങൾ ഇല്ലാതാക്കണമെന്ന് അവർ ആഗ്രഹിക്കുന്നു, അതിനാൽ സാങ്കേതികമായി ഞങ്ങൾക്ക് അത് ചെയ്യാൻ കഴിയണം.

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

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

പൊതുവേ, ഒരു പട്ടികയിലെ നിർദ്ദിഷ്ട വരികൾ, നിർദ്ദിഷ്ട കാര്യങ്ങൾ ഇല്ലാതാക്കുന്നത് ഓട്ടോമേറ്റ് ചെയ്യുക എന്നതാണ് ചുമതല.

ഞങ്ങൾ ഇന്ന് സംസാരിക്കുന്ന ഒരു അഭ്യർത്ഥനയുണ്ട്, അതായത്, മാലിന്യം നീക്കം ചെയ്യുന്നതിനെക്കുറിച്ച്.

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

ഡാറ്റാബേസ് വളരുകയും വളരുകയും ചെയ്യുന്നു. ദിവസേനയുള്ള DELETE അൽപ്പം സാവധാനത്തിൽ പ്രവർത്തിക്കാൻ തുടങ്ങുന്നു.

അപ്പോൾ ഞങ്ങൾ ഇപ്പോൾ ഒരു മാർക്കറ്റിംഗ് കമ്പനിയാണെന്നും ട്രാഫിക്ക് നിരവധി മടങ്ങ് വർദ്ധിക്കുമെന്നും ഞങ്ങൾ മനസ്സിലാക്കുന്നു, അതിനാൽ അനാവശ്യ കാര്യങ്ങൾ താൽക്കാലികമായി നിർത്താൻ ഞങ്ങൾ തീരുമാനിക്കുന്നു. ഞങ്ങൾ അത് തിരികെ നൽകാൻ മറക്കുന്നു.

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

അവൻ ദേവ്, സ്റ്റേജിംഗ് എന്നിവ പരിശോധിച്ചു - എല്ലാം ശരിയാണ്. സ്വാഭാവികമായും, നിങ്ങൾ ഇപ്പോഴും ശേഖരിച്ചത് വൃത്തിയാക്കേണ്ടതുണ്ട്. അവൻ പരിശോധിച്ചു, എല്ലാം പ്രവർത്തിക്കുന്നു.

ഇനി എന്ത് സംഭവിക്കും? അപ്പോൾ എല്ലാം നമുക്ക് വേണ്ടി തകരുന്നു. ഇത് വളരെയധികം കുറയുന്നു, ഒരു ഘട്ടത്തിൽ എല്ലാം താഴേക്ക് വീഴുന്നു. എല്ലാവരും ഞെട്ടലിലാണ്, എന്താണ് സംഭവിക്കുന്നതെന്ന് ആർക്കും മനസ്സിലാകുന്നില്ല. തുടർന്ന് ഈ DELETE ആയിരുന്നു പ്രശ്‌നം എന്ന് തെളിഞ്ഞു.

എന്തോ കുഴപ്പം സംഭവിച്ചോ? തെറ്റ് സംഭവിക്കാനിടയുള്ള കാര്യങ്ങളുടെ ഒരു ലിസ്റ്റ് ഇതാ. ഇതിൽ ഏതാണ് ഏറ്റവും പ്രധാനം?

• ഉദാഹരണത്തിന്, ഒരു അവലോകനവും ഇല്ല, അതായത് DBA വിദഗ്ധൻ നോക്കിയില്ല. പരിചയസമ്പന്നനായ ഒരു കണ്ണുകൊണ്ട്, അവൻ ഉടൻ തന്നെ പ്രശ്നം കണ്ടെത്തും, കൂടാതെ, നിരവധി ദശലക്ഷം ലൈനുകൾ അടിഞ്ഞുകൂടിയ പ്രോഡിലേക്ക് അദ്ദേഹത്തിന് ആക്സസ് ഉണ്ട്.

• ഒരുപക്ഷേ അവർ എന്തെങ്കിലും തെറ്റായി പരിശോധിച്ചിരിക്കാം.

• ഒരുപക്ഷേ ഹാർഡ്‌വെയർ കാലഹരണപ്പെട്ടതായിരിക്കാം, നിങ്ങൾ ഈ ഡാറ്റാബേസ് നവീകരിക്കേണ്ടതുണ്ട്.

• അല്ലെങ്കിൽ ഡാറ്റാബേസിൽ തന്നെ എന്തോ കുഴപ്പമുണ്ട്, ഞങ്ങൾ Postgres-ൽ നിന്ന് MySQL-ലേക്ക് മാറേണ്ടതുണ്ട്.

• അല്ലെങ്കിൽ ഓപ്പറേഷനിൽ എന്തെങ്കിലും കുഴപ്പമുണ്ടാവാം.

• ജോലിയുടെ ഓർഗനൈസേഷനിൽ ചില തെറ്റുകൾ ഉണ്ടായേക്കാം, നിങ്ങൾ ആരെയെങ്കിലും പുറത്താക്കുകയും മികച്ച ആളുകളെ നിയമിക്കുകയും ചെയ്യേണ്ടതുണ്ടോ?

ഡിബിഎ പരിശോധനയൊന്നും ഉണ്ടായിരുന്നില്ല. ഒരു ഡി‌ബി‌എ ഉണ്ടായിരുന്നെങ്കിൽ, അദ്ദേഹം ഈ നിരവധി ദശലക്ഷം വരികൾ കാണും, കൂടാതെ ഒരു പരീക്ഷണവുമില്ലാതെ പോലും അദ്ദേഹം പറയും: "അവർ അത് ചെയ്യുന്നില്ല." ഈ കോഡ് GitLab, GitHub എന്നിവയിലായിരുന്നെങ്കിൽ, ഒരു കോഡ് അവലോകന പ്രക്രിയ ഉണ്ടായിരുന്നെങ്കിൽ, DBA അംഗീകാരമില്ലാതെ ഈ ഓപ്പറേഷൻ പ്രോഡിൽ നടക്കുമെന്ന് അങ്ങനെയൊന്നും ഇല്ലായിരുന്നുവെങ്കിൽ, DBA വ്യക്തമായി പറയും: “നിങ്ങൾക്ക് അത് ചെയ്യാൻ കഴിയില്ല. ”

നിങ്ങൾക്ക് ഡിസ്ക് ഐഒയിൽ പ്രശ്‌നങ്ങളുണ്ടാകുമെന്നും എല്ലാ പ്രക്രിയകളും ഭ്രാന്തനാകുമെന്നും ലോക്കുകൾ ഉണ്ടാകാമെന്നും നിങ്ങൾ ഓട്ടോവാക്വം കുറച്ച് മിനിറ്റ് തടയുമെന്നും അദ്ദേഹം പറയും, അതിനാൽ ഇത് നല്ലതല്ല.

http://bit.ly/nancy-hl2018-2

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

ഞങ്ങളുടെ പരിശോധനകൾ ദുർബലമാണെന്ന് ഞങ്ങൾ മനസ്സിലാക്കുന്നു, അതായത് നിർമ്മിച്ച പ്രക്രിയ പ്രശ്നങ്ങൾ പിടിപെടുന്നില്ല. മതിയായ DB പരീക്ഷണം നടത്തിയില്ല.

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

ഒരുപക്ഷേ ഞങ്ങളുടെ ഉപകരണങ്ങൾ മോശമാണോ? നോക്കിയാൽ ലേറ്റൻസി കുതിച്ചു. പുനരുപയോഗം 100% ആണെന്ന് ഞങ്ങൾ കണ്ടു. തീർച്ചയായും, ഇവ ആധുനിക NVMe ഡ്രൈവുകളാണെങ്കിൽ, അത് ഞങ്ങൾക്ക് വളരെ എളുപ്പമായിരിക്കും. ഒരുപക്ഷെ അത് കാരണം ഞങ്ങൾ കിടക്കില്ല.

നിങ്ങൾക്ക് മേഘങ്ങളുണ്ടെങ്കിൽ, നവീകരണം എളുപ്പമാണ്. പുതിയ ഹാർഡ്‌വെയറിൽ ഞങ്ങൾ പുതിയ പകർപ്പുകൾ സമാരംഭിച്ചു. മാറാൻ. പിന്നെ എല്ലാം ശുഭം. വളരെ എളുപ്പമാണ്.

ചെറിയ ഡിസ്കുകൾ എങ്ങനെയെങ്കിലും സ്പർശിക്കാൻ കഴിയുമോ? ഇവിടെ, DBA- യുടെ സഹായത്തോടെ, ചെക്ക്‌പോയിന്റ് ട്യൂണിംഗ് എന്ന ഒരു പ്രത്യേക വിഷയത്തിലേക്ക് ഞങ്ങൾ മുഴുകുന്നു. ഞങ്ങൾ ചെക്ക്‌പോയിന്റ് ട്യൂണിംഗ് നടത്തിയിട്ടില്ലെന്ന് ഇത് മാറുന്നു.

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

Postgres-ലെ ക്രമീകരണങ്ങൾ പിന്നിലാണ്. അവ 10-15 വർഷം പഴക്കമുള്ള ഡാറ്റയ്ക്കും പ്രവർത്തനങ്ങൾക്കുമായി രൂപകൽപ്പന ചെയ്‌തിരിക്കുന്നു. കൂടാതെ ചെക്ക് പോയിന്റും ഒരു അപവാദമല്ല.

ഈ വിവരങ്ങൾ പോസ്റ്റ്‌ഗ്രെസ് പരിശോധനയ്‌ക്കൊപ്പമുള്ള ഞങ്ങളുടെ റിപ്പോർട്ടിൽ നിന്നുള്ളതാണ്, അതായത് സ്വയമേവയുള്ള ആരോഗ്യ പരിശോധന. നിരവധി ടെറാബൈറ്റുകളുടെ ചില ഡാറ്റാബേസ് ഇതാ. 90% കേസുകളിലും ചെക്ക്‌പോസ്റ്റുകൾ നിർബന്ധിതമാണെന്ന് വ്യക്തമാണ്.

എന്താണ് ഇതിനർത്ഥം? അവിടെ രണ്ട് ക്രമീകരണങ്ങൾ ഉണ്ട്. ചെക്ക് പോയിന്റ് ടൈംഔട്ടിൽ സംഭവിക്കാം, ഉദാഹരണത്തിന്, 10 മിനിറ്റിനുള്ളിൽ. അല്ലെങ്കിൽ ധാരാളം ഡാറ്റ പൂരിപ്പിക്കുമ്പോൾ അത് സംഭവിക്കാം.

സ്ഥിരസ്ഥിതിയായി, max_wal_saze 1 ജിഗാബൈറ്റായി സജ്ജീകരിച്ചിരിക്കുന്നു. വാസ്തവത്തിൽ, ഇത് 300-400 മെഗാബൈറ്റിന് ശേഷം പോസ്റ്റ്ഗ്രേസിൽ സംഭവിക്കുന്നു. നിങ്ങൾ വളരെയധികം ഡാറ്റ മാറ്റി, നിങ്ങൾക്ക് ഒരു ചെക്ക് പോയിന്റുണ്ട്.

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

മാത്രമല്ല, ഇത് കുറച്ച് തവണ മാത്രമേ വരുന്നുള്ളൂവെന്ന് ഉറപ്പാക്കേണ്ടതുണ്ട്. അതായത്, നമുക്ക് max_wal_size ഉയർത്താം. അവൻ കുറച്ച് തവണ ആക്രമിക്കും.

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

അതനുസരിച്ച്, ഞങ്ങൾ രണ്ട് ശ്രേണി ഡാറ്റാബേസ് പരീക്ഷണങ്ങൾ നടത്തുന്നു.

ആദ്യ സീരീസ് - ഞങ്ങൾ max_wal_size മാറ്റുന്നു. ഞങ്ങൾ ഒരു വലിയ ഓപ്പറേഷൻ നടത്തുന്നു. ആദ്യം നമ്മൾ 1 ജിഗാബൈറ്റിന്റെ സ്ഥിരസ്ഥിതി ക്രമീകരണത്തിലാണ് ഇത് ചെയ്യുന്നത്. ഞങ്ങൾ ദശലക്ഷക്കണക്കിന് ലൈനുകളുടെ ഒരു വലിയ ഡിലീറ്റ് ചെയ്യുന്നു.

ഇത് ഞങ്ങൾക്ക് എത്ര ബുദ്ധിമുട്ടാണെന്ന് നിങ്ങൾക്ക് കാണാൻ കഴിയും. ഡിസ്ക് IO വളരെ മോശമാണെന്ന് ഞങ്ങൾ കാണുന്നു. നമ്മൾ എത്ര WAL സൃഷ്ടിച്ചുവെന്ന് നോക്കാം, കാരണം ഇത് വളരെ പ്രധാനമാണ്. എത്ര പ്രാവശ്യം ചെക്ക്‌പോസ്റ്റ് നടന്നുവെന്ന് നോക്കാം. അത് നല്ലതല്ലെന്ന് ഞങ്ങൾ കാണുന്നു.

അടുത്തതായി ഞങ്ങൾ max_wal_size വർദ്ധിപ്പിക്കുന്നു. ഞങ്ങൾ ആവർത്തിക്കുന്നു. വർദ്ധിപ്പിക്കുക, ആവർത്തിക്കുക. അങ്ങനെ പലതവണ. തത്വത്തിൽ, 10 പോയിന്റുകൾ നല്ലതാണ്, ഇവിടെ 1, 2, 4, 8 ജിഗാബൈറ്റുകൾ. ഒരു നിർദ്ദിഷ്ട സിസ്റ്റത്തിന്റെ പെരുമാറ്റം ഞങ്ങൾ നോക്കുന്നു. ഇവിടെയുള്ള ഉപകരണങ്ങൾ പ്രോഡിൽ പോലെ ആയിരിക്കണം എന്ന് വ്യക്തമാണ്. നിങ്ങൾക്ക് ഒരേ ഡിസ്കുകളും അതേ അളവിലുള്ള മെമ്മറിയും അതേ പോസ്റ്റ്ഗ്രെസ് ക്രമീകരണങ്ങളും ഉണ്ടായിരിക്കണം.

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

റഷ്യൻ ഭാഷയിൽ ചെക്ക് പോയിന്റ് എന്നാൽ നിയന്ത്രണ പോയിന്റുകൾ എന്നാണ് അർത്ഥമാക്കുന്നത്.

ഉദാഹരണം: സൂചിക പ്രകാരം നിരവധി ദശലക്ഷം വരികൾ ഇല്ലാതാക്കുക, വരികൾ പേജുകളിലുടനീളം "ചിതറിക്കിടക്കുന്നു".

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

പ്രോഡിൽ അത്തരമൊരു പ്രവർത്തനം അനുവദിച്ചാൽ, ഞങ്ങൾ താഴെ വീഴും, കാരണം ഒരു ഡിലീറ്റ് ഞങ്ങളെ ഷെൽഫിൽ കൊല്ലുന്നുവെന്ന് വ്യക്തമാണ്.

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

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

എന്തുകൊണ്ടാണ് ഇത്?

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

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

ഞങ്ങൾ ചെക്ക് പോയിന്റിനെ പലതവണ സേവ് ചെയ്യാൻ നിർബന്ധിക്കും. അതിനായി അനാവശ്യ ഓപ്പറേഷനുകൾ ഉള്ളതുപോലെ.

എന്നാൽ അത് മാത്രമല്ല. പോസ്റ്റ്ഗ്രേസിൽ, പേജുകൾക്ക് 8 കിലോബൈറ്റും ലിനക്സിൽ 4 കിലോബൈറ്റും ഭാരമുണ്ട്. ഒപ്പം full_page_writes എന്ന ക്രമീകരണവും ഉണ്ട്. ഇത് സ്ഥിരസ്ഥിതിയായി പ്രവർത്തനക്ഷമമാക്കിയിരിക്കുന്നു. ഇത് ശരിയാണ്, കാരണം ഞങ്ങൾ ഇത് ഓഫാക്കിയാൽ, ഒരു പരാജയം സംഭവിച്ചാൽ, പേജിന്റെ പകുതി മാത്രമേ സംരക്ഷിക്കപ്പെടൂ എന്ന അപകടമുണ്ട്.

ഫോർവേഡ് ലോഗിന്റെ WAL-ലെ എൻട്രിയുടെ സ്വഭാവം, നമുക്ക് ഒരു ചെക്ക്‌പോയിന്റ് ഉള്ളപ്പോൾ, ഞങ്ങൾ ആദ്യമായി ഒരു പേജ് മാറ്റുമ്പോൾ, മുഴുവൻ പേജും, അതായത്, എല്ലാ 8 കിലോബൈറ്റുകളും, ഫോർവേഡ് ലോഗിൽ അവസാനിക്കുന്നു, എന്നിരുന്നാലും ഞങ്ങൾ മാത്രം 100 ബൈറ്റുകൾ ഭാരമുള്ള ഒരു വരി മാറ്റി. കൂടാതെ മുഴുവൻ പേജും എഴുതാൻ ഞങ്ങൾ നിർബന്ധിതരാകുന്നു.

തുടർന്നുള്ള മാറ്റങ്ങളിൽ ഒരു പ്രത്യേക ട്യൂപ്പിൾ മാത്രമേ ഉണ്ടാകൂ, എന്നാൽ ആദ്യമായി ഞങ്ങൾ എല്ലാം എഴുതുന്നു.

അതനുസരിച്ച്, ചെക്ക്‌പോയിന്റ് വീണ്ടും സംഭവിക്കുകയാണെങ്കിൽ, ഞങ്ങൾ ആദ്യം മുതൽ എല്ലാം വീണ്ടും ആരംഭിക്കുകയും പേജ് മുഴുവൻ ക്രാം ചെയ്യുകയും വേണം. ഇടയ്‌ക്കിടെയുള്ള ചെക്ക്‌പോസ്റ്റുകൾക്കൊപ്പം, ഞങ്ങൾ ഒരേ പേജുകളിലൂടെ നടക്കുമ്പോൾ, full_page_writes = on അത് കഴിയുന്നതിലും വലുതായിരിക്കും, അതായത് ഞങ്ങൾ കൂടുതൽ WAL സൃഷ്ടിക്കുന്നു. കൂടുതൽ പകർപ്പുകളിലേക്കും ആർക്കൈവിലേക്കും ഡിസ്കിലേക്കും അയയ്ക്കുന്നു.

അതനുസരിച്ച്, ഞങ്ങൾക്ക് രണ്ട് ആവർത്തനങ്ങളുണ്ട്.

ഞങ്ങൾ max_wal_size വർദ്ധിപ്പിക്കുകയാണെങ്കിൽ, ചെക്ക് പോയിന്റിന്റെയും വാൾ റൈറ്ററിന്റെയും പ്രവർത്തനം ഞങ്ങൾ എളുപ്പമാക്കുന്നു. അത് കൊള്ളാം.

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

ഞങ്ങൾ ഓപ്പറേഷൻ നടത്തുകയും ചെക്ക്‌പോയിന്റ് പൂർത്തിയാകാറായപ്പോൾ കാണുകയും ചെയ്യുന്നു, ഞങ്ങൾ മനഃപൂർവം ഒരു കിൽ -9 പോസ്റ്റ്‌ഗ്രെസ് ചെയ്യുന്നു.

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

സ്ഥിതി മോശമാണെന്ന് ഞാൻ രണ്ടുതവണ ശ്രദ്ധിക്കും. ഒന്നാമതായി, ചെക്ക്‌പോയിന്റ് അവസാനിക്കുന്നതിന് തൊട്ടുമുമ്പ് ഞങ്ങൾ വീണു, അതിനാൽ ഞങ്ങൾക്ക് ഒരുപാട് നഷ്ടപ്പെടാനുണ്ട്. രണ്ടാമതായി, ഞങ്ങൾക്ക് ഒരു വലിയ ഓപ്പറേഷൻ ഉണ്ടായിരുന്നു. ചെക്ക്‌പോസ്റ്റുകൾക്ക് കാലഹരണപ്പെട്ടാൽ, അവസാന ചെക്ക്‌പോയിന്റിന് ശേഷം ഏറ്റവും കുറവ് WAL സൃഷ്ടിക്കപ്പെടുമായിരുന്നു. അതായത്, ഇത് രണ്ടുതവണ തോറ്റതാണ്.

വ്യത്യസ്‌ത max_wal_size-നുള്ള ഈ സാഹചര്യം ഞങ്ങൾ അളക്കുകയും max_wal_size 64 ജിഗാബൈറ്റ് ആണെങ്കിൽ, ഇരട്ടി മോശമായ സാഹചര്യത്തിൽ ഞങ്ങൾ 10 മിനിറ്റ് ഉയരുമെന്ന് മനസ്സിലാക്കുകയും ചെയ്യുന്നു. ഇത് നമുക്ക് അനുയോജ്യമാണോ അല്ലയോ എന്ന് ഞങ്ങൾ ചിന്തിക്കുന്നു. ഇതൊരു ബിസിനസ് പ്രശ്നമാണ്. ബിസിനസ്സ് തീരുമാനങ്ങൾക്ക് ഉത്തരവാദികളായവരെ ഈ ചിത്രം കാണിച്ച് ഞങ്ങൾ ചോദിക്കേണ്ടതുണ്ട്: “ഒരു പ്രശ്നമുണ്ടായാൽ നമുക്ക് കാത്തിരിക്കാൻ കഴിയുന്ന പരമാവധി സമയം എത്രയാണ്? മോശമായ അവസ്ഥയിൽ 3-5 മിനിറ്റ് കിടക്കാൻ കഴിയുമോ? എന്നിട്ട് നിങ്ങൾ ഒരു തീരുമാനം എടുക്കുക.

പിന്നെ ഇവിടെ ഒരു രസകരമായ പോയിന്റുണ്ട്. സമ്മേളനത്തിൽ പത്രോണിയെക്കുറിച്ച് ഞങ്ങൾക്ക് രണ്ട് റിപ്പോർട്ടുകൾ ഉണ്ട്. ഒരുപക്ഷേ നിങ്ങൾ അത് ഉപയോഗിക്കുന്നുണ്ടാകാം. പോസ്റ്റ്‌ഗ്രെസിന്റെ സ്വയം പരാജയമാണിത്. GitLab ഉം Data Egret ഉം ഇതിനെക്കുറിച്ച് സംസാരിച്ചു.

നിങ്ങൾക്ക് 30 സെക്കൻഡിനുള്ളിൽ സംഭവിക്കുന്ന ഒരു ഓട്ടോഫെയ്‌ലോവർ ഉണ്ടെങ്കിൽ, നമുക്ക് 10 മിനിറ്റ് കിടക്കാൻ കഴിയുമോ? കാരണം ഈ സമയത്ത് ഞങ്ങൾ പകർപ്പിലേക്ക് മാറും, എല്ലാം ശരിയാകും. ഇതൊരു വിവാദ വിഷയമാണ്. വ്യക്തമായ ഉത്തരം എനിക്കറിയില്ല. ഈ വിഷയം ദുരന്തനിവാരണത്തെ ചുറ്റിപ്പറ്റി മാത്രമല്ലെന്ന് എനിക്ക് തോന്നുന്നു.

ഒരു പരാജയത്തിൽ നിന്ന് നമുക്ക് ദീർഘനാളത്തെ വീണ്ടെടുക്കൽ ഉണ്ടെങ്കിൽ, മറ്റ് പല സാഹചര്യങ്ങളിലും നമുക്ക് അസ്വസ്ഥതയുണ്ടാകും. ഉദാഹരണത്തിന്, അതേ പരീക്ഷണങ്ങളിൽ, നമ്മൾ എന്തെങ്കിലും ചെയ്യുമ്പോൾ, ചിലപ്പോൾ 10 മിനിറ്റ് കാത്തിരിക്കേണ്ടി വരും.

ഞങ്ങൾക്ക് ഓട്ടോഫെയ്‌ലോവർ ഉണ്ടെങ്കിലും ഞാൻ ഇപ്പോഴും അധികം പോകില്ല. ചട്ടം പോലെ, 64, 100 ജിഗാബൈറ്റുകൾ പോലുള്ള മൂല്യങ്ങൾ നല്ല മൂല്യങ്ങളാണ്. ചിലപ്പോൾ കുറച്ച് തിരഞ്ഞെടുക്കുന്നത് പോലും വിലമതിക്കുന്നു. പൊതുവേ, ഇതൊരു സൂക്ഷ്മ ശാസ്ത്രമാണ്.

ആവർത്തിക്കുന്നതിന്, ഉദാഹരണത്തിന്, max_wal_size = 1, 8, നിങ്ങൾ മാസ് ഓപ്പറേഷൻ നിരവധി തവണ ആവർത്തിക്കേണ്ടതുണ്ട്. നീ അതു ചെയ്തു. നിങ്ങൾ അത് വീണ്ടും അതേ അടിസ്ഥാനത്തിൽ ചെയ്യാൻ ആഗ്രഹിക്കുന്നു, എന്നാൽ നിങ്ങൾ ഇതിനകം എല്ലാം ഇല്ലാതാക്കി. എന്തുചെയ്യും?

ഞങ്ങളുടെ പരിഹാരത്തെക്കുറിച്ചും അത്തരം സാഹചര്യങ്ങളിൽ ആവർത്തിക്കാൻ ഞങ്ങൾ എന്തുചെയ്യുന്നുവെന്നതിനെക്കുറിച്ചും ഞാൻ പിന്നീട് നിങ്ങളോട് പറയും. ഇത് ഏറ്റവും ശരിയായ സമീപനമാണ്.

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

നിങ്ങൾക്ക് ശരിയായി വിന്യസിച്ച ഡാറ്റാബേസ് ലാബുകൾ ഇല്ലെങ്കിൽപ്പോലും, ROLLBACK ഉള്ള ഈ ഇല്ലാതാക്കൽ ചെക്ക്‌പോയിന്റ് ട്യൂണിംഗിന് അനുയോജ്യമാണ്.

"i" എന്ന ഒരു നിര ഉപയോഗിച്ച് ഞങ്ങൾ ഒരു അടയാളം ഉണ്ടാക്കി. പോസ്റ്റ്ഗ്രേസിന് സേവന നിരകളുണ്ട്. പ്രത്യേകം ആവശ്യപ്പെട്ടില്ലെങ്കിൽ അവ അദൃശ്യമാണ്. ഇവയാണ്: ctid, xmid, xmax.

Ctid എന്നത് ഭൗതിക വിലാസമാണ്. പേജ് പൂജ്യം, പേജിലെ ആദ്യത്തെ ട്യൂപ്പിൾ.

ROOLBACK ന് ശേഷം ട്യൂപ്പിൾ അതേ സ്ഥലത്ത് തന്നെ തുടരുന്നതായി കാണാം. അതായത്, നമുക്ക് വീണ്ടും ശ്രമിക്കാം, അത് അതേ രീതിയിൽ പെരുമാറും. ഇതാണ് പ്രധാന കാര്യം.

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

ഇത് പ്രോഗ്രാമർമാരെക്കുറിച്ചാണ്. DBA യെ കുറിച്ചും അവർ പ്രോഗ്രാമർമാരെ എപ്പോഴും ശകാരിക്കുന്നു: "നിങ്ങൾ എന്തിനാണ് ഇത്രയും നീണ്ടതും ബുദ്ധിമുട്ടുള്ളതുമായ പ്രവർത്തനങ്ങൾ ചെയ്യുന്നത്?" ഇത് തികച്ചും വ്യത്യസ്തമായ ലംബമായ വിഷയമാണ്. മുമ്പ് ഭരണം ഉണ്ടായിരുന്നു, എന്നാൽ ഇപ്പോൾ വികസനം ഉണ്ടാകും.

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

ബ്രേക്കിംഗ് പ്രധാനമായിരിക്കുന്നത് എന്തുകൊണ്ട്?

• ഡിസ്ക് ഹാർഡ് ആണെന്ന് കണ്ടാൽ, നമുക്ക് വേഗത കുറയ്ക്കാം. നമ്മൾ തകരാറിലാണെങ്കിൽ, നമുക്ക് താൽക്കാലികമായി നിർത്താം, ത്രോട്ടിലിംഗ് മന്ദഗതിയിലാക്കാം.

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

https://postgres.ai/products/joe/

ഇത് രസകരമാണ്. “ഞാൻ ഏത് പായ്ക്ക് വലുപ്പമാണ് തിരഞ്ഞെടുക്കേണ്ടത്?” എന്ന് ഡവലപ്പർമാർ ചോദിക്കുന്നത് ഞാൻ പലപ്പോഴും കാണാറുണ്ട്.

വലിയ ബാച്ച് വലുപ്പം, ഇടപാട് ഓവർഹെഡ്, അതായത് അധിക ഇടപാട് ഓവർഹെഡ് കുറയുമെന്ന് വ്യക്തമാണ്. എന്നാൽ അതേ സമയം, ഈ ഇടപാടിനുള്ള സമയം വർദ്ധിക്കുന്നു.

എനിക്ക് വളരെ ലളിതമായ ഒരു നിയമമുണ്ട്: കഴിയുന്നത്ര എടുക്കുക, എന്നാൽ സെക്കൻഡിൽ എക്സിക്യൂഷൻ കവിയരുത്.

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

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

ഞങ്ങൾ പായ്ക്ക് വലുപ്പം തിരഞ്ഞെടുക്കുന്നു. ഓരോ സാഹചര്യത്തിലും നമുക്ക് ഇത് വ്യത്യസ്തമായി ചെയ്യാൻ കഴിയും. ഓട്ടോമേറ്റ് ചെയ്യാം. ഒരു പായ്ക്ക് പ്രോസസ്സ് ചെയ്യുന്നതിന്റെ കാര്യക്ഷമതയെക്കുറിച്ച് ഞങ്ങൾക്ക് ബോധ്യമുണ്ട്. അതായത്, ഞങ്ങൾ ഒരു പായ്ക്ക് ഇല്ലാതാക്കുകയോ അപ്ഡേറ്റ് ചെയ്യുകയോ ചെയ്യുന്നു.

വഴിയിൽ, ഞാൻ നിങ്ങളോട് പറയുന്നതെല്ലാം ഇല്ലാതാക്കുന്നതിനെ കുറിച്ച് മാത്രമല്ല. നിങ്ങൾ ഊഹിച്ചതുപോലെ, ഇവ ഡാറ്റയിലെ ഏതെങ്കിലും ബൾക്ക് പ്രവർത്തനങ്ങളാണ്.

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

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

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

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

https://docs.gitlab.com/ee/development/background_migrations.html

വിഭജന തന്ത്രങ്ങൾ എന്തൊക്കെയാണ്? ഡെവലപ്പർമാർ പാക്കിൽ ഉപയോഗിക്കുന്ന 3 വ്യത്യസ്ത പാർട്ടീഷനിംഗ് തന്ത്രങ്ങൾ ഞാൻ കാണുന്നു.

ആദ്യത്തേത് വളരെ ലളിതമാണ്. ഞങ്ങൾക്ക് ഒരു സംഖ്യാ ഐഡി ഉണ്ട്. നമുക്ക് അതിനെ വ്യത്യസ്ത ഇടവേളകളായി വിഭജിച്ച് അതിനോടൊപ്പം പ്രവർത്തിക്കാം. പോരായ്മ വ്യക്തമാണ്. ആദ്യ സെഗ്‌മെന്റിൽ, നമുക്ക് 100 വരി യഥാർത്ഥ മാലിന്യങ്ങൾ ഉണ്ടായിരിക്കാം, രണ്ടാമത്തെ 5 വരികളിൽ അല്ലെങ്കിൽ ഇല്ല, അല്ലെങ്കിൽ എല്ലാ 1 വരികളും മാലിന്യമായി മാറും. വളരെ അസമമായ ജോലി, പക്ഷേ തകർക്കാൻ എളുപ്പമാണ്. മാക്സിമം ഐഡി എടുത്ത് തകർത്തു. ഇതൊരു നിഷ്കളങ്കമായ സമീപനമാണ്.

രണ്ടാമത്തെ തന്ത്രം സമതുലിതമായ സമീപനമാണ്. ഇത് Gitlab-ൽ ഉപയോഗിക്കുന്നു. ഞങ്ങൾ മേശ എടുത്തു സ്കാൻ ചെയ്തു. ഓരോ പാക്കിലും കൃത്യമായി 10 റെക്കോർഡുകൾ അടങ്ങിയ ഐഡി പാക്കുകളുടെ അതിരുകൾ ഞങ്ങൾ കണ്ടെത്തി. അവർ എന്നെ ഒരുതരം ക്യൂവിൽ നിർത്തി. ഞങ്ങൾ കൂടുതൽ പ്രോസസ്സ് ചെയ്യുന്നു. നിങ്ങൾക്ക് ഇത് നിരവധി ത്രെഡുകളിൽ ചെയ്യാൻ കഴിയും.

ആദ്യ തന്ത്രത്തിൽ, നിങ്ങൾക്ക് ഇത് നിരവധി ത്രെഡുകളിലും ചെയ്യാം. അത് ബുദ്ധിമുട്ടുള്ള കാര്യമല്ല.

https://medium.com/@samokhvalov/how-partial-indexes-affect-update-performance-in-postgres-d05e0052abc

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

സാധാരണഗതിയിൽ, ഇൻഡക്സ് സ്കാൻ ചെയ്യുന്നതിനേക്കാൾ വേഗതയുള്ളതാണ് ഇൻഡക്സ് ഒൺലി സ്കാൻ.

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

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

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

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

എന്നാൽ ഇത് ഏറ്റവും ഒപ്റ്റിമൽ തന്ത്രമാണ്, ഇത് എങ്ങനെ ബാച്ചുകളായി വിഭജിക്കാം, ഒരു അഭ്യർത്ഥനയോടെ ബാച്ചുകളായി ഷൂട്ട് ചെയ്യുക, ഒരു സമയം കുറച്ച് ഇല്ലാതാക്കുക തുടങ്ങിയവ.

നീണ്ട ഇടപാടുകൾ - https://gitlab.com/snippets/1890447

തടഞ്ഞ ഓട്ടോവാക്വം https://gitlab.com/snippets/1889668

തടയൽ പ്രശ്നം https://gitlab.com/snippets/1890428

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

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

ഒരു വലിയ IO ഉണ്ടെങ്കിൽ, ഇത് നല്ലതല്ലെന്ന് വ്യക്തമാണ്.

നീണ്ട ഇടപാടുകളും. OLTP-യിൽ ദൈർഘ്യമേറിയ ഇടപാടുകൾ അനുവദിക്കരുത്. സ്‌നിപ്പെറ്റിലേക്കുള്ള ഒരു ലിങ്ക് ഇതാ, ഈ സ്‌നിപ്പെറ്റ് എടുക്കാനും ഇതിനകം തന്നെ ദൈർഘ്യമേറിയ ഇടപാടുകൾ ട്രാക്കുചെയ്യാനും നിങ്ങളെ അനുവദിക്കുന്നു.

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

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

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

ചിലപ്പോൾ ഈ പിശകുകളെല്ലാം ഒരുമിച്ച് സംഭവിക്കുന്നു.

എന്റെ അഭിപ്രായത്തിൽ, ഇവിടെ ഏറ്റവും പ്രധാനപ്പെട്ട തെറ്റ് സംഘടനാപരമായതാണ്. ഇത് സംഘടനാപരമായതാണ്, കാരണം സാങ്കേതികവിദ്യ പ്രവർത്തിക്കുന്നില്ല. ഇത് നമ്പർ 2 ആണ് - അവർ തെറ്റായ സ്ഥലത്ത് പരിശോധിച്ചു.

പരിശോധിക്കാൻ എളുപ്പമുള്ള ഒരു പ്രൊഡക്ഷൻ ക്ലോൺ ഞങ്ങളുടെ പക്കലില്ലാത്തതിനാൽ ഞങ്ങൾ അവിടെ പരിശോധിച്ചില്ല. ഡെവലപ്പർക്ക് ഉൽപ്പാദനത്തിലേക്ക് പ്രവേശനം ഇല്ലായിരിക്കാം.

ഞങ്ങൾ തെറ്റായ സ്ഥലത്ത് പരിശോധിച്ചു. അവർ അവിടെ ചെക്ക് ചെയ്തിരുന്നെങ്കിൽ നമ്മൾ തന്നെ കാണുമായിരുന്നു. ഒരേ അളവിലുള്ള ഡാറ്റയും സമാനമായ ക്രമീകരണവും ഉള്ള ഒരു നല്ല പരിതസ്ഥിതിയിൽ പരിശോധിച്ചാൽ ഡവലപ്പർക്ക് DBA ഇല്ലാതെ പോലും ഇതെല്ലാം കാണാൻ കഴിയും. ഈ അധഃപതനമെല്ലാം കണ്ടു നാണിച്ചു പോകുമായിരുന്നു.

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

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

നമ്മൾ ചെയ്യുന്നത് ഓപ്പൺ സോഴ്സ് ആണ്. ഇത് GitLab-ൽ പോസ്റ്റ് ചെയ്തിട്ടുണ്ട്. DBA ഇല്ലാതെ പോലും ആളുകൾക്ക് പരിശോധിക്കാൻ കഴിയുന്ന തരത്തിലാണ് ഞങ്ങൾ ഇത് നിർമ്മിക്കുന്നത്. ഞങ്ങൾ ഒരു ഡാറ്റാബേസ് ലാബ് ഉണ്ടാക്കുന്നു, അതായത്, ജോ നിലവിൽ പ്രവർത്തിക്കുന്ന അടിസ്ഥാന ഘടകത്തെ ഞങ്ങൾ വിളിക്കുന്നു. നിങ്ങൾക്ക് നിർമ്മാണത്തിന്റെ ഒരു പകർപ്പ് എടുക്കാം. ഇപ്പോൾ ജോ ഫോർ സ്ലാക്ക് നടപ്പിലാക്കുന്നു, നിങ്ങൾക്ക് അവിടെ ഇങ്ങനെ പറയാം: "അത്തരമൊരു അഭ്യർത്ഥന വിശദീകരിക്കുക", നിങ്ങളുടെ ഡാറ്റാബേസിന്റെ പകർപ്പിന്റെ ഫലം ഉടനടി നേടുക. നിങ്ങൾക്ക് അവിടെ DELETE ചെയ്യാനും കഴിയും, ആരും ശ്രദ്ധിക്കില്ല.

നിങ്ങൾക്ക് 10 ടെറാബൈറ്റുകൾ ഉണ്ടെന്ന് പറയാം, ഞങ്ങൾ ഒരു ഡാറ്റാബേസ് ലാബും 10 ടെറാബൈറ്റ് ഉണ്ടാക്കുകയാണ്. കൂടാതെ 10 ഡവലപ്പർമാർക്ക് ഒരേസമയം 10 ​​ടെറാബൈറ്റ് ഡാറ്റാബേസുകൾക്കൊപ്പം ഒരേസമയം പ്രവർത്തിക്കാനാകും. എല്ലാവർക്കും അവർക്കാവശ്യമുള്ളത് ചെയ്യാം. ഇല്ലാതാക്കാനും ഡ്രോപ്പ് ചെയ്യാനും മറ്റും കഴിയും. ഇത് അതിശയകരമാണ്. നാളെ നമ്മൾ ഇതിനെക്കുറിച്ച് സംസാരിക്കും.

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

ഉദാഹരണം: 5 ടെറാബൈറ്റ് ഡാറ്റാബേസ്, 30 സെക്കൻഡിനുള്ളിൽ ഒരു പകർപ്പ് നേടുന്നു. കൂടാതെ അത് വലിപ്പത്തെ പോലും ആശ്രയിക്കുന്നില്ല, അതായത് എത്ര ടെറാബൈറ്റുകൾ എന്നത് പ്രശ്നമല്ല.

ഇന്ന് നിങ്ങൾക്ക് പോകാം postgres.AI ഞങ്ങളുടെ ഉപകരണങ്ങളിൽ കുഴിച്ചിടുക. നിങ്ങൾക്ക് രജിസ്റ്റർ ചെയ്യാനും അവിടെ എന്താണ് ഉള്ളതെന്ന് കാണാനും കഴിയും. നിങ്ങൾക്കായി ഈ ബോട്ട് ഇൻസ്റ്റാൾ ചെയ്യാം. ഇത് സൗജന്യമാണ്. എഴുതുക.

ചോദ്യങ്ങൾ

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

ഇത് വളരെ നല്ല സമീപനവും വളരെ നല്ല ദൗത്യവുമാണ്. ഇത് pg_repack ചെയ്യുന്നതുമായി വളരെ സാമ്യമുള്ളതാണ്, നിങ്ങൾ ഐഡി ആളുകൾ ഇത് 4 ബൈറ്റുകൾ ആക്കുമ്പോൾ നിങ്ങൾ ചെയ്യേണ്ടതിന് സമാനമാണ് ഇത്. പല ചട്ടക്കൂടുകളും വർഷങ്ങൾക്ക് മുമ്പ് ഇത് ചെയ്തു, പ്ലേറ്റുകൾ ഇപ്പോൾ വലുതായി വളർന്നു, അവ 8 ബൈറ്റുകളായി പരിവർത്തനം ചെയ്യേണ്ടതുണ്ട്.

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

നിങ്ങൾ GitHub-ൽ pg_repack നോക്കുകയാണെങ്കിൽ, ID int 4-ൽ നിന്ന് int 8-ലേക്ക് പരിവർത്തനം ചെയ്യാനുള്ള ഒരു ടാസ്‌ക് ഉള്ളപ്പോൾ, pg_repack തന്നെ ഉപയോഗിക്കാൻ ഒരു ആശയം ഉണ്ടായിരുന്നു. ഇതും സാധ്യമാണ്, എന്നാൽ ഇത് ഒരു ഹാക്കർ രീതിയാണ്, പക്ഷേ ഇതിന് ഇത് പ്രവർത്തിക്കും. നിങ്ങൾക്ക് pg_repack ഉപയോഗിക്കുന്ന ട്രിഗറിൽ ഇടപെട്ട് അവിടെ പറയാനാകും: “ഞങ്ങൾക്ക് ഈ ഡാറ്റ ആവശ്യമില്ല,” അതായത് ഞങ്ങൾക്ക് ആവശ്യമുള്ളത് മാത്രം ഞങ്ങൾ കൈമാറുന്നു. എന്നിട്ട് അവൻ സ്വിച്ചുചെയ്യുന്നു, അത്രമാത്രം.

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

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

ഞാൻ MySQL ലോകത്തിൽ നിന്നുള്ള ആളാണ്, അതിനാൽ ഞാൻ കേൾക്കാൻ വന്നു. ഞങ്ങൾ ഈ സമീപനം ഉപയോഗിക്കുന്നു.

എന്നാൽ 90% ഉണ്ടെങ്കിൽ മാത്രം. ഞങ്ങൾക്ക് 5% ഉണ്ടെങ്കിൽ, അത് ഉപയോഗിക്കുന്നത് വളരെ നല്ലതല്ല.

റിപ്പോർട്ടിന് നന്ദി! പ്രോഡിൻറെ പൂർണ്ണമായ പകർപ്പ് ഉണ്ടാക്കാൻ ഉറവിടങ്ങളില്ലെങ്കിൽ, ലോഡും വലുപ്പവും കണക്കാക്കാൻ എന്തെങ്കിലും അൽഗോരിതം അല്ലെങ്കിൽ ഫോർമുല ഉണ്ടോ?

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

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

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

സൂചികകളിലും അവർ അതുതന്നെ ചെയ്തു.

അതേ ചെക്ക് പോയിന്റ് ട്യൂണിംഗ് ഓട്ടോമേറ്റ് ചെയ്യാമെന്ന് എനിക്ക് ഊഹിക്കാം. എന്നെങ്കിലും ഇത് സംഭവിച്ചേക്കാം. എന്നാൽ അപ്പോൾ എനിക്ക് ചോദ്യം ശരിക്കും മനസ്സിലാകുന്നില്ല.

ചോദ്യം ഇതാണ്: അവിടെത്തന്നെ പോകുന്ന ഒരു ഡെവലപ്‌മെന്റ് വെക്‌റ്റർ ഉണ്ടോ, ഇവിടെ നിങ്ങളുടേതിന് സമാന്തരമായി പോകുന്നുണ്ടോ? ആ. അവർ ഇതുവരെ അതിനെക്കുറിച്ച് ചിന്തിച്ചിട്ടില്ലേ?

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

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

ഗുഡ് ആഫ്റ്റർനൂൺ നീണ്ട ഇടപാടുകളുടെ അപകടങ്ങളെക്കുറിച്ച് നിങ്ങൾ സംസാരിച്ചു. ഇല്ലാതാക്കിയാൽ ഓട്ടോവാക്വം ബ്ലോക്ക് ചെയ്യപ്പെടുമെന്ന് നിങ്ങൾ പറഞ്ഞു. ഇത് നമുക്ക് മറ്റെങ്ങനെ ദോഷം ചെയ്യും? കാരണം നമ്മൾ കൂടുതൽ സംസാരിക്കുന്നത് ഇടം ശൂന്യമാക്കുന്നതിനെക്കുറിച്ചും അത് ഉപയോഗിക്കാനാകുന്നതിനെക്കുറിച്ചും ആണ്. മറ്റെന്താണ് നമുക്ക് നഷ്ടപ്പെടാനുള്ളത്?

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

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

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

ഞങ്ങൾ ഇതിനകം ഒരു മാലിന്യം തിരഞ്ഞെടുക്കുമ്പോൾ, ഉദാഹരണത്തിന്, ഇല്ലാതാക്കിയ ഒരു ഫ്ലാഗ് ഉണ്ട്

പോസ്റ്റ്‌ഗ്രേസിൽ ഓട്ടോവാക്വം സ്വയമേവ ചെയ്യുന്നത് ഇതാണ്.

ഓ, അവൻ അത് ചെയ്യുന്നുണ്ടോ?

ഓട്ടോവാക്വം മാലിന്യ ശേഖരണമാണ്.

നന്ദി!

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

തീർച്ചയായും ഉണ്ട്.

ഉപയോഗിക്കാൻ പാടില്ലാത്ത ഒരു മേശ പൂട്ടിയിട്ടുണ്ടെങ്കിൽ നമുക്ക് സ്വയം പരിരക്ഷിക്കാൻ കഴിയുമോ?

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

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