પ્રિય કાઢી નાખો. નિકોલે સમોખવાલોવ (Postgres.ai)

દૂરના ભવિષ્યમાં કોઈક સમયે, બિનજરૂરી ડેટાને આપમેળે દૂર કરવું એ DBMS [1] ના મહત્વપૂર્ણ કાર્યોમાંનું એક હશે. આ દરમિયાન, આપણે બિનજરૂરી ડેટાને કાઢી નાખવા અથવા ઓછા ખર્ચાળ સ્ટોરેજ સિસ્ટમમાં ખસેડવાની કાળજી લેવાની જરૂર છે. ચાલો કહીએ કે તમે અમુક મિલિયન પંક્તિઓ કાઢી નાખવાનું નક્કી કર્યું છે. એકદમ સરળ કાર્ય, ખાસ કરીને જો સ્થિતિ જાણીતી હોય અને યોગ્ય અનુક્રમણિકા હોય. "કોષ્ટક 1 થી કાઢી નાખો જ્યાં col1 = :value" - શું સરળ હોઈ શકે, બરાબર?

વિડિઓ:

• હું પહેલા વર્ષથી એટલે કે 2007 થી હાઇલોડ પ્રોગ્રામ કમિટીમાં છું.

• અને હું 2005 થી પોસ્ટગ્રેસ સાથે છું. ઘણા પ્રોજેક્ટ્સમાં તેનો ઉપયોગ કર્યો.

• RuPostges સાથે ગ્રૂપ પણ 2007 થી.

• અમે મીટઅપમાં 2100+ સહભાગીઓ સુધી વધ્યા છીએ. તે ન્યૂયોર્ક પછી વિશ્વમાં બીજા સ્થાને છે, જે લાંબા સમયથી સાન ફ્રાન્સિસ્કોથી આગળ નીકળી ગયું છે.

• હું ઘણા વર્ષોથી કેલિફોર્નિયામાં રહું છું. હું મોટી કંપનીઓ સહિત અમેરિકન કંપનીઓ સાથે વધુ વ્યવહાર કરું છું. તેઓ પોસ્ટગ્રેસના સક્રિય વપરાશકર્તાઓ છે. અને ત્યાં તમામ પ્રકારની રસપ્રદ વસ્તુઓ છે.

https://postgres.ai/ મારી કંપની છે. અમે સ્વચાલિત કાર્યોના વ્યવસાયમાં છીએ જે વિકાસની મંદીને દૂર કરે છે.

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

https://www.seagate.com/files/www-content/our-story/trends/files/idc-seagate-dataage-whitepaper.pdf

હું તાજેતરમાં લોસ એન્જલસમાં VLDB ખાતે હતો. ડેટાબેઝ પરની આ સૌથી મોટી કોન્ફરન્સ છે. અને એવો અહેવાલ હતો કે ભવિષ્યમાં ડીબીએમએસ ફક્ત ડેટા જ સંગ્રહિત કરશે નહીં, પણ આપમેળે ડેટા કાઢી નાખશે. આ એક નવો વિષય છે.

ઝેટાબાઇટ્સની દુનિયામાં વધુ ને વધુ ડેટા છે - તે 1 પેટાબાઇટ્સ છે. અને હવે એવો અંદાજ છે કે અમારી પાસે વિશ્વમાં 000 થી વધુ ઝેટાબાઇટ્સ ડેટા સંગ્રહિત છે. અને તેમાંના વધુ અને વધુ છે.

https://vldb2019.github.io/files/VLDB19-keynote-2-slides.pdf

અને તેની સાથે શું કરવું? દેખીતી રીતે તેને દૂર કરવાની જરૂર છે. આ રસપ્રદ અહેવાલની લિંક અહીં છે. પરંતુ હજુ સુધી ડીબીએમએસમાં આનો અમલ કરવામાં આવ્યો નથી.

જેઓ પૈસા ગણી શકે છે તેમને બે વસ્તુઓ જોઈએ છે. તેઓ ઇચ્છે છે કે અમે કાઢી નાખીએ, તેથી તકનીકી રીતે અમે તે કરવા સક્ષમ હોવા જોઈએ.

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

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

સામાન્ય રીતે, કાર્ય અમુક કોષ્ટકમાં ચોક્કસ વસ્તુઓ, ચોક્કસ રેખાઓને કાઢી નાખવાનું સ્વચાલિત કરવાનું છે.

અને અમારી પાસે આવી વિનંતી છે, જેના વિશે આપણે આજે વાત કરીશું, એટલે કે કચરો દૂર કરવા વિશે.

અમે એક અનુભવી વિકાસકર્તાને તે કરવા માટે કહ્યું. તેણે આ વિનંતી લીધી, તેને પોતાને માટે તપાસી - બધું કાર્ય કરે છે. સ્ટેજિંગ પર પરીક્ષણ કર્યું - બધું સારું છે. બહાર વળેલું - બધું કામ કરે છે. દિવસમાં એકવાર અમે તેને ચલાવીએ છીએ - બધું સારું છે.

ડેટાબેઝ વધે છે અને વધે છે. દૈનિક DELETE થોડી વધુ ધીમેથી કામ કરવાનું શરૂ કરે છે.

