Postgres: bloat, pg_repack, deferred constraints

ടേബിളുകളിലും സൂചികകളിലും ബ്ലോട്ടിൻ്റെ പ്രഭാവം വ്യാപകമായി അറിയപ്പെടുന്നു, ഇത് പോസ്റ്റ്‌ഗ്രേസിൽ മാത്രമല്ല. VACUUM FULL അല്ലെങ്കിൽ CLUSTER പോലുള്ള ബോക്‌സിന് പുറത്ത് ഇത് കൈകാര്യം ചെയ്യാനുള്ള വഴികളുണ്ട്, പക്ഷേ അവ പ്രവർത്തന സമയത്ത് പട്ടികകൾ ലോക്ക് ചെയ്യുന്നു, അതിനാൽ എല്ലായ്പ്പോഴും ഉപയോഗിക്കാൻ കഴിയില്ല.

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

എന്നതിനെ അടിസ്ഥാനമാക്കിയാണ് ഈ ലേഖനം എഴുതിയിരിക്കുന്നത് എന്റെ പ്രസംഗം PgConf.Russia 2020-ൽ.

എന്തുകൊണ്ടാണ് വീക്കം സംഭവിക്കുന്നത്?

Postgres ഒരു മൾട്ടി-പതിപ്പ് മോഡലിനെ അടിസ്ഥാനമാക്കിയുള്ളതാണ് (എം.വി.സി.സി). അതിന്റെ സാരാംശം, പട്ടികയിലെ ഓരോ വരിയിലും നിരവധി പതിപ്പുകൾ ഉണ്ടാകാം, അതേസമയം ഇടപാടുകൾ ഈ പതിപ്പുകളിൽ ഒന്നിൽ കൂടുതൽ കാണില്ല, എന്നാൽ ഒരേ ഒന്നായിരിക്കണമെന്നില്ല. ഇത് നിരവധി ഇടപാടുകൾ ഒരേസമയം പ്രവർത്തിക്കാനും പരസ്പരം ഫലത്തിൽ യാതൊരു സ്വാധീനവും ചെലുത്താതിരിക്കാനും അനുവദിക്കുന്നു.

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

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

തുടർന്ന് ഞങ്ങൾ എൻട്രികളിലൊന്ന് അപ്‌ഡേറ്റുചെയ്‌തു, അതുവഴി പഴയ പതിപ്പ് പ്രസക്തമല്ലെന്ന് അടയാളപ്പെടുത്തി.

ഘട്ടം ഘട്ടമായി, വരി പതിപ്പുകൾ അപ്‌ഡേറ്റ് ചെയ്യുകയും ഇല്ലാതാക്കുകയും ചെയ്തുകൊണ്ട്, ഏകദേശം പകുതി ഡാറ്റയും “മാലിന്യങ്ങൾ” ഉള്ള ഒരു പേജിൽ ഞങ്ങൾ അവസാനിച്ചു. ഈ ഡാറ്റ ഒരു ഇടപാടിനും ദൃശ്യമല്ല.

പോസ്റ്റ്ഗ്രേസിന് ഒരു സംവിധാനമുണ്ട് VACUUM, കാലഹരണപ്പെട്ട പതിപ്പുകൾ വൃത്തിയാക്കുകയും പുതിയ ഡാറ്റയ്ക്ക് ഇടം നൽകുകയും ചെയ്യുന്നു. എന്നാൽ ഇത് വേണ്ടത്ര ആക്രമണാത്മകമായി കോൺഫിഗർ ചെയ്തിട്ടില്ലെങ്കിലോ മറ്റ് ടേബിളുകളിൽ ജോലി ചെയ്യുന്ന തിരക്കിലാണെങ്കിലോ, "ഗാർബേജ് ഡാറ്റ" അവശേഷിക്കുന്നു, പുതിയ ഡാറ്റയ്ക്കായി ഞങ്ങൾ അധിക പേജുകൾ ഉപയോഗിക്കേണ്ടതുണ്ട്.

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

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

അത്തരം ശൂന്യമായ അല്ലെങ്കിൽ വളരെ വിരളമായ പേജുകളുടെ എണ്ണം വലുതാകുമ്പോൾ, അതിനെ ബ്ലോട്ട് എന്ന് വിളിക്കുന്നു, അത് പ്രകടനത്തെ ബാധിക്കാൻ തുടങ്ങുന്നു.

