પોસ્ટગ્રેએસક્યુએલ એન્ટિપેટર્ન: "મૃત" ની લડાઈ

PostgreSQL ની આંતરિક પદ્ધતિઓ જે રીતે કાર્ય કરે છે તેના કારણે તે કેટલીક પરિસ્થિતિઓમાં ખૂબ જ ઝડપી બને છે અને અન્યમાં એટલું ઝડપી નથી. આજે, આપણે DBMS કેવી રીતે કાર્ય કરે છે અને ડેવલપર તેની સાથે શું કરે છે તે વચ્ચેના સંઘર્ષનું એક ઉત્તમ ઉદાહરણ જોઈશું: અપડેટ વિરુદ્ધ MVCC સિદ્ધાંતો.

સંક્ષિપ્ત પ્લોટ ઉત્તમ લેખ:

જ્યારે કોઈ પંક્તિને UPDATE આદેશ દ્વારા સુધારવામાં આવે છે, ત્યારે વાસ્તવમાં બે કામગીરી કરવામાં આવે છે: એક DELETE અને એક INSERT. લાઇનનું વર્તમાન સંસ્કરણ xmax એ UPDATE કરેલા વ્યવહારના નંબર પર સેટ થયેલ છે. પછી તે બનાવવામાં આવે છે નવી આવૃત્તિ એ જ લાઇન; તેનું xmin મૂલ્ય પાછલા સંસ્કરણના xmax મૂલ્ય સાથે મેળ ખાય છે.

આ વ્યવહાર પૂર્ણ થયાના થોડા સમય પછી, જૂનું કે નવું સંસ્કરણ, તેના પર આધાર રાખીને COMMIT/ROOLBACK, ઓળખાશે ડેડ ટુપલ્સ પસાર થતી વખતે VACUUM ટેબલ મુજબ અને સાફ.

પરંતુ આ તરત જ થશે નહીં, પરંતુ "મૃત" સાથેની સમસ્યાઓ ખૂબ જ ઝડપથી થઈ શકે છે - વારંવાર અથવા રેકોર્ડનું મોટા પાયે અપડેટિંગ એક મોટા ટેબલ પર, અને થોડી વાર પછી એવી પરિસ્થિતિનો સામનો કરવો પડે છે કે VACUUM મદદ કરી શકશે નહીં.

#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;

ડેટાબેઝમાં આ એન્ટ્રીના કેટલા વર્ઝન છે? હા, ચાર! તેમાંથી એક વર્તમાન છે, અને ત્રણને [ઓટો]વેક્યુમ દ્વારા સાફ કરવાની જરૂર પડશે.

એવું ના કરો! તેનો ઉપયોગ કરો! એક વિનંતીમાં બધા ક્ષેત્રોને અપડેટ કરી રહ્યા છીએ — લગભગ હંમેશા પદ્ધતિનો તર્ક આ રીતે બદલી શકાય છે:

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

#2: ઉપયોગ કરો "IS DISTINCT FROM, લ્યુક!"

તો, તમે હજુ પણ ઇચ્છતા હતા કે કોષ્ટકમાં ઘણા બધા રેકોર્ડ અપડેટ કરો (ઉદાહરણ તરીકે, સ્ક્રિપ્ટ અથવા કન્વર્ટરનો ઉપયોગ કરતી વખતે). અને આના જેવું કંઈક સ્ક્રિપ્ટમાં નાખવામાં આવે છે:

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;

ભલે આ પ્રક્રિયાઓ સ્વતંત્ર કાર્યો કરે, પરંતુ તે જ ID ની અંદર, બીજા ક્લાયંટને આ વિનંતી પર "લોક" કરવામાં આવશે જ્યાં સુધી પહેલો વ્યવહાર પૂર્ણ ન થાય.

ઉકેલ #1: કાર્ય પાછલા કાર્ય સુધી ઘટાડી દેવામાં આવ્યું છે

ચાલો તેને ફરીથી ઉમેરીએ. IS DISTINCT FROM:

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

આ ફોર્મમાં, બીજી ક્વેરી ડેટાબેઝમાં કંઈપણ બદલશે નહીં; બધું પહેલેથી જ "જેમ હોવું જોઈએ તેમ" છે - તેથી કોઈ બ્લોકિંગ થશે નહીં. રેકોર્ડ "મળ્યો ન હતો" તે હકીકત પછી એપ્લિકેશન અલ્ગોરિધમમાં નિયંત્રિત થાય છે.

ઉકેલ #2: સલાહકારી તાળાઓ

આ એક મોટો વિષય છે જેના પર એક અલગ લેખ લખવો પડશે, જ્યાં તમે તેના વિશે વાંચી શકો છો. એપ્લિકેશનની પદ્ધતિઓ અને સલાહકારી અવરોધના મુશ્કેલીઓ.

ઉકેલ #3: મૂર્ખ કોલ્સ

પણ તમારી સાથે આવું જ થવું જોઈએ. સમાન રેકોર્ડ સાથે એક સાથે કાર્યઅથવા કદાચ તમે ક્લાયન્ટ-સાઇડ બિઝનેસ લોજિક કોલ અલ્ગોરિધમ્સમાં ભૂલ કરી હશે, ઉદાહરણ તરીકે? પણ જો તમે તેના વિશે વિચારો તો...

સોર્સ: www.habr.com