પછી અમે સમજીએ છીએ કે હવે અમારી પાસે માર્કેટિંગ કંપની છે અને ટ્રાફિક અનેક ગણો મોટો હશે, તેથી અમે બિનજરૂરી વસ્તુઓને અસ્થાયી રૂપે થોભાવવાનું નક્કી કરીએ છીએ. અને પાછા ફરવાનું ભૂલી જાઓ.

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

તેણે સ્ટેજિંગ પર, દેવ પર તપાસ કરી - બધું બરાબર છે. સ્વાભાવિક રીતે, તમારે હજી પણ જે સંચિત થયું છે તેને સાફ કરવાની જરૂર છે. તેણે બધું કામ તપાસ્યું.

આગળ શું થશે? પછી બધું આપણા માટે અલગ પડે છે. તે ડ્રોપ કરે છે જેથી અમુક સમયે બધું નીચે પડી જાય. દરેક જણ આઘાતમાં છે, કોઈ સમજી શકતું નથી કે શું થઈ રહ્યું છે. અને પછી ખબર પડી કે મામલો આ DELETE માં હતો.

કંઈક ખોટું થયું? અહીં શું ખોટું થઈ શકે છે તેની સૂચિ છે. આમાંથી કયું સૌથી મહત્વનું છે?

• ઉદાહરણ તરીકે, ત્યાં કોઈ સમીક્ષા ન હતી, એટલે કે DBA નિષ્ણાતે તેને જોયો ન હતો. તે તરત જ અનુભવી આંખથી સમસ્યા શોધી કાઢશે, અને તે ઉપરાંત, તેની પાસે પ્રોડની ઍક્સેસ છે, જ્યાં ઘણી મિલિયન લાઇન્સ એકઠી થઈ છે.

• કદાચ તેઓએ કંઈક ખોટું કર્યું છે.

• કદાચ હાર્ડવેર જૂનું છે અને તમારે આ આધારને અપગ્રેડ કરવાની જરૂર છે.

• અથવા ડેટાબેઝમાં જ કંઈક ખોટું છે, અને અમારે Postgres થી MySQL પર જવાની જરૂર છે.

• અથવા કદાચ ઓપરેશનમાં કંઈક ખોટું છે.

• કદાચ કામના સંગઠનમાં કેટલીક ભૂલો છે અને તમારે કોઈને બરતરફ કરવાની અને શ્રેષ્ઠ લોકોને નોકરી પર રાખવાની જરૂર છે?

ત્યાં કોઈ DBA ચેક ન હતો. જો કોઈ DBA હોત, તો તે આ લાખો લીટીઓ જોશે અને કોઈપણ પ્રયોગો કર્યા વિના પણ કહેશે: "તેઓ તે કરતા નથી." ધારો કે જો આ કોડ GitLab, GitHub માં હોત અને ત્યાં કોડ સમીક્ષા પ્રક્રિયા હોય અને એવી કોઈ વસ્તુ ન હોય કે DBA ની મંજૂરી વિના આ ઑપરેશન પ્રોડ પર થશે, તો દેખીતી રીતે DBA કહેશે: "આ કરી શકાતું નથી. "

અને તે કહેશે કે તમને ડિસ્ક IO માં સમસ્યા હશે અને બધી પ્રક્રિયાઓ પાગલ થઈ જશે, ત્યાં તાળાઓ હોઈ શકે છે, અને તમે થોડી મિનિટો માટે ઑટોવેક્યુમને અવરોધિત કરશો, તેથી આ સારું નથી.

http://bit.ly/nancy-hl2018-2

બીજી ભૂલ - તેઓએ ખોટી જગ્યાએ તપાસ કરી. અમે એ હકીકત પછી જોયું કે પ્રોડ પર ઘણો જંક ડેટા એકઠો થયો હતો, પરંતુ ડેવલપર પાસે આ ડેટાબેઝમાં સંચિત ડેટા નથી અને સ્ટેજિંગ દરમિયાન કોઈએ આ જંક બનાવ્યો નથી. તદનુસાર, ત્યાં 1 લાઇન હતી જે ઝડપથી કામ કરતી હતી.

અમે સમજીએ છીએ કે અમારા પરીક્ષણો નબળા છે, એટલે કે, જે પ્રક્રિયા બનાવવામાં આવી છે તે સમસ્યાઓને પકડી શકતી નથી. પર્યાપ્ત DB પ્રયોગ કરવામાં આવ્યો ન હતો.

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

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

જો તમારી પાસે વાદળો છે, તો પછી અપગ્રેડ ત્યાં સરળતાથી થઈ જાય છે. નવા હાર્ડવેર પર નવી પ્રતિકૃતિઓ ઊભી કરી. સ્વિચઓવર અને બધું સારું છે. ખૂબ સરળ.

શું કોઈક રીતે નાની ડિસ્કને સ્પર્શ કરવાનું શક્ય છે? અને અહીં, ફક્ત DBA ની મદદથી, અમે ચેકપોઇન્ટ ટ્યુનિંગ નામના ચોક્કસ વિષયમાં ડાઇવ કરીએ છીએ. તે તારણ આપે છે કે અમારી પાસે ચેકપોઇન્ટ ટ્યુનિંગ નથી.

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

Postgres માં સેટિંગ્સ પાછળ છે. તેઓ 10-15 વર્ષ જૂના ડેટા અને વ્યવહારો માટે ડિઝાઇન કરવામાં આવ્યા છે. અને ચેકપોઇન્ટ કોઈ અપવાદ નથી.

