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

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

എന്നതിൽ നിന്നുള്ള ഒരു ചെറിയ പ്ലോട്ട് മികച്ച ലേഖനം:

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

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

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

#1: എനിക്ക് അത് നീക്കാൻ ഇഷ്ടമാണ്

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

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

പിന്നെ, എക്സിക്യൂഷൻ പുരോഗമിക്കുമ്പോൾ, Y ഫീൽഡും അപ്ഡേറ്റ് ചെയ്യേണ്ടതുണ്ടെന്ന് അത് കണ്ടെത്തുന്നു:

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

... പിന്നെ ഇസഡും ഉണ്ട് - ചെറിയ കാര്യങ്ങളിൽ എന്തിനാണ് വിഷമിക്കുന്നത്?

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

ഈ എൻട്രിയുടെ എത്ര പതിപ്പുകൾ ഇപ്പോൾ ഡാറ്റാബേസിൽ ഉണ്ട്? അതെ, നാല്! അവയിലൊന്ന് നിലവിലുള്ളതാണ്, മൂന്നെണ്ണം [ഓട്ടോ] വാക്വം ഉപയോഗിച്ച് വൃത്തിയാക്കേണ്ടതുണ്ട്.

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

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