પોસ્ટગ્રેસ: બ્લોટ, pg_repack અને વિલંબિત અવરોધો

કોષ્ટકો અને અનુક્રમણિકાઓ પર બ્લોટની અસર વ્યાપકપણે જાણીતી છે અને તે માત્ર પોસ્ટગ્રેસમાં જ નથી. VACUUM FULL અથવા CLUSTER જેવા બોક્સની બહાર તેની સાથે વ્યવહાર કરવાની રીતો છે, પરંતુ તેઓ ઓપરેશન દરમિયાન કોષ્ટકોને લોક કરે છે અને તેથી હંમેશા તેનો ઉપયોગ કરી શકાતો નથી.

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

આ લેખ તેના આધારે લખવામાં આવ્યો છે મારું ભાષણ PgConf.Russia 2020 પર.

બ્લોટ શા માટે થાય છે?

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

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

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

અમે પછી એક એન્ટ્રી અપડેટ કરી, ત્યાંથી જૂના સંસ્કરણને હવે સંબંધિત નથી તરીકે ચિહ્નિત કર્યું.

સ્ટેપ બાય સ્ટેપ, પંક્તિના સંસ્કરણોને અપડેટ કરીને અને કાઢી નાખીને, અમે એક પૃષ્ઠ સાથે સમાપ્ત કર્યું જેમાં લગભગ અડધો ડેટા "કચરો" છે. આ ડેટા કોઈપણ વ્યવહાર માટે દેખાતો નથી.

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

તેથી અમારા ઉદાહરણમાં, અમુક સમયે કોષ્ટકમાં ચાર પૃષ્ઠો હશે, પરંતુ તેમાંથી માત્ર અડધા જીવંત ડેટા હશે. પરિણામે, કોષ્ટકને ઍક્સેસ કરતી વખતે, અમે જરૂરી કરતાં વધુ ડેટા વાંચીશું.

જો VACUUM હવે તમામ અપ્રસ્તુત પંક્તિ સંસ્કરણોને કાઢી નાખે તો પણ, પરિસ્થિતિ નાટકીય રીતે સુધરશે નહીં. નવી પંક્તિઓ માટે અમારી પાસે પૃષ્ઠોમાં અથવા તો સંપૂર્ણ પૃષ્ઠોમાં ખાલી જગ્યા હશે, પરંતુ અમે હજી પણ જરૂરી કરતાં વધુ ડેટા વાંચીશું.
માર્ગ દ્વારા, જો સંપૂર્ણ ખાલી પૃષ્ઠ (અમારા ઉદાહરણમાં બીજું) ફાઇલના અંતે હોય, તો VACUUM તેને ટ્રિમ કરવામાં સક્ષમ હશે. પરંતુ હવે તે મધ્યમાં છે, તેથી તેની સાથે કંઈ કરી શકાતું નથી.

જ્યારે આવા ખાલી અથવા અત્યંત છૂટાછવાયા પૃષ્ઠોની સંખ્યા મોટી થઈ જાય છે, જેને બ્લોટ કહેવામાં આવે છે, તે પ્રભાવને અસર કરવાનું શરૂ કરે છે.

ઉપર વર્ણવેલ દરેક વસ્તુ કોષ્ટકોમાં બ્લોટની ઘટનાના મિકેનિક્સ છે. અનુક્રમણિકાઓમાં આ ઘણી જ રીતે થાય છે.

શું મને પેટનું ફૂલવું છે?