અહીં અમારા પોસ્ટગ્રેસ ચેક-અપ રિપોર્ટની માહિતી છે, એટલે કે સ્વચાલિત આરોગ્ય તપાસ. અને અહીં કેટલાક ટેરાબાઈટનો ડેટાબેઝ છે. અને તે સારી રીતે જોઈ શકાય છે કે લગભગ 90% કિસ્સાઓમાં ફરજિયાત ચેકપોઇન્ટ્સ.

તેનો અર્થ શું છે? ત્યાં બે સેટિંગ્સ છે. ચેકપોઇન્ટ સમયસમાપ્તિ દ્વારા આવી શકે છે, ઉદાહરણ તરીકે, 10 મિનિટે. અથવા તે ત્યારે આવી શકે છે જ્યારે ઘણો ડેટા ભરવામાં આવ્યો હોય.

અને મૂળભૂત રીતે max_wal_saze 1 ગીગાબાઈટ પર સેટ કરેલ છે. વાસ્તવમાં, આ ખરેખર 300-400 મેગાબાઇટ્સ પછી પોસ્ટગ્રેસમાં થાય છે. તમે ઘણો ડેટા બદલ્યો છે અને તમારી ચેકપોઇન્ટ થાય છે.

અને જો કોઈએ તેને ટ્યુન કર્યું નથી, અને સેવામાં વધારો થયો છે, અને કંપની ઘણા પૈસા કમાય છે, તેની પાસે ઘણા બધા વ્યવહારો છે, તો પછી ચેકપોઇન્ટ એક મિનિટમાં એકવાર આવે છે, કેટલીકવાર દર 30 સેકન્ડે, અને કેટલીકવાર ઓવરલેપ પણ થાય છે. આ તદ્દન ખરાબ છે.

અને આપણે ખાતરી કરવાની જરૂર છે કે તે ઓછી વાર આવે છે. એટલે કે, આપણે max_wal_size વધારી શકીએ છીએ. અને તે ઓછી વાર આવશે.

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

તદનુસાર, અમે ડેટાબેઝ પર પ્રયોગોની બે શ્રેણી કરી રહ્યા છીએ.

પ્રથમ શ્રેણી - અમે max_wal_size બદલીએ છીએ. અને અમે મોટા પાયે ઓપરેશન કરી રહ્યા છીએ. પ્રથમ, આપણે તેને 1 ગીગાબાઈટના ડિફોલ્ટ સેટિંગ પર કરીએ છીએ. અને અમે લાખો લીટીઓને મોટા પાયે ડીલીટ કરીએ છીએ.

તમે જોઈ શકો છો કે તે અમારા માટે કેટલું મુશ્કેલ છે. આપણે જોઈએ છીએ કે ડિસ્ક IO ખૂબ જ ખરાબ છે. અમે જોઈએ છીએ કે અમે કેટલા WAL જનરેટ કર્યા છે, કારણ કે આ ખૂબ જ મહત્વપૂર્ણ છે. ચાલો જોઈએ કેટલી વાર ચોકી થઈ. અને આપણે જોઈએ છીએ કે તે સારું નથી.

આગળ આપણે max_wal_size વધારીએ છીએ. અમે પુનરાવર્તન કરીએ છીએ. અમે વધારો, અમે પુનરાવર્તન. અને ઘણી વખત. સૈદ્ધાંતિક રીતે, 10 પોઇન્ટ સારા છે, જ્યાં 1, 2, 4, 8 ગીગાબાઇટ્સ. અને અમે ચોક્કસ સિસ્ટમના વર્તનને જોઈએ છીએ. તે સ્પષ્ટ છે કે અહીં સાધનો પ્રોડ જેવા હોવા જોઈએ. તમારી પાસે સમાન ડિસ્ક, સમાન મેમરી અને સમાન પોસ્ટગ્રેસ સેટિંગ્સ હોવી આવશ્યક છે.

અને આ રીતે અમે અમારી સિસ્ટમનું વિનિમય કરીશું, અને અમે જાણીએ છીએ કે ખરાબ માસ DELETE ના કિસ્સામાં DBMS કેવી રીતે વર્તશે, તે કેવી રીતે ચેકપોઇન્ટ કરશે.

રશિયનમાં ચેકપોઇન્ટ એ ચેકપોઇન્ટ છે.

ઉદાહરણ: અનુક્રમણિકા દ્વારા ઘણી મિલિયન પંક્તિઓ કાઢી નાખો, પંક્તિઓ પૃષ્ઠો પર "વિખેરાયેલી" છે.

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

જો આવા ઓપરેશનને પ્રોડમાં મંજૂરી આપવામાં આવે છે, તો અમે ફક્ત સૂઈશું, કારણ કે તે સ્પષ્ટ છે કે એક DELETE અમને શેલ્ફમાં મારી નાખે છે.

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

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

શા માટે?

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

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

અને અમે તેને ઘણી વખત સાચવવા માટે ચેકપોઇન્ટ પર દબાણ કરીશું. તેના માટે નિરર્થક કામગીરી કેવી રીતે થશે.