മുകളിൽ വിവരിച്ചതെല്ലാം പട്ടികകളിൽ ബ്ലാറ്റ് സംഭവിക്കുന്നതിന്റെ മെക്കാനിക്സാണ്. സൂചികകളിൽ ഇത് ഏതാണ്ട് സമാനമായ രീതിയിൽ സംഭവിക്കുന്നു.

എനിക്ക് വയറുവേദന ഉണ്ടോ?

നിങ്ങൾക്ക് വയറുവേദനയുണ്ടോ എന്ന് നിർണ്ണയിക്കാൻ നിരവധി മാർഗങ്ങളുണ്ട്. ആദ്യത്തേതിന്റെ ആശയം ആന്തരിക Postgres സ്ഥിതിവിവരക്കണക്കുകൾ ഉപയോഗിക്കുക എന്നതാണ്, അതിൽ പട്ടികകളിലെ വരികളുടെ എണ്ണം, "തത്സമയ" വരികളുടെ എണ്ണം മുതലായവയെക്കുറിച്ചുള്ള ഏകദേശ വിവരങ്ങൾ അടങ്ങിയിരിക്കുന്നു. നിങ്ങൾക്ക് ഇന്റർനെറ്റിൽ റെഡിമെയ്ഡ് സ്ക്രിപ്റ്റുകളുടെ നിരവധി വ്യതിയാനങ്ങൾ കണ്ടെത്താനാകും. ഞങ്ങൾ അടിസ്ഥാനമായി എടുത്തു സ്ക്രിപ്റ്റ് Toast, bloat btree സൂചികകൾക്കൊപ്പം ബ്ലോട്ട് ടേബിളുകൾ വിലയിരുത്താൻ കഴിയുന്ന PostgreSQL വിദഗ്ധരിൽ നിന്ന്. ഞങ്ങളുടെ അനുഭവത്തിൽ, അതിന്റെ പിശക് 10-20% ആണ്.

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

20% വരെ സ്വീകാര്യമായ ഒരു ചെറിയ ബ്ലോട്ട് മൂല്യം ഞങ്ങൾ പരിഗണിക്കുന്നു. ഫിൽഫാക്ടറിന്റെ അനലോഗ് ആയി ഇതിനെ കണക്കാക്കാം പട്ടികകൾ и സൂചികകൾ. 50%-ഉം അതിനുമുകളിലും, പ്രകടന പ്രശ്നങ്ങൾ ആരംഭിക്കാം.

വയറുവേദനയെ ചെറുക്കാനുള്ള വഴികൾ

പോസ്‌റ്റ്‌ഗ്രേസിന് ബോക്‌സ് ഔട്ട് ഓഫ് ബോക്‌സ് നേരിടാൻ നിരവധി മാർഗങ്ങളുണ്ട്, പക്ഷേ അവ എല്ലായ്‌പ്പോഴും എല്ലാവർക്കും അനുയോജ്യമല്ല.

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

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

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

നിങ്ങൾ AUTOVACUUM സജ്ജീകരിച്ച സാഹചര്യത്തിൽ എന്തുചെയ്യണം, പക്ഷേ ബ്ലോട്ട് വളരുന്നു.

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

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

ടീം റെൻഡെക്സ് മുമ്പത്തെ രണ്ടിന് സമാനമാണ്, എന്നാൽ ഒരു നിർദ്ദിഷ്ട സൂചിക അല്ലെങ്കിൽ പട്ടികയുടെ എല്ലാ സൂചികകളും പുനർനിർമ്മിക്കുന്നു. ലോക്കുകൾ അൽപ്പം ദുർബലമാണ്: ടേബിളിലെ ഷെയർലോക്ക് (മാറ്റങ്ങൾ തടയുന്നു, പക്ഷേ തിരഞ്ഞെടുക്കാൻ അനുവദിക്കുന്നു), പുനർനിർമ്മിക്കുന്ന സൂചികയിലെ AccessExclusiveLock (ഈ സൂചിക ഉപയോഗിച്ചുള്ള അന്വേഷണങ്ങളെ തടയുന്നു). എന്നിരുന്നാലും, പോസ്റ്റ്ഗ്രേസിന്റെ 12-ാം പതിപ്പിൽ ഒരു പരാമീറ്റർ പ്രത്യക്ഷപ്പെട്ടു ഒരേസമയം, ഒരേസമയം കൂട്ടിച്ചേർക്കൽ, മാറ്റം വരുത്തൽ, അല്ലെങ്കിൽ റെക്കോർഡുകൾ ഇല്ലാതാക്കൽ എന്നിവ തടയാതെ സൂചിക പുനർനിർമ്മിക്കാൻ നിങ്ങളെ അനുവദിക്കുന്നു.