તમને બ્લોટ છે કે કેમ તે નિર્ધારિત કરવાની ઘણી રીતો છે. પ્રથમનો વિચાર આંતરિક પોસ્ટગ્રેસ આંકડાઓનો ઉપયોગ કરવાનો છે, જેમાં કોષ્ટકોમાં પંક્તિઓની સંખ્યા, "જીવંત" પંક્તિઓની સંખ્યા, વગેરે વિશેની અંદાજિત માહિતી શામેલ છે. તમે ઇન્ટરનેટ પર તૈયાર સ્ક્રિપ્ટની ઘણી વિવિધતાઓ શોધી શકો છો. અમે એક આધાર તરીકે લીધો સ્ક્રિપ્ટ પોસ્ટગ્રેએસક્યુએલ નિષ્ણાતો પાસેથી, જે ટોસ્ટ અને બ્લોટ બીટ્રી ઇન્ડેક્સની સાથે બ્લોટ ટેબલનું મૂલ્યાંકન કરી શકે છે. અમારા અનુભવમાં, તેની ભૂલ 10-20% છે.

બીજી રીત એક્સ્ટેંશનનો ઉપયોગ કરવાનો છે pgstattuple, જે તમને પૃષ્ઠોની અંદર જોવાની અને અંદાજિત અને ચોક્કસ બ્લોટ મૂલ્ય બંને મેળવવાની મંજૂરી આપે છે. પરંતુ બીજા કિસ્સામાં, તમારે આખું ટેબલ સ્કેન કરવું પડશે.

અમે નાના બ્લોટ મૂલ્યને 20% સુધી સ્વીકાર્ય ગણીએ છીએ. તે માટે ફિલફેક્ટરના એનાલોગ તરીકે ગણી શકાય કોષ્ટકો и સૂચકાંકો. 50% અને તેથી વધુ પર, પ્રદર્શન સમસ્યાઓ શરૂ થઈ શકે છે.

બ્લોટ સામે લડવાની રીતો

પોસ્ટગ્રેસ પાસે બોક્સની બહાર બ્લોટ સાથે વ્યવહાર કરવાની ઘણી રીતો છે, પરંતુ તે હંમેશા દરેક માટે યોગ્ય નથી.

ઑટોવેક્યુમને ગોઠવો જેથી બ્લોટ ન થાય. અથવા વધુ સ્પષ્ટ રીતે, તેને તમારા માટે સ્વીકાર્ય સ્તર પર રાખવા માટે. આ "કેપ્ટનની" સલાહ જેવું લાગે છે, પરંતુ વાસ્તવમાં આ પ્રાપ્ત કરવું હંમેશા સરળ હોતું નથી. ઉદાહરણ તરીકે, તમારી પાસે ડેટા સ્કીમમાં નિયમિત ફેરફારો સાથે સક્રિય વિકાસ છે અથવા કોઈ પ્રકારનું ડેટા સ્થળાંતર થઈ રહ્યું છે. પરિણામે, તમારી લોડ પ્રોફાઇલ વારંવાર બદલાઈ શકે છે અને સામાન્ય રીતે ટેબલથી ટેબલમાં બદલાતી રહેશે. આનો અર્થ એ છે કે તમારે સતત થોડું આગળ કામ કરવાની જરૂર છે અને દરેક કોષ્ટકની બદલાતી પ્રોફાઇલમાં AUTOVACUUM ને સમાયોજિત કરવાની જરૂર છે. પરંતુ દેખીતી રીતે આ કરવું સરળ નથી.

AUTOVACUUM કોષ્ટકો સાથે ચાલુ રાખી શકતું નથી તેનું બીજું સામાન્ય કારણ એ છે કે ત્યાં લાંબા સમયથી ચાલતા વ્યવહારો છે જે તેને તે વ્યવહારો માટે ઉપલબ્ધ ડેટાને સાફ કરવાથી અટકાવે છે. અહીંની ભલામણ પણ સ્પષ્ટ છે - "ઝૂલતા" વ્યવહારોથી છુટકારો મેળવો અને સક્રિય વ્યવહારોનો સમય ઓછો કરો. પરંતુ જો તમારી એપ્લિકેશન પરનો ભાર OLAP અને OLTP નો વર્ણસંકર છે, તો પછી તમારી પાસે એકસાથે ઘણા વારંવાર અપડેટ્સ અને ટૂંકા પ્રશ્નો, તેમજ લાંબા ગાળાની કામગીરી - ઉદાહરણ તરીકે, રિપોર્ટ બનાવવી. આવી સ્થિતિમાં, લોડને વિવિધ પાયા પર ફેલાવવા વિશે વિચારવું યોગ્ય છે, જે તેમાંથી દરેકને વધુ ફાઇન-ટ્યુનિંગ માટે પરવાનગી આપશે.