પરંતુ તે બધુ જ નથી. પૃષ્ઠો પોસ્ટગ્રેસમાં 8 કિલોબાઈટ અને લિનક્સમાં 4 કિલોબાઈટ છે. અને ફુલ_પેજ_રાઇટ્સ સેટિંગ છે. તે મૂળભૂત રીતે સક્ષમ છે. અને આ સાચું છે, કારણ કે જો આપણે તેને બંધ કરીએ, તો એક ભય છે કે જો તે ક્રેશ થાય તો ફક્ત અડધુ પૃષ્ઠ જ સાચવવામાં આવશે.

ફોરવર્ડ લોગના WAL પર લખવાની વર્તણૂક એવી છે કે જ્યારે આપણી પાસે ચેકપોઈન્ટ હોય અને આપણે પહેલીવાર પેજ બદલીએ, ત્યારે આખું પેજ, એટલે કે તમામ 8 કિલોબાઈટ, ફોરવર્ડ લોગમાં આવી જાય છે, જો કે આપણે ફક્ત બદલાવ કર્યો છે. રેખા, જેનું વજન 100 બાઇટ્સ છે. અને આપણે આખું પાનું લખવાનું છે.

અનુગામી ફેરફારોમાં, માત્ર એક ચોક્કસ ટ્યુપલ હશે, પરંતુ પ્રથમ વખત અમે બધું લખીશું.

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

અને, તે મુજબ, અમારી પાસે બે નિરર્થકતા છે.

જો આપણે max_wal_size વધારીએ છીએ, તો તે તારણ આપે છે કે અમે તેને ચેકપોઇન્ટ અને વોલ રાઇટર બંને માટે સરળ બનાવીએ છીએ. અને તે મહાન છે.

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

અમે એક ઑપરેશન કરીએ છીએ અને જોઈએ છીએ કે ચેકપોઇન્ટ ક્યારે પૂર્ણ થવાનું છે, અમે હેતુસર -9 પોસ્ટગ્રેસને મારી નાખીએ છીએ.

અને તે પછી અમે તેને ફરીથી શરૂ કરીએ છીએ, અને જુઓ કે તે આ સાધન પર કેટલો સમય વધશે, એટલે કે આ ખરાબ પરિસ્થિતિમાં તે કેટલું REDO કરશે.

બે વાર હું નોંધ કરીશ કે પરિસ્થિતિ ખરાબ છે. પ્રથમ, અમે ચેકપોઇન્ટ સમાપ્ત થાય તે પહેલાં જ ક્રેશ થઈ ગયા, તેથી અમારે ઘણું ગુમાવવાનું છે. અને બીજું, અમે એક વિશાળ ઓપરેશન કર્યું. અને જો ચેકપોઇન્ટ સમયસમાપ્તિ પર હતા, તો સંભવતઃ છેલ્લી ચેકપોઇન્ટથી ઓછી WAL જનરેટ થશે. એટલે કે તે ડબલ લુઝર છે.

અમે આવી સ્થિતિને વિવિધ max_wal_size માપો માટે માપીએ છીએ અને સમજીએ છીએ કે જો max_wal_size 64 ગીગાબાઇટ્સ છે, તો બેવડા ખરાબ કિસ્સામાં આપણે 10 મિનિટ સુધી ચઢીશું. અને અમે વિચારીએ છીએ કે તે અમને અનુકૂળ છે કે નહીં. આ એક વ્યવસાય પ્રશ્ન છે. અમારે વ્યવસાયના નિર્ણયો માટે જવાબદાર લોકોને આ ચિત્ર બતાવવાની જરૂર છે અને પૂછવું જોઈએ, "કોઈ સમસ્યાના કિસ્સામાં આપણે વધુમાં વધુ કેટલો સમય સૂઈ શકીએ? શું આપણે સૌથી ખરાબ પરિસ્થિતિમાં 3-5 મિનિટ સૂઈ શકીએ? અને તમે નિર્ણય લો.

અને અહીં એક રસપ્રદ મુદ્દો છે. અમે કોન્ફરન્સમાં Patroni વિશે અહેવાલો એક દંપતિ છે. અને કદાચ તમે તેનો ઉપયોગ કરી રહ્યા છો. આ Postgres માટે ઓટોફેઈલઓવર છે. ગિટલેબ અને ડેટા એગ્રેટે આ વિશે વાત કરી.

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

નિષ્ફળતા પછી જો આપણી પાસે લાંબી રિકવરી હોય, તો આપણે બીજી ઘણી પરિસ્થિતિઓમાં અસ્વસ્થતા અનુભવીએ છીએ. ઉદાહરણ તરીકે, સમાન પ્રયોગોમાં, જ્યારે આપણે કંઈક કરીએ છીએ અને કેટલીકવાર 10 મિનિટ રાહ જોવી પડે છે.

જો અમારી પાસે ઑટોફેલઓવર હોય તો પણ હું હજી પણ બહુ દૂર જઈશ નહીં. એક નિયમ તરીકે, મૂલ્યો જેમ કે 64, 100 ગીગાબાઇટ્સ સારા મૂલ્યો છે. કેટલીકવાર તે ઓછું પસંદ કરવાનું પણ યોગ્ય છે. સામાન્ય રીતે, આ એક સૂક્ષ્મ વિજ્ઞાન છે.