Postgres-ന്റെ മുൻ പതിപ്പുകളിൽ, REINDEX ഒരേസമയം ഉപയോഗിക്കുന്നതുപോലുള്ള ഒരു ഫലം നിങ്ങൾക്ക് നേടാനാകും ഒരേസമയം സൂചിക സൃഷ്ടിക്കുക. കർശനമായ ലോക്കിംഗ് ഇല്ലാതെ ഒരു സൂചിക സൃഷ്ടിക്കാൻ ഇത് നിങ്ങളെ അനുവദിക്കുന്നു (ShareUpdateExclusiveLock, ഇത് സമാന്തര അന്വേഷണങ്ങളിൽ ഇടപെടുന്നില്ല), തുടർന്ന് പഴയ സൂചികയെ പുതിയൊരെണ്ണം ഉപയോഗിച്ച് മാറ്റി പഴയ സൂചിക ഇല്ലാതാക്കുക. നിങ്ങളുടെ ആപ്ലിക്കേഷനിൽ ഇടപെടാതെ തന്നെ സൂചിക ബ്ലാറ്റ് ഇല്ലാതാക്കാൻ ഇത് നിങ്ങളെ അനുവദിക്കുന്നു. സൂചികകൾ പുനർനിർമ്മിക്കുമ്പോൾ ഡിസ്ക് സബ്സിസ്റ്റത്തിൽ ഒരു അധിക ലോഡ് ഉണ്ടാകുമെന്ന് പരിഗണിക്കേണ്ടത് പ്രധാനമാണ്.

അതിനാൽ, സൂചികകൾക്ക് "ഈച്ചയിൽ" വീക്കം ഒഴിവാക്കാനുള്ള വഴികളുണ്ടെങ്കിൽ, പട്ടികകൾക്കായി ഒന്നുമില്ല. ഇവിടെയാണ് വിവിധ ബാഹ്യ വിപുലീകരണങ്ങൾ പ്രവർത്തിക്കുന്നത്: pg_repack (മുമ്പ് pg_reorg), pgcompact, pgcompactable മറ്റുള്ളവരും. ഈ ലേഖനത്തിൽ, ഞാൻ അവയെ താരതമ്യം ചെയ്യില്ല, കൂടാതെ pg_repack-നെക്കുറിച്ച് മാത്രമേ സംസാരിക്കൂ, അത് ചില പരിഷ്ക്കരണങ്ങൾക്ക് ശേഷം ഞങ്ങൾ സ്വയം ഉപയോഗിക്കുന്നു.

pg_repack എങ്ങനെ പ്രവർത്തിക്കുന്നു

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

അടുത്തതായി, pg_repack പഴയ ടേബിളിൽ നിന്ന് പുതിയ ടേബിളിലേക്ക് ഡാറ്റ കൈമാറുന്നു, അപ്രസക്തമായ എല്ലാ വരികളും സ്വയമേവ ഫിൽട്ടർ ചെയ്യുന്നു, തുടർന്ന് പുതിയ ടേബിളിനായി സൂചികകൾ സൃഷ്ടിക്കുന്നു. ഈ പ്രവർത്തനങ്ങളെല്ലാം നിർവ്വഹിക്കുമ്പോൾ, ലോഗ് ടേബിളിൽ മാറ്റങ്ങൾ അടിഞ്ഞു കൂടുന്നു.

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