બીજું ઉદાહરણ - જો પ્રોફાઇલ સજાતીય છે, પરંતુ ડેટાબેઝ ખૂબ ઊંચા ભાર હેઠળ છે, તો પછી સૌથી આક્રમક ઓટોવેક્યુમ પણ સામનો કરી શકશે નહીં, અને બ્લોટ થશે. સ્કેલિંગ (ઊભી અથવા આડી) એકમાત્ર ઉકેલ છે.

એવી પરિસ્થિતિમાં શું કરવું જ્યાં તમે AUTOVACUUM સેટ કર્યું છે, પરંતુ બ્લોટ વધતું જ રહે છે.

ટીમ વેક્યુમ ફુલ કોષ્ટકો અને અનુક્રમણિકાઓના સમાવિષ્ટોનું પુનઃનિર્માણ કરે છે અને તેમાં ફક્ત સંબંધિત ડેટા છોડે છે. બ્લોટને દૂર કરવા માટે, તે સંપૂર્ણ રીતે કાર્ય કરે છે, પરંતુ તેના અમલ દરમિયાન ટેબલ પર એક વિશિષ્ટ લોક કેપ્ચર થાય છે (AccessExclusiveLock), જે આ ટેબલ પર ક્વેરી ચલાવવાની મંજૂરી આપશે નહીં, પસંદ પણ કરે છે. જો તમે તમારી સેવા અથવા તેનો અમુક ભાગ અમુક સમય માટે (ડેટાબેઝ અને તમારા હાર્ડવેરના કદના આધારે દસ મિનિટથી લઈને કેટલાક કલાકો સુધી) બંધ કરી શકો છો, તો આ વિકલ્પ શ્રેષ્ઠ છે. કમનસીબે, સુનિશ્ચિત જાળવણી દરમિયાન અમારી પાસે VACUUM FULL ચલાવવાનો સમય નથી, તેથી આ પદ્ધતિ અમારા માટે યોગ્ય નથી.

ટીમ ક્લસ્ટર કોષ્ટકોના સમાવિષ્ટોને VACUUM FULL ની જેમ પુનઃનિર્માણ કરે છે, પરંતુ તમને એક અનુક્રમણિકા નિર્દિષ્ટ કરવાની મંજૂરી આપે છે કે જેના અનુસાર ડિસ્ક પર ડેટા ભૌતિક રીતે ઓર્ડર કરવામાં આવશે (પરંતુ ભવિષ્યમાં નવી પંક્તિઓ માટે ઓર્ડરની ખાતરી આપવામાં આવતી નથી). અમુક પરિસ્થિતિઓમાં, ઇન્ડેક્સ દ્વારા બહુવિધ રેકોર્ડ્સ વાંચવા સાથે - સંખ્યાબંધ પ્રશ્નો માટે આ એક સારું ઑપ્ટિમાઇઝેશન છે. આદેશનો ગેરલાભ VACUUM FULL ની જેમ જ છે - તે ઓપરેશન દરમિયાન ટેબલને લૉક કરે છે.