પુનરાવર્તનો કરવા માટે, ઉદાહરણ તરીકે, max_wal_size =1, 8, તમારે સામૂહિક કામગીરીને ઘણી વખત પુનરાવર્તિત કરવાની જરૂર છે. તમે તેને બનાવ્યું. અને તે જ આધાર પર તમે તેને ફરીથી કરવા માંગો છો, પરંતુ તમે પહેલાથી જ બધું કાઢી નાખ્યું છે. શુ કરવુ?

હું અમારા ઉકેલ વિશે પછીથી વાત કરીશ, આવી પરિસ્થિતિઓમાં પુનરાવર્તન કરવા માટે અમે શું કરીએ છીએ. અને આ સૌથી સાચો અભિગમ છે.

પરંતુ આ કિસ્સામાં, અમે નસીબદાર હતા. જો, જેમ તે અહીં કહે છે "BEGIN, DELETE, ROLLBACK", તો આપણે DELETE પુનરાવર્તન કરી શકીએ છીએ. એટલે કે, જો આપણે તેને જાતે રદ કર્યું છે, તો આપણે તેને પુનરાવર્તન કરી શકીએ છીએ. અને ભૌતિક રીતે તમારા પર ડેટા તે જ જગ્યાએ રહેશે. તમને કોઈ ફૂલે પણ નથી મળતું. તમે આવા DELETEs પર પુનરાવર્તન કરી શકો છો.

ROLLBACK સાથેનું આ DELETE ચેકપૉઇન્ટ ટ્યુનિંગ માટે આદર્શ છે, પછી ભલે તમારી પાસે ડેટાબેઝ લેબ યોગ્ય રીતે ગોઠવાયેલ ન હોય.

અમે એક કૉલમ "i" સાથે પ્લેટ બનાવી. પોસ્ટગ્રેસમાં ઉપયોગિતા કૉલમ છે. તેઓ અદ્રશ્ય છે સિવાય કે ખાસ માટે પૂછવામાં આવે. આ છે: ctid, xmid, xmax.

Ctid એ ભૌતિક સરનામું છે. શૂન્ય પૃષ્ઠ, પૃષ્ઠમાં પ્રથમ ટ્યુપલ.

તે જોઈ શકાય છે કે રૂલબેક પછી ટપલ એ જ જગ્યાએ રહી. એટલે કે, આપણે ફરીથી પ્રયાસ કરી શકીએ છીએ, તે તે જ રીતે વર્તે છે. આ મુખ્ય વસ્તુ છે.

Xmax એ ટપલના મૃત્યુનો સમય છે. તેના પર સ્ટેમ્પ લગાવવામાં આવ્યો હતો, પરંતુ પોસ્ટગ્રેસ જાણે છે કે ટ્રાન્ઝેક્શન રોલ બેક કરવામાં આવ્યું હતું, તેથી તે 0 છે કે તે રોલ બેક ટ્રાન્ઝેક્શન છે તેનાથી કોઈ ફરક પડતો નથી. આ સૂચવે છે કે DELETE પર પુનરાવર્તિત કરવું શક્ય છે અને સિસ્ટમ વર્તણૂકની બલ્ક કામગીરી તપાસો. તમે ગરીબો માટે ડેટાબેઝ લેબ બનાવી શકો છો.

આ પ્રોગ્રામરો વિશે છે. ડીબીએ વિશે પણ, તેઓ હંમેશા આ માટે પ્રોગ્રામરોને ઠપકો આપે છે: "તમે આટલા લાંબા અને મુશ્કેલ ઓપરેશન્સ કેમ કરો છો?". આ એક સંપૂર્ણપણે અલગ કાટખૂણે વિષય છે. પહેલા વહીવટ હતો, હવે વિકાસ થશે.

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

તોડવું શા માટે મહત્વનું છે?

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

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

https://postgres.ai/products/joe/

આ રસપ્રદ છે. હું વારંવાર જોઉં છું કે વિકાસકર્તાઓ પૂછે છે: "મારે કયા પૅકનું કદ પસંદ કરવું જોઈએ?".

તે સ્પષ્ટ છે કે બંડલનું કદ જેટલું મોટું છે, તેટલું નાનું ટ્રાન્ઝેક્શન ઓવરહેડ, એટલે કે, વ્યવહારોમાંથી વધારાનું ઓવરહેડ. પરંતુ તે જ સમયે, આ વ્યવહાર માટે સમય વધે છે.

મારો એક ખૂબ જ સરળ નિયમ છે: તમે જેટલું કરી શકો તેટલું લો, પરંતુ એક્ઝિક્યુટેબલ પ્રતિ સેકન્ડ પર ન જાઓ.

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

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

અમે પેકનું કદ પસંદ કરીએ છીએ. દરેક કિસ્સામાં, અમે તેને અલગ રીતે કરી શકીએ છીએ. સ્વયંસંચાલિત થઈ શકે છે. અને અમે એક પેકની પ્રક્રિયાની કાર્યક્ષમતા અંગે સહમત છીએ. એટલે કે, અમે એક પેકને ડીલીટ કરીએ છીએ અથવા અપડેટ કરીએ છીએ.

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

અને આપણે જોઈએ છીએ કે યોજના ઉત્તમ છે. તમે ઈન્ડેક્સ સ્કેન જોઈ શકો છો, માત્ર ઈન્ડેક્સ સ્કેન વધુ સારું છે. અને અમારી પાસે થોડી માત્રામાં ડેટા સામેલ છે. અને એક સેકન્ડ કરતાં પણ ઓછા સમયમાં પરિપૂર્ણ થાય છે. સુપર.

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

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

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