സിദ്ധാന്തത്തിൽ എല്ലാം മികച്ചതായി തോന്നുന്നു, എന്നാൽ പ്രായോഗികമായി എന്താണ് സംഭവിക്കുന്നത്? ഞങ്ങൾ pg_repack ലോഡില്ലാതെയും ലോഡിന് താഴെയും പരീക്ഷിച്ചു, കൂടാതെ അകാല സ്റ്റോപ്പ് (മറ്റൊരു രീതിയിൽ പറഞ്ഞാൽ, Ctrl+C ഉപയോഗിച്ച്) അതിന്റെ പ്രവർത്തനം പരിശോധിച്ചു. എല്ലാ പരിശോധനകളും പോസിറ്റീവ് ആയിരുന്നു.

ഞങ്ങൾ ഭക്ഷണശാലയിലേക്ക് പോയി - തുടർന്ന് എല്ലാം ഞങ്ങൾ പ്രതീക്ഷിച്ചതുപോലെ നടന്നില്ല.

ആദ്യ പാൻകേക്ക് വിൽപ്പനയ്ക്ക്

ആദ്യ ക്ലസ്റ്ററിൽ ഒരു അദ്വിതീയ നിയന്ത്രണത്തിന്റെ ലംഘനത്തെക്കുറിച്ച് ഞങ്ങൾക്ക് ഒരു പിശക് ലഭിച്ചു:

$ ./pg_repack -t tablename -o id
INFO: repacking table "tablename"
ERROR: query failed: 
    ERROR: duplicate key value violates unique constraint "index_16508"
DETAIL:  Key (id, index)=(100500, 42) already exists.

ഈ പരിമിതിക്ക് സ്വയമേവ സൃഷ്ടിച്ച നാമം index_16508 ഉണ്ടായിരുന്നു - ഇത് pg_repack സൃഷ്ടിച്ചതാണ്. അതിന്റെ രചനയിൽ ഉൾപ്പെടുത്തിയിരിക്കുന്ന ആട്രിബ്യൂട്ടുകളെ അടിസ്ഥാനമാക്കി, അതിനോട് യോജിക്കുന്ന "ഞങ്ങളുടെ" നിയന്ത്രണം ഞങ്ങൾ നിർണ്ണയിച്ചു. ഇത് തികച്ചും സാധാരണമായ ഒരു പരിമിതിയല്ല, മാറ്റിവെച്ചതാണ് എന്നതാണ് പ്രശ്നം.മാറ്റിവച്ച നിയന്ത്രണം), അതായത്. അതിന്റെ സ്ഥിരീകരണം sql കമാൻഡിനേക്കാൾ പിന്നീട് നടക്കുന്നു, ഇത് അപ്രതീക്ഷിത പ്രത്യാഘാതങ്ങളിലേക്ക് നയിക്കുന്നു.

മാറ്റിവച്ച നിയന്ത്രണങ്ങൾ: അവ എന്തുകൊണ്ട് ആവശ്യമാണ്, അവ എങ്ങനെ പ്രവർത്തിക്കുന്നു

മാറ്റിവെച്ച നിയന്ത്രണങ്ങളെക്കുറിച്ചുള്ള ഒരു ചെറിയ സിദ്ധാന്തം.
നമുക്ക് ഒരു ലളിതമായ ഉദാഹരണം പരിഗണിക്കാം: രണ്ട് ആട്രിബ്യൂട്ടുകളുള്ള കാറുകളുടെ ഒരു ടേബിൾ-റഫറൻസ് ബുക്ക് ഉണ്ട് - ഡയറക്ടറിയിലെ കാറിന്റെ പേരും ക്രമവും.

create table cars
(
  name text constraint pk_cars primary key,
  ord integer not null constraint uk_cars unique
);

ആദ്യത്തെയും രണ്ടാമത്തെയും കാറുകൾ നമുക്ക് സ്വാപ്പ് ചെയ്യേണ്ടതുണ്ടെന്ന് പറയാം. ആദ്യ മൂല്യം രണ്ടാമത്തേതും രണ്ടാമത്തേത് ആദ്യത്തേതും അപ്ഡേറ്റ് ചെയ്യുക എന്നതാണ് നേരായ പരിഹാരം:

begin;
  update cars set ord = 2 where name = 'audi';
  update cars set ord = 1 where name = 'bmw';
commit;