ટીમ REINDEX અગાઉના બે જેવું જ છે, પરંતુ ચોક્કસ અનુક્રમણિકા અથવા કોષ્ટકના તમામ અનુક્રમણિકાઓનું પુનઃનિર્માણ કરે છે. તાળાઓ થોડા નબળા છે: ટેબલ પર શેરલોક (સુધારાઓને અટકાવે છે, પરંતુ પસંદગીને મંજૂરી આપે છે) અને પુનઃબીલ્ડ થઈ રહેલા અનુક્રમણિકા પર AccessExclusiveLock (આ અનુક્રમણિકાનો ઉપયોગ કરીને પ્રશ્નોને અવરોધિત કરે છે). જો કે, પોસ્ટગ્રેસના 12મા સંસ્કરણમાં એક પરિમાણ દેખાયો એકસાથે, જે તમને સહવર્તી ઉમેરણ, ફેરફાર અથવા રેકોર્ડ્સને કાઢી નાખવાને અવરોધિત કર્યા વિના ઇન્ડેક્સને ફરીથી બનાવવાની મંજૂરી આપે છે.

Postgres ના પહેલાનાં સંસ્કરણોમાં, તમે એકસાથે REINDEX નો ઉપયોગ કરીને સમાન પરિણામ પ્રાપ્ત કરી શકો છો એકસાથે ઇન્ડેક્સ બનાવો. તે તમને કડક લોકીંગ વિના ઇન્ડેક્સ બનાવવા માટે પરવાનગી આપે છે (ShareUpdateExclusiveLock, જે સમાંતર પ્રશ્નોમાં દખલ કરતું નથી), પછી જૂના અનુક્રમણિકાને નવા સાથે બદલો અને જૂની અનુક્રમણિકા કાઢી નાખો. આ તમને તમારી એપ્લિકેશનમાં દખલ કર્યા વિના ઇન્ડેક્સ બ્લોટને દૂર કરવાની મંજૂરી આપે છે. તે ધ્યાનમાં લેવું મહત્વપૂર્ણ છે કે જ્યારે અનુક્રમણિકાઓનું પુનર્નિર્માણ કરવામાં આવે ત્યારે ડિસ્ક સબસિસ્ટમ પર વધારાનો ભાર હશે.

આમ, જો અનુક્રમણિકાઓ માટે "ફ્લાય પર" બ્લોટને દૂર કરવાની રીતો છે, તો પછી કોષ્ટકો માટે કોઈ નથી. આ તે છે જ્યાં વિવિધ બાહ્ય એક્સ્ટેંશન રમતમાં આવે છે: pg_repack (અગાઉ pg_reorg), pgcompact, pg કોમ્પેક્ટેબલ અને અન્ય. આ લેખમાં, હું તેમની તુલના કરીશ નહીં અને ફક્ત pg_repack વિશે વાત કરીશ, જે, કેટલાક ફેરફાર કર્યા પછી, અમે અમારી જાતને ઉપયોગ કરીએ છીએ.

કેવી રીતે pg_repack કામ કરે છે

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

આગળ, pg_repack જૂના કોષ્ટકમાંથી ડેટાને નવા કોષ્ટકમાં સ્થાનાંતરિત કરે છે, આપમેળે બધી અપ્રસ્તુત પંક્તિઓને ફિલ્ટર કરે છે, અને પછી નવા કોષ્ટક માટે અનુક્રમણિકાઓ બનાવે છે. આ તમામ કામગીરીના અમલ દરમિયાન, લોગ ટેબલમાં ફેરફારો એકઠા થાય છે.

આગળનું પગલું એ ફેરફારોને નવા કોષ્ટકમાં સ્થાનાંતરિત કરવાનું છે. સ્થાનાંતરણ અનેક પુનરાવર્તનો પર કરવામાં આવે છે, અને જ્યારે લોગ કોષ્ટકમાં 20 થી ઓછી એન્ટ્રીઓ બાકી હોય, ત્યારે pg_repack એક મજબૂત લોક મેળવે છે, નવીનતમ ડેટા સ્થાનાંતરિત કરે છે, અને પોસ્ટગ્રેસ સિસ્ટમ કોષ્ટકોમાં નવા સાથે જૂના કોષ્ટકને બદલે છે. આ એકમાત્ર અને ખૂબ જ ટૂંકા સમય છે જ્યારે તમે ટેબલ સાથે કામ કરી શકશો નહીં. આ પછી, જૂનું ટેબલ અને લોગ સાથેનું ટેબલ કાઢી નાખવામાં આવે છે અને ફાઇલ સિસ્ટમમાં જગ્યા ખાલી કરવામાં આવે છે. પ્રક્રિયા પૂર્ણ થઈ ગઈ છે.