https://docs.gitlab.com/ee/development/background_migrations.html

પાર્ટીશનની વ્યૂહરચના શું છે? હું 3 અલગ અલગ પાર્ટીશનીંગ વ્યૂહરચના જોઉં છું જેનો ઉપયોગ પેક પરના વિકાસકર્તાઓ કરી રહ્યા છે.

પ્રથમ એક ખૂબ જ સરળ છે. અમારી પાસે સંખ્યાત્મક ID છે. અને ચાલો તેને અલગ-અલગ અંતરાલોમાં વિભાજીત કરીએ અને તેની સાથે કામ કરીએ. નુકસાન સ્પષ્ટ છે. પ્રથમ સેગમેન્ટમાં, અમારી પાસે વાસ્તવિક કચરાની 100 લાઇન હોઈ શકે છે, બીજી 5 લાઇનમાં અથવા બિલકુલ નહીં, અથવા બધી 1 લાઇન કચરો બની જશે. ખૂબ જ અસમાન કામ, પરંતુ તેને તોડવું સરળ છે. તેઓએ મહત્તમ ID લીધું અને તેને તોડી નાખ્યું. આ એક નિષ્કપટ અભિગમ છે.

બીજી વ્યૂહરચના એ સંતુલિત અભિગમ છે. તેનો ઉપયોગ ગિટલેબમાં થાય છે. તેઓએ ટેબલ લીધું અને સ્કેન કર્યું. અમે ID પેકની સીમાઓ શોધી કાઢી જેથી દરેક પેકમાં બરાબર 10 રેકોર્ડ હોય. અને તેમને એક કતારમાં મૂકો. અને પછી અમે પ્રક્રિયા કરીએ છીએ. તમે આ બહુવિધ થ્રેડોમાં કરી શકો છો.

પ્રથમ વ્યૂહરચનામાં, પણ, માર્ગ દ્વારા, તમે આ ઘણા થ્રેડોમાં કરી શકો છો. તે મુશ્કેલ નથી.

https://medium.com/@samokhvalov/how-partial-indexes-affect-update-performance-in-postgres-d05e0052abc

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

સામાન્ય રીતે, માત્ર ઇન્ડેક્સ સ્કેન ઇન્ડેક્સ સ્કેન કરતાં વધુ ઝડપી છે.

અને અમે ઝડપથી અમારા ID શોધીએ છીએ જેને અમે કાઢી નાખવા માંગીએ છીએ. BATCH_SIZE અમે અગાઉથી પસંદ કરીએ છીએ. અને અમે ફક્ત તેમને જ મેળવી શકતા નથી, અમે તેમને એક વિશિષ્ટ રીતે મેળવીએ છીએ અને તરત જ તેમને હેક કરીએ છીએ. પરંતુ અમે લોક કરી રહ્યા છીએ જેથી જો તેઓ પહેલેથી જ લૉક હોય, તો અમે તેમને લૉક કરતા નથી, પરંતુ આગળ વધીએ છીએ અને આગળના લોકોને લઈએ છીએ. આ અપડેટ સ્કીપ લૉક માટે છે. Postgres ની આ સુપર ફીચર અમને ઘણા થ્રેડોમાં કામ કરવાની પરવાનગી આપે છે જો આપણે ઈચ્છીએ. તે એક પ્રવાહમાં શક્ય છે. અને અહીં એક CTE છે - આ એક વિનંતી છે. અને અમારી પાસે આ CTE ના બીજા માળે વાસ્તવિક કાઢી નાખવાનું કામ ચાલી રહ્યું છે - returning *. તમે આઈડી પરત કરી શકો છો, પરંતુ તે વધુ સારું છે *જો તમારી પાસે દરેક લાઇન પર વધુ ડેટા નથી.

શા માટે આપણને તેની જરૂર છે? આ તે છે જેને આપણે પાછા જાણ કરવાની જરૂર છે. અમે હવે હકીકતમાં ઘણી બધી રેખાઓ કાઢી નાખી છે. અને અમારી પાસે ID દ્વારા અથવા આના જેવા create_at દ્વારા સરહદો છે. તમે ન્યૂનતમ, મહત્તમ કરી શકો છો. બીજું કંઈક કરી શકાય. તમે અહીં ઘણું બધું ભરી શકો છો. અને તે મોનીટરીંગ માટે ખૂબ જ અનુકૂળ છે.

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

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

પરંતુ આ સૌથી શ્રેષ્ઠ વ્યૂહરચના છે, કેવી રીતે બેચેસમાં વિભાજિત કરવું અને એક વિનંતી સાથે બેચ પર શૂટ કરવું, થોડું કાઢી નાખવું વગેરે.

લાંબા વ્યવહારો https://gitlab.com/snippets/1890447

અવરોધિત ઓટોવેક્યુમ - https://gitlab.com/snippets/1889668

અવરોધિત સમસ્યા - https://gitlab.com/snippets/1890428