എന്നാൽ ഞങ്ങൾ ഈ കോഡ് പ്രവർത്തിപ്പിക്കുമ്പോൾ, ഒരു നിയന്ത്രണ ലംഘനം ഞങ്ങൾ പ്രതീക്ഷിക്കുന്നു, കാരണം പട്ടികയിലെ മൂല്യങ്ങളുടെ ക്രമം അദ്വിതീയമാണ്:

[23305] ERROR: duplicate key value violates unique constraint “uk_cars”
Detail: Key (ord)=(2) already exists.

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

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

ഓപ്‌ഷൻ മൂന്ന്: നിർബ്ബന്ധം മാറ്റിവയ്ക്കുക, അങ്ങനെ അത് പ്രതിജ്ഞാബദ്ധമായ സമയത്ത് മാത്രം പരിശോധിക്കപ്പെടും:

create table cars
(
  name text constraint pk_cars primary key,
  ord integer not null constraint uk_cars unique deferrable initially deferred
);

ഞങ്ങളുടെ പ്രാരംഭ അഭ്യർത്ഥനയുടെ യുക്തി എല്ലാ മൂല്യങ്ങളും പ്രതിബദ്ധതയുള്ള സമയത്ത് അദ്വിതീയമാണെന്ന് ഉറപ്പാക്കുന്നതിനാൽ, അത് വിജയിക്കും.

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

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

അവലംബം: ബെഗ്രിഫ്സ്

CHECK ഉം NOT NULL ഉം എല്ലായ്പ്പോഴും വരി തലത്തിൽ പരിശോധിക്കും; മറ്റ് നിയന്ത്രണങ്ങൾക്കായി, പട്ടികയിൽ നിന്ന് കാണാൻ കഴിയുന്നതുപോലെ, വ്യത്യസ്ത ഓപ്ഷനുകൾ ഉണ്ട്. നിങ്ങൾക്ക് കൂടുതൽ വായിക്കാം ഇവിടെ.

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

pg_repack മെച്ചപ്പെടുത്തൽ

മാറ്റിവെച്ച നിയന്ത്രണങ്ങൾ എന്താണെന്ന് ഞങ്ങൾ കവർ ചെയ്തിട്ടുണ്ട്, എന്നാൽ അവ എങ്ങനെയാണ് ഞങ്ങളുടെ പ്രശ്നവുമായി ബന്ധപ്പെട്ടിരിക്കുന്നത്? നമുക്ക് നേരത്തെ ലഭിച്ച പിശക് ഓർക്കുക:

$ ./pg_repack -t tablename -o id
INFO: repacking table "tablename"
ERROR: query failed: 
    ERROR: duplicate key value violates unique constraint "index_16508"
DETAIL:  Key (id, index)=(100500, 42) already exists.

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

ഇത് മാറുന്നതുപോലെ, പ്രശ്നത്തിന്റെ റൂട്ട് pg_repack-ന്റെ മുൻ ഘട്ടത്തിലാണ്, അത് സൂചികകൾ മാത്രം സൃഷ്ടിക്കുന്നു, പക്ഷേ നിയന്ത്രണങ്ങളല്ല: പഴയ പട്ടികയ്ക്ക് ഒരു അദ്വിതീയ പരിമിതി ഉണ്ടായിരുന്നു, പുതിയത് പകരം ഒരു അദ്വിതീയ സൂചിക സൃഷ്ടിച്ചു.

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

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

അപ്പോൾ നമുക്ക് എന്തെല്ലാം ആശയങ്ങൾ ഉണ്ടായിരുന്നു?

മാറ്റിവെച്ചതിന് സമാനമായ ഒരു സൂചിക സൃഷ്ടിക്കുക

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

പരിശോധനകൾ എല്ലായ്‌പ്പോഴും മാറ്റിവയ്ക്കാത്ത മോഡിൽ ആണെന്ന് ഉറപ്പാക്കാൻ, ഒറിജിനൽ മാറ്റിവെച്ച നിയന്ത്രണത്തിന് സമാനമായ ഒരു പുതിയ സൂചിക ഞങ്ങൾ സൃഷ്ടിച്ചു:

CREATE UNIQUE INDEX CONCURRENTLY uk_tablename__immediate ON tablename (id, index);
-- run pg_repack
DROP INDEX CONCURRENTLY uk_tablename__immediate;

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

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