સિદ્ધાંતમાં બધું સરસ લાગે છે, પરંતુ વ્યવહારમાં શું થાય છે? અમે લોડ વિના અને લોડ હેઠળ 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
);

કારણ કે અમારી પ્રારંભિક વિનંતીનો તર્ક ખાતરી કરે છે કે પ્રતિબદ્ધ સમયે તમામ મૂલ્યો અનન્ય છે, તે સફળ થશે.

ઉપર ચર્ચા કરેલ ઉદાહરણ, અલબત્ત, ખૂબ જ કૃત્રિમ છે, પરંતુ તે વિચારને છતી કરે છે. અમારી એપ્લિકેશનમાં, અમે તર્કને અમલમાં મૂકવા માટે વિલંબિત અવરોધોનો ઉપયોગ કરીએ છીએ જે તકરાર ઉકેલવા માટે જવાબદાર છે જ્યારે વપરાશકર્તાઓ એકસાથે બોર્ડ પર શેર કરેલ વિજેટ ઑબ્જેક્ટ્સ સાથે કામ કરે છે. આવા પ્રતિબંધોનો ઉપયોગ કરીને અમને એપ્લિકેશન કોડને થોડો સરળ બનાવવાની મંજૂરી આપે છે.

સામાન્ય રીતે, મર્યાદાના પ્રકાર પર આધાર રાખીને, પોસ્ટગ્રેસ પાસે તેમને તપાસવા માટે ગ્રેન્યુલારિટીના ત્રણ સ્તરો છે: પંક્તિ, વ્યવહાર અને અભિવ્યક્તિ સ્તર.

સોર્સ: begriffs

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 ના પાછલા પગલામાં રહેલું છે, જે ફક્ત અનુક્રમણિકાઓ બનાવે છે, પરંતુ અવરોધો નહીં: જૂના કોષ્ટકમાં એક અનન્ય અવરોધ હતો, અને તેના બદલે નવાએ એક અનન્ય અનુક્રમણિકા બનાવ્યું હતું.

અહીં એ નોંધવું અગત્યનું છે કે જો અવરોધ સામાન્ય હોય અને વિલંબિત ન હોય, તો તેના બદલે બનાવેલ અનન્ય અનુક્રમણિકા આ ​​અવરોધની સમકક્ષ છે, કારણ કે Postgres માં અનન્ય અવરોધો એક અનન્ય અનુક્રમણિકા બનાવીને લાગુ કરવામાં આવે છે. પરંતુ વિલંબિત અવરોધના કિસ્સામાં, વર્તન સમાન હોતું નથી, કારણ કે અનુક્રમણિકા વિલંબિત કરી શકાતી નથી અને તે હંમેશા 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. સ્વિકાર્ય સ્તર પર બ્લોટ રાખવા માટે ઓટોવેક્યુમને એડજસ્ટ કરો.
3. જો બ્લોટ હજી પણ વધી રહ્યું છે અને તમે આઉટ-ઓફ-ધ-બોક્સ સાધનોનો ઉપયોગ કરીને તેને દૂર કરી શકતા નથી, તો બાહ્ય એક્સ્ટેંશનનો ઉપયોગ કરવાથી ડરશો નહીં. મુખ્ય વસ્તુ એ છે કે બધું સારી રીતે ચકાસવું.
4. તમારી જરૂરિયાતોને અનુરૂપ બાહ્ય ઉકેલોને સંશોધિત કરવામાં ડરશો નહીં - કેટલીકવાર આ તમારા પોતાના કોડને બદલવા કરતાં વધુ અસરકારક અને સરળ પણ હોઈ શકે છે.

સોર્સ: www.habr.com