ભૂલ #5 એક મોટી છે. ઓકમેટરના નિકોલાઈએ પોસ્ટગ્રેસ મોનિટરિંગ વિશે વાત કરી. આદર્શ પોસ્ટગ્રેસ મોનિટરિંગ, કમનસીબે, અસ્તિત્વમાં નથી. કેટલાક નજીક છે, કેટલાક દૂર છે. ઓકમીટર સંપૂર્ણ બનવા માટે પૂરતું નજીક છે, પરંતુ ઘણું બધું ખૂટે છે અને ઉમેરવાની જરૂર છે. તમારે આ માટે તૈયાર રહેવાની જરૂર છે.

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

જો ત્યાં મોટો IO છે, તો તે સ્પષ્ટ છે કે આ સારું નથી.

લાંબા વ્યવહારો પણ. OLTP પર લાંબા વ્યવહારોને મંજૂરી આપવી જોઈએ નહીં. અને અહીં એક સ્નિપેટની એક લિંક છે જે તમને આ સ્નિપેટ લેવા અને લાંબા વ્યવહારોની કેટલીક ટ્રેકિંગ કરવાની મંજૂરી આપે છે.

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

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

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

કેટલીકવાર આ બધી ભૂલો સરવાળે થાય છે.

મારા મતે, અહીં મુખ્ય ભૂલ સંસ્થાકીય છે. તે સંસ્થાકીય છે, કારણ કે તકનીક ખેંચતી નથી. આ નંબર 2 છે - તેઓએ ખોટી જગ્યાએ તપાસ કરી.

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

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

ઓટોવેક્યુમ વિશે વધુ. અમે ઘણી મિલિયન લાઇનોનો મોટા પાયે સ્વીપ કર્યા પછી, અમારે હજુ પણ REPACK કરવાની જરૂર છે. આ ખાસ કરીને અનુક્રમણિકાઓ માટે મહત્વપૂર્ણ છે. અમે ત્યાં બધું સાફ કર્યા પછી તેમને ખરાબ લાગશે.

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

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

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

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

ઉદાહરણ: 5 ટેરાબાઇટ ડેટાબેઝ, 30 સેકન્ડથી ઓછા સમયમાં નકલ મેળવવી. અને તે કદ પર પણ નિર્ભર નથી, એટલે કે, તે કેટલા ટેરાબાઇટ છે તેનાથી કોઈ ફરક પડતો નથી.

આજે તમે જઈ શકો છો postgres.ai અને અમારા સાધનોમાં ખોદવું. તમે ત્યાં શું છે તે જોવા માટે નોંધણી કરાવી શકો છો. તમે આ બોટ ઇન્સ્ટોલ કરી શકો છો. આ મફત છે. લખો.

પ્રશ્નો

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

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

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

જો તમે GitHub પર pg_repack જુઓ છો, તો ત્યાં, જ્યારે ID ને int 4 થી int 8 માં કન્વર્ટ કરવાનું કાર્ય હતું, ત્યારે pg_repack નો ઉપયોગ કરવાનો વિચાર આવ્યો હતો. આ પણ શક્ય છે, પરંતુ તે થોડી હેક છે, પરંતુ તે આ માટે પણ કામ કરશે. તમે pg_repack ઉપયોગ કરે છે તે ટ્રિગરમાં હસ્તક્ષેપ કરી શકો છો અને ત્યાં કહી શકો છો: "અમને આ ડેટાની જરૂર નથી", એટલે કે અમે ફક્ત અમને જે જોઈએ છે તે સ્થાનાંતરિત કરીએ છીએ. અને પછી તે માત્ર સ્વિચ કરે છે અને બસ.

આ અભિગમ સાથે, અમને હજી પણ કોષ્ટકની બીજી નકલ મળે છે, જેમાં ડેટા પહેલેથી જ અનુક્રમિત છે અને સુંદર અનુક્રમણિકાઓ સાથે ખૂબ જ સમાનરૂપે સ્ટેક થયેલ છે.

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

હું MySQL ની દુનિયાથી થોડો જ દૂર છું, તેથી હું સાંભળવા આવ્યો છું. અને અમે આ અભિગમનો ઉપયોગ કરીએ છીએ.

પરંતુ જો આપણી પાસે 90% હોય તો જ તે છે. જો અમારી પાસે 5% છે, તો તેનો ઉપયોગ કરવો ખૂબ સારું નથી.

રિપોર્ટ માટે આભાર! જો ઉત્પાદનની સંપૂર્ણ નકલ બનાવવા માટે કોઈ સંસાધનો નથી, તો શું લોડ અથવા કદની ગણતરી કરવા માટે કોઈ અલ્ગોરિધમ અથવા સૂત્ર છે?

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

રિપોર્ટ માટે આભાર! તમે સૌપ્રથમ એ હકીકત વિશે શરૂ કર્યું કે ત્યાં એક સરસ પોસ્ટગ્રેસ છે, જેમાં આવી અને આવી મર્યાદાઓ છે, પરંતુ તે વિકાસશીલ છે. અને આ બધુ મોટા પાયે છે. શું આ બધું પોસ્ટગ્રેસના જ વિકાસ સાથે સંઘર્ષમાં નથી, જેમાં કેટલાક DELETE deferent દેખાશે અથવા બીજું કંઈક જે આપણે અહીં અમારા કેટલાક વિચિત્ર માધ્યમો સાથે સ્મીયર કરવાનો પ્રયાસ કરી રહ્યા છીએ તે નીચા સ્તરે રાખવું જોઈએ?

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

