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

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

માંથી સંક્ષિપ્ત વાર્તા મહાન લેખ:

જ્યારે પંક્તિ અપડેટ આદેશ દ્વારા સંશોધિત કરવામાં આવે છે, ત્યારે ખરેખર બે કામગીરી કરવામાં આવે છે: કાઢી નાખો અને દાખલ કરો. IN શબ્દમાળાનું વર્તમાન સંસ્કરણ 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;

... અને પછી 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;

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

ઉકેલ નંબર 1: કાર્ય પાછલા એકમાં ઘટાડવામાં આવ્યું છે

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

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

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

ઉકેલ નંબર 2: સલાહકારી તાળાઓ

એક અલગ લેખ માટે એક મોટો વિષય, જેના વિશે તમે વાંચી શકો છો એપ્લિકેશનની પદ્ધતિઓ અને ભલામણ અવરોધિત કરવાની "રેક"..

ઉકેલ નંબર 3: મૂર્ખ કોલ્સ

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

સોર્સ: www.habr.com