MySQL માં 300 મિલિયન રેકોર્ડ્સને ભૌતિક રીતે કાઢી નાખવાની વાર્તા

પરિચય

નમસ્તે. હું ningenMe, વેબ ડેવલપર છું.

શીર્ષક કહે છે તેમ, મારી વાર્તા એ MySQL માં 300 મિલિયન રેકોર્ડ્સને ભૌતિક રીતે કાઢી નાખવાની વાર્તા છે.

મને આમાં રસ પડ્યો, તેથી મેં રીમાઇન્ડર (સૂચનો) બનાવવાનું નક્કી કર્યું.

ઘર - ચેતવણી

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

સામાન્ય રીતે આ પ્રક્રિયા લગભગ 1 કલાકમાં પૂર્ણ થઈ જાય છે, પરંતુ આ વખતે તે 7 કે 8 કલાક સુધી પૂર્ણ થઈ નથી, અને ચેતવણી પોપ અપ થવાનું બંધ થયું નથી...

કારણ શોધી રહ્યાં છીએ

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

hoge_table | 350'000'000 |

350 મિલિયન રેકોર્ડ. અનુક્રમણિકા યોગ્ય રીતે કામ કરી રહી હોય તેવું લાગતું હતું, માત્ર ખૂબ જ ધીમું.

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

DB

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

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

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

અને પછી હું એક્શનમાં આવ્યો.

કરેક્શન

તર્કમાં ફેરફાર કરવા કરતાં ડેટાબેઝનું કદ ઘટાડવું અને તેની પ્રક્રિયા માટેનો સમય ઓછો કરવો તે વધુ તર્કસંગત હતું.

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

ક્રિયા 1

વિશ્વસનીય બેકઅપ તૈયાર કર્યા પછી, મેં આખરે વિનંતીઓ મોકલવાનું શરૂ કર્યું.

"વિનંતી મોકલી રહ્યું છે"

DELETE FROM hoge_table WHERE create_time <= 'YYYY-MM-DD HH:MM:SS';

"…"

"…"

"હમ્મ... જવાબ નથી. કદાચ પ્રક્રિયામાં લાંબો સમય લાગે છે?" — મેં વિચાર્યું, પરંતુ માત્ર કિસ્સામાં, મેં ગ્રાફના તરફ જોયું અને જોયું કે ડિસ્ક લોડ ખૂબ જ ઝડપથી વધી રહ્યો છે.
"ખતરનાક," મેં ફરીથી વિચાર્યું અને તરત જ વિનંતી બંધ કરી.

ક્રિયા 2

દરેક વસ્તુનું પૃથ્થકરણ કર્યા પછી, મને સમજાયું કે ડેટાની માત્રા એક જ સમયે બધું કાઢી નાખવા માટે ખૂબ મોટી છે.

મેં એક સ્ક્રિપ્ટ લખવાનું નક્કી કર્યું જે લગભગ 1 રેકોર્ડ્સ કાઢી શકે અને તેને લોન્ચ કર્યું.

'હું સ્ક્રિપ્ટ અમલમાં મૂકું છું'

"હવે આ ચોક્કસપણે કામ કરશે," મેં વિચાર્યું.

ક્રિયા 3

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

તેથી મેં જે કરવાનું નક્કી કર્યું તે અહીં છે:

કોષ્ટકની નકલ કરો અને તેનું નામ બદલો

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

| hoge_table     | 350'000'000|
| tmp_hoge_table |  50'000'000|

જો તમે નવા ટેબલને ઉપરના કદના સમાન બનાવો છો, તો ડેટા પ્રોસેસિંગની ઝડપ પણ 1/7 ઝડપી થવી જોઈએ.

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

પ્રદર્શન

"વિનંતી મોકલી રહ્યું છે"

INSERT INTO tmp_hoge_table SELECT FROM hoge_table create_time > 'YYYY-MM-DD HH:MM:SS';

"…"
"…"
"એમ...?"

ક્રિયા 4

મેં વિચાર્યું કે અગાઉનો વિચાર કામ કરશે, પરંતુ દાખલ વિનંતી મોકલ્યા પછી, બહુવિધ ભૂલો દેખાઈ. MySQL ક્ષમાશીલ નથી.

હું પહેલેથી જ એટલો થાકી ગયો હતો કે મેં વિચારવાનું શરૂ કર્યું કે હું હવે આ કરવા માંગતો નથી.

મેં બેસીને વિચાર્યું અને સમજાયું કે કદાચ એક સમય માટે ઘણી બધી ઇન્સર્ટ ક્વેરીઝ હતી...
ડેટાબેસે 1 દિવસમાં પ્રોસેસ કરવી જોઈએ તેટલા ડેટા માટે મેં દાખલ વિનંતી મોકલવાનો પ્રયાસ કર્યો. થયું!

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

ટેબલનું નામ બદલીને

અહીં નસીબ મારી બાજુ પર હતું: બધું સરળતાથી ચાલ્યું.

ચેતવણી ગુમ થઈ ગઈ

બેચ પ્રક્રિયા ઝડપ વધી છે.

પહેલા આ પ્રક્રિયામાં એક કલાક જેટલો સમય લાગતો હતો, હવે તે લગભગ 2 મિનિટ લે છે.

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

સારાંશ

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

શું તમે ડેટાબેઝમાંથી રેકોર્ડ્સ કાઢી નાખતી વખતે ડેટા પ્રતિકૃતિ દરમિયાન લોડ વિશે વિચારો છો? ચાલો MySQL ને ઓવરલોડ ન કરીએ.

જેઓ ડેટાબેઝમાં સારી રીતે વાકેફ છે તેઓ ચોક્કસપણે આવી સમસ્યાનો સામનો કરશે નહીં. તમારા બાકીના માટે, હું આશા રાખું છું કે આ લેખ ઉપયોગી હતો.

વાંચવા બદલ આભાર!

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

સોર્સ: www.habr.com