ആശയം ഫലിച്ചില്ല. ആ സമയത്ത്, ഞങ്ങൾ മറ്റ് രണ്ട് പരിഹാരങ്ങൾ കണ്ടു: മാറ്റിവച്ച നിയന്ത്രണങ്ങൾ ഒഴിവാക്കാൻ ഞങ്ങളുടെ ആപ്ലിക്കേഷൻ കോഡ് മാറ്റിയെഴുതുക, അല്ലെങ്കിൽ അവയുമായി പ്രവർത്തിക്കാൻ pg_repack "പഠിപ്പിക്കുക". ഞങ്ങൾ രണ്ടാമത്തേത് തിരഞ്ഞെടുത്തു.

പുതിയ പട്ടികയിലെ സൂചികകൾ യഥാർത്ഥ പട്ടികയിൽ നിന്ന് മാറ്റിവെച്ച നിയന്ത്രണങ്ങൾ ഉപയോഗിച്ച് മാറ്റിസ്ഥാപിക്കുക

പുനരവലോകനത്തിൻ്റെ ഉദ്ദേശ്യം വ്യക്തമാണ് - ഒറിജിനൽ ടേബിളിന് മാറ്റിവെച്ച ഒരു നിയന്ത്രണമുണ്ടെങ്കിൽ, പുതിയതിന് നിങ്ങൾ അത്തരമൊരു നിയന്ത്രണം സൃഷ്ടിക്കേണ്ടതുണ്ട്, ഒരു സൂചികയല്ല.

ഞങ്ങളുടെ മാറ്റങ്ങൾ പരിശോധിക്കാൻ, ഞങ്ങൾ ഒരു ലളിതമായ പരീക്ഷ എഴുതി:

• മാറ്റിവച്ച നിയന്ത്രണവും ഒരു റെക്കോർഡും ഉള്ള പട്ടിക;
• നിലവിലുള്ള ഒരു റെക്കോർഡുമായി വൈരുദ്ധ്യമുള്ള ഒരു ലൂപ്പിൽ ഡാറ്റ ചേർക്കുക;
• ഒരു അപ്ഡേറ്റ് ചെയ്യുക - ഡാറ്റ മേലിൽ വൈരുദ്ധ്യമല്ല;
• മാറ്റങ്ങൾ വരുത്തുക.

create table test_table
(
  id serial,
  val int,
  constraint uk_test_table__val unique (val) deferrable initially deferred 
);

INSERT INTO test_table (val) VALUES (0);
FOR i IN 1..10000 LOOP
  BEGIN
    INSERT INTO test_table VALUES (0) RETURNING id INTO v_id;
    UPDATE test_table set val = i where id = v_id;
    COMMIT;
  END;
END LOOP;

pg_repack-ൻ്റെ യഥാർത്ഥ പതിപ്പ് എല്ലായ്‌പ്പോഴും ആദ്യ ഇൻസേർട്ടിൽ ക്രാഷ് ചെയ്‌തു, പരിഷ്‌ക്കരിച്ച പതിപ്പ് പിശകുകളില്ലാതെ പ്രവർത്തിക്കുന്നു. കൊള്ളാം.

ഞങ്ങൾ പ്രൊഡക്ഷനിലേക്ക് പോയി, ലോഗ് ടേബിളിൽ നിന്ന് പുതിയതിലേക്ക് ഡാറ്റ പകർത്തുന്നതിൻ്റെ അതേ ഘട്ടത്തിൽ വീണ്ടും ഒരു പിശക് ലഭിക്കും:

$ ./pg_repack -t tablename -o id
INFO: repacking table "tablename"
ERROR: query failed: 
    ERROR: duplicate key value violates unique constraint "index_16508"
DETAIL:  Key (id, index)=(100500, 42) already exists.

ക്ലാസിക് സാഹചര്യം: എല്ലാം പരീക്ഷണ പരിതസ്ഥിതികളിൽ പ്രവർത്തിക്കുന്നു, പക്ഷേ ഉൽപ്പാദനത്തിലല്ലേ?!

APPLY_COUNT, രണ്ട് ബാച്ചുകളുടെ ജംഗ്ഷൻ

ഞങ്ങൾ കോഡ് അക്ഷരാർത്ഥത്തിൽ വരിയായി വിശകലനം ചെയ്യാൻ തുടങ്ങി, ഒരു പ്രധാന കാര്യം കണ്ടെത്തി: ലോഗ് ടേബിളിൽ നിന്ന് ഡാറ്റ ബാച്ചുകളായി പുതിയതിലേക്ക് മാറ്റുന്നു, APPLY_COUNT സ്ഥിരാങ്കം ബാച്ചിന്റെ വലുപ്പം സൂചിപ്പിച്ചു:

for (;;)
{
num = apply_log(connection, table, APPLY_COUNT);

if (num > MIN_TUPLES_BEFORE_SWITCH)
     continue;  /* there might be still some tuples, repeat. */
...
}

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

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

FOR i IN 1..10000 LOOP
  BEGIN
    INSERT INTO test_table VALUES (1) RETURNING id INTO v_id;
    UPDATE test_table set val = i where id = v_id;
    UPDATE test_table set val = i where id = v_id; -- one more update
    COMMIT;
  END;
END LOOP;

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

ബാച്ചിംഗിൽ നിന്നുള്ള വിസമ്മതം

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

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

അതിനാൽ, ആദ്യ ഓപ്ഷൻ ആരംഭിക്കാൻ ഞങ്ങൾ തീരുമാനിച്ചു, കാരണം ഇത് ലളിതമാണ്. ആദ്യം, ഒരു നീണ്ട ഇടപാട് ഒരു യഥാർത്ഥ പ്രശ്നമാകുമോ എന്ന് മനസ്സിലാക്കേണ്ടത് ആവശ്യമാണ്. പഴയ പട്ടികയിൽ നിന്ന് പുതിയതിലേക്കുള്ള ഡാറ്റയുടെ പ്രധാന കൈമാറ്റം ഒരു നീണ്ട ഇടപാടിൽ സംഭവിക്കുന്നതിനാൽ, ചോദ്യം "ഈ ഇടപാട് എത്രത്തോളം വർദ്ധിപ്പിക്കും?" എന്നതിലേക്ക് രൂപാന്തരപ്പെട്ടു. ആദ്യ ഇടപാടിന്റെ ദൈർഘ്യം പ്രധാനമായും പട്ടികയുടെ വലുപ്പത്തെ ആശ്രയിച്ചിരിക്കുന്നു. ഡാറ്റാ കൈമാറ്റ സമയത്ത് പട്ടികയിൽ എത്ര മാറ്റങ്ങൾ ശേഖരിക്കുന്നു എന്നതിനെ ആശ്രയിച്ചിരിക്കും പുതിയ ഒന്നിന്റെ ദൈർഘ്യം, അതായത്. ലോഡിന്റെ തീവ്രതയിൽ. കുറഞ്ഞ സേവന ലോഡിന്റെ സമയത്താണ് pg_repack റൺ സംഭവിച്ചത്, കൂടാതെ പട്ടികയുടെ യഥാർത്ഥ വലുപ്പവുമായി താരതമ്യപ്പെടുത്തുമ്പോൾ മാറ്റങ്ങളുടെ അളവ് ആനുപാതികമായി ചെറുതായിരുന്നു. ഒരു പുതിയ ഇടപാടിന്റെ സമയം അവഗണിക്കാമെന്ന് ഞങ്ങൾ തീരുമാനിച്ചു (താരതമ്യത്തിന്, ഇത് ശരാശരി 1 മണിക്കൂർ 2-3 മിനിറ്റാണ്).

പരീക്ഷണങ്ങൾ പോസിറ്റീവ് ആയിരുന്നു. നിർമ്മാണത്തിലും സമാരംഭിക്കുക. വ്യക്തതയ്ക്കായി, പ്രവർത്തിപ്പിച്ചതിന് ശേഷം ഡാറ്റാബേസുകളിലൊന്നിന്റെ വലുപ്പമുള്ള ഒരു ചിത്രം ഇതാ:

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

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

കണ്ടെത്തലുകൾ

ഞങ്ങളുടെ സ്വന്തം അനുഭവത്തെ അടിസ്ഥാനമാക്കി ഞങ്ങൾക്ക് എന്താണ് ശുപാർശ ചെയ്യാൻ കഴിയുക:

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

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