અનુક્રમણિકાઓ સાથે પૂર્ણ.

હું ધારી શકું છું કે સમાન ચેકપોઇન્ટ ટ્યુનિંગ સ્વચાલિત થઈ શકે છે. કોઈ દિવસ તે હોઈ શકે છે. પરંતુ પછી હું ખરેખર પ્રશ્ન સમજી શકતો નથી.

પ્રશ્ન એ છે કે શું વિકાસનું એવું કોઈ વેક્ટર છે જે અહીં અને ત્યાં જાય છે, અને અહીં તમારું સમાંતર ચાલે છે? તે. શું તેઓએ હજી સુધી તેના વિશે વિચાર્યું નથી?

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

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

શુભ બપોર તમે લાંબા વ્યવહારોના જોખમો વિશે વાત કરી. તમે કહ્યું હતું કે કાઢી નાખવાના કિસ્સામાં ઓટોવેક્યુમ અવરોધિત છે. તે આપણને બીજું કેવી રીતે નુકસાન કરે છે? કારણ કે અમે જગ્યા ખાલી કરવા અને તેનો ઉપયોગ કરવા સક્ષમ બનવા વિશે વધુ વાત કરી રહ્યા છીએ. આપણે બીજું શું ગુમાવીએ છીએ?

ઑટોવેક્યુમ કદાચ અહીં સૌથી મોટી સમસ્યા નથી. અને હકીકત એ છે કે લાંબી ટ્રાન્ઝેક્શન અન્ય વ્યવહારોને લોક કરી શકે છે, આ શક્યતા વધુ ખતરનાક છે. તેણીને મળી શકે અથવા ન મળી શકે. જો તેણી મળી, તો તે ખૂબ જ ખરાબ હોઈ શકે છે. અને ઓટોવેક્યુમ સાથે - આ પણ એક સમસ્યા છે. OLTP માં લાંબા વ્યવહારો સાથે બે સમસ્યાઓ છે: લોક અને ઓટોવેક્યુમ. અને જો તમારી પાસે પ્રતિકૃતિ પર હોટ સ્ટેન્ડબાય ફીડબેક સક્ષમ છે, તો પણ તમને માસ્ટર પર ઓટોવેક્યુમ લોક પ્રાપ્ત થશે, તે પ્રતિકૃતિમાંથી આવશે. પરંતુ ઓછામાં ઓછા ત્યાં કોઈ તાળાઓ હશે નહીં. અને લોક હશે. અમે ડેટા ફેરફારો વિશે વાત કરી રહ્યા છીએ, તેથી તાળાઓ અહીં એક મહત્વપૂર્ણ મુદ્દો છે. અને જો આ બધું લાંબા, લાંબા સમય માટે છે, તો વધુ અને વધુ વ્યવહારો લૉક કરવામાં આવે છે. તેઓ બીજાને ચોરી શકે છે. અને લોક વૃક્ષો દેખાય છે. મેં સ્નિપેટની લિંક આપી છે. અને આ સમસ્યા ઓટોવેક્યુમ સાથેની સમસ્યા કરતાં વધુ ઝડપથી ધ્યાનપાત્ર બને છે, જે ફક્ત એકઠા થઈ શકે છે.

રિપોર્ટ માટે આભાર! તમે તમારા રિપોર્ટની શરૂઆત એમ કહીને કરી કે તમે ખોટી રીતે પરીક્ષણ કર્યું છે. અમે અમારો વિચાર ચાલુ રાખ્યો કે અમારે એ જ સાધનસામગ્રી લેવાની જરૂર છે, એ જ રીતે આધાર સાથે. ચાલો કહીએ કે અમે વિકાસકર્તાને આધાર આપ્યો. અને તેણે વિનંતીનું પાલન કર્યું. અને તે સારું લાગે છે. પરંતુ તે જીવંત માટે તપાસતો નથી, પરંતુ જીવંત માટે, ઉદાહરણ તરીકે, અમારી પાસે 60-70% નો ભાર છે. અને જો આપણે આ ટ્યુનિંગનો ઉપયોગ કરીએ તો પણ તે ખૂબ સારી રીતે કામ કરતું નથી.

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

જ્યારે આપણે પહેલેથી કચરો પસંદ કરીએ છીએ અને અમારી પાસે છે, ઉદાહરણ તરીકે, કાઢી નાખેલ ધ્વજ

આ તે છે જે ઑટોવેક્યુમ પોસ્ટગ્રેસમાં આપમેળે કરે છે.

ઓહ, તે કરે છે?

ઓટોવેક્યુમ કચરો એકત્ર કરનાર છે.

આભાર!

રિપોર્ટ માટે આભાર! શું ત્યાં કોઈ વિકલ્પ છે કે તરત જ પાર્ટિશનિંગ સાથે ડેટાબેઝને એવી રીતે ડિઝાઈન કરવાનો કે તમામ કચરો મુખ્ય ટેબલથી બાજુમાં ક્યાંક ગંદો થઈ જાય?

અલબત્ત હોય છે.

જો આપણે એવા ટેબલને લૉક કર્યું હોય જેનો ઉપયોગ ન કરવો જોઈએ તો શું આપણી જાતને બચાવવાનું શક્ય છે?

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

સોર્સ: www.habr.com