పరిచయం
హలో. నేను 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