PostgreSQL ആന്റിപാറ്റേണുകൾ: "മരിച്ചവരുടെ" കൂട്ടത്തിനെതിരായ പോരാട്ടം

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

എന്നതിൽ നിന്നുള്ള ഹ്രസ്വ കഥ വലിയ ലേഖനം:

അപ്‌ഡേറ്റ് കമാൻഡ് ഉപയോഗിച്ച് ഒരു വരി പരിഷ്‌ക്കരിക്കുമ്പോൾ, യഥാർത്ഥത്തിൽ രണ്ട് പ്രവർത്തനങ്ങൾ നടത്തുന്നു: ഇല്ലാതാക്കുക, ചേർക്കുക. IN സ്ട്രിംഗിന്റെ നിലവിലെ പതിപ്പ് xmax എന്നത് അപ്‌ഡേറ്റ് നടത്തിയ ഇടപാടിന്റെ എണ്ണത്തിന് തുല്യമാണ്. അപ്പോൾ അത് സൃഷ്ടിക്കപ്പെടുന്നു ഒരു പുതിയ പതിപ്പ് ഒരേ വരി; അതിന്റെ xmin മൂല്യം മുമ്പത്തെ പതിപ്പിന്റെ xmax മൂല്യവുമായി പൊരുത്തപ്പെടുന്നു.

ഈ ഇടപാട് പൂർത്തിയായി കുറച്ച് സമയത്തിന് ശേഷം, പഴയതോ പുതിയതോ ആയ പതിപ്പിനെ ആശ്രയിച്ചിരിക്കുന്നു COMMIT/ROOLBACK, അംഗീകരിക്കപ്പെടും "ചത്ത" (ചത്ത ട്യൂപ്പിൾസ്) കടന്നുപോകുമ്പോൾ VACUUM മേശ അനുസരിച്ച് വൃത്തിയാക്കി.

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

#1: ഞാൻ ഇത് നീക്കാൻ ഇഷ്ടപ്പെടുന്നു

നിങ്ങളുടെ രീതി ബിസിനസ്സ് ലോജിക്കിൽ പ്രവർത്തിക്കുന്നുണ്ടെന്ന് പറയട്ടെ, ചില റെക്കോർഡുകളിൽ X ഫീൽഡ് അപ്ഡേറ്റ് ചെയ്യേണ്ടത് അത്യാവശ്യമാണെന്ന് പെട്ടെന്ന് അത് മനസ്സിലാക്കുന്നു:

UPDATE tbl SET X = <newX> WHERE pk = $1;

തുടർന്ന്, നിർവ്വഹണം പുരോഗമിക്കുമ്പോൾ, Y ഫീൽഡും അപ്‌ഡേറ്റ് ചെയ്യേണ്ടതായി മാറുന്നു:

UPDATE tbl SET Y = <newY> WHERE pk = $1;

... പിന്നെ Z - എന്തിനാണ് നിസ്സാരകാര്യങ്ങളിൽ സമയം കളയുന്നത്?

UPDATE tbl SET Z = <newZ> WHERE pk = $1;

ഈ റെക്കോർഡിന്റെ എത്ര പതിപ്പുകൾ നമുക്ക് ഇപ്പോൾ ഡാറ്റാബേസിൽ ഉണ്ട്? അതെ, 4 കഷണങ്ങൾ! ഇവയിൽ ഒരെണ്ണം പ്രസക്തമാണ്, കൂടാതെ 3 എണ്ണം നിങ്ങൾക്ക് ശേഷം [ഓട്ടോ]വാക്വം ഉപയോഗിച്ച് വൃത്തിയാക്കേണ്ടതുണ്ട്.

ഇത് ഈ രീതിയിൽ ചെയ്യരുത്! ഉപയോഗിക്കുക ഒരു അഭ്യർത്ഥനയിൽ എല്ലാ ഫീൽഡുകളും അപ്ഡേറ്റ് ചെയ്യുന്നു - മിക്കവാറും എല്ലായ്‌പ്പോഴും രീതിയുടെ യുക്തി ഇതുപോലെ മാറ്റാവുന്നതാണ്:

UPDATE tbl SET X = <newX>, Y = <newY>, Z = <newZ> WHERE pk = $1;

#2: ഉപയോഗം വ്യത്യസ്തമാണ്, ലൂക്കാ!

അതിനാൽ, നിങ്ങൾ ഇപ്പോഴും ആഗ്രഹിച്ചു ഒരു പട്ടികയിൽ നിരവധി റെക്കോർഡുകൾ അപ്ഡേറ്റ് ചെയ്യുക (ഉദാഹരണത്തിന്, ഒരു സ്ക്രിപ്റ്റ് അല്ലെങ്കിൽ കൺവെർട്ടർ ഉപയോഗിക്കുമ്പോൾ). ഇതുപോലുള്ള ഒന്ന് സ്ക്രിപ്റ്റിലേക്ക് പറക്കുന്നു:

UPDATE tbl SET X = <newX> WHERE pk BETWEEN $1 AND $2;

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

UPDATE tbl SET X = <newX> WHERE pk BETWEEN $1 AND $2 AND X IS DISTINCT FROM <newX>;

അത്തരമൊരു അത്ഭുതകരമായ ഓപ്പറേറ്ററുടെ അസ്തിത്വത്തെക്കുറിച്ച് പലർക്കും അറിയില്ല, അതിനാൽ ഇതാ ഒരു ചീറ്റ് ഷീറ്റ് IS DISTINCT FROM സഹായിക്കാൻ മറ്റ് ലോജിക്കൽ ഓപ്പറേറ്റർമാരും:

... കൂടാതെ സമുച്ചയത്തിലെ പ്രവർത്തനങ്ങളെക്കുറിച്ച് കുറച്ച് ROW()-ഭാവങ്ങൾ:

#3: തടയുന്നതിലൂടെ ഞാൻ എന്റെ പ്രണയിനിയെ തിരിച്ചറിയുന്നു

ലോഞ്ച് ചെയ്യുന്നു സമാനമായ രണ്ട് സമാന്തര പ്രക്രിയകൾ, ഓരോന്നും എൻട്രി "പുരോഗതിയിലാണെന്ന്" അടയാളപ്പെടുത്താൻ ശ്രമിക്കുന്നു:

UPDATE tbl SET processing = TRUE WHERE pk = $1;

ഈ പ്രക്രിയകൾ യഥാർത്ഥത്തിൽ പരസ്പരം സ്വതന്ത്രമായി കാര്യങ്ങൾ ചെയ്യുന്നുണ്ടെങ്കിലും, ഒരേ ഐഡിയിൽ തന്നെ, ആദ്യ ഇടപാട് പൂർത്തിയാകുന്നതുവരെ രണ്ടാമത്തെ ക്ലയന്റ് ഈ അഭ്യർത്ഥനയിൽ "ലോക്ക്" ചെയ്യപ്പെടും.

പരിഹാരം # 1: ചുമതല മുമ്പത്തേതിലേക്ക് ചുരുക്കിയിരിക്കുന്നു

നമുക്ക് അത് വീണ്ടും ചേർക്കാം IS DISTINCT FROM:

UPDATE tbl SET processing = TRUE WHERE pk = $1 AND processing IS DISTINCT FROM TRUE;

ഈ ഫോമിൽ, രണ്ടാമത്തെ അഭ്യർത്ഥന ഡാറ്റാബേസിൽ ഒന്നും മാറ്റില്ല, എല്ലാം ഇതിനകം തന്നെ ആയിരിക്കണം - അതിനാൽ, തടയൽ സംഭവിക്കില്ല. അടുത്തതായി, പ്രയോഗിച്ച അൽഗോരിതത്തിൽ റെക്കോർഡ് "കണ്ടെത്തുന്നില്ല" എന്ന വസ്തുത ഞങ്ങൾ പ്രോസസ്സ് ചെയ്യുന്നു.

പരിഹാരം # 2: ഉപദേശക ലോക്കുകൾ

ഒരു പ്രത്യേക ലേഖനത്തിനായുള്ള ഒരു വലിയ വിഷയം, അതിൽ നിങ്ങൾക്ക് വായിക്കാൻ കഴിയും പ്രയോഗത്തിന്റെ രീതികളും ശുപാർശ തടയുന്നതിനുള്ള "റേക്ക്".

പരിഹാരം # 3: മണ്ടൻ കോളുകൾ

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

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