ప్రియమైన తొలగించండి. నికోలాయ్ సమోఖ్వలోవ్ (Postgres.ai)

సుదూర భవిష్యత్తులో, అనవసరమైన డేటాను స్వయంచాలకంగా తీసివేయడం DBMS [1] యొక్క ముఖ్యమైన పనులలో ఒకటి. ఈలోగా, అనవసరమైన డేటాను తొలగించడం లేదా తక్కువ ఖర్చుతో కూడిన నిల్వ సిస్టమ్‌లకు తరలించడం పట్ల మనమే జాగ్రత్త వహించాలి. మీరు కొన్ని మిలియన్ అడ్డు వరుసలను తొలగించాలని నిర్ణయించుకున్నారని అనుకుందాం. చాలా సులభమైన పని, ప్రత్యేకించి పరిస్థితి తెలిసినట్లయితే మరియు తగిన సూచిక ఉంటే. "టేబుల్1 నుండి తొలగించండి col1 = :విలువ" - ఏది సరళమైనది, సరియైనది?

వీడియోలు:

• నేను మొదటి సంవత్సరం నుండి, అంటే 2007 నుండి హైలోడ్ ప్రోగ్రామ్ కమిటీలో ఉన్నాను.

• మరియు నేను 2005 నుండి పోస్ట్‌గ్రెస్‌తో ఉన్నాను. అనేక ప్రాజెక్టులలో ఉపయోగించారు.

• 2007 నుండి కూడా RuPostges తో సమూహం.

• మేము మీటప్‌లో 2100+ మంది పాల్గొనే స్థాయికి చేరుకున్నాము. ఇది న్యూయార్క్ తర్వాత ప్రపంచంలో రెండవ స్థానంలో ఉంది, శాన్ ఫ్రాన్సిస్కో చాలా కాలం పాటు అధిగమించింది.

• నేను చాలా సంవత్సరాలుగా కాలిఫోర్నియాలో నివసిస్తున్నాను. నేను పెద్ద కంపెనీలతో సహా అమెరికన్ కంపెనీలతో ఎక్కువగా వ్యవహరిస్తాను. వారు Postgres యొక్క క్రియాశీల వినియోగదారులు. మరియు అన్ని రకాల ఆసక్తికరమైన విషయాలు ఉన్నాయి.

https://postgres.ai/ నా కంపెనీ. మేము అభివృద్ధి మందగమనాలను తొలగించే పనులను ఆటోమేట్ చేసే వ్యాపారంలో ఉన్నాము.

మీరు ఏదైనా చేస్తుంటే, కొన్నిసార్లు పోస్ట్‌గ్రెస్ చుట్టూ కొన్ని రకాల ప్లగ్‌లు ఉంటాయి. అడ్మిన్ మీ కోసం టెస్ట్ స్టాండ్‌ని సెటప్ చేయడానికి మీరు వేచి ఉండాలని లేదా DBA మీకు ప్రతిస్పందించే వరకు మీరు వేచి ఉండాలని అనుకుందాం. మరియు మేము అభివృద్ధి, పరీక్ష మరియు పరిపాలన ప్రక్రియలో ఇటువంటి అడ్డంకులను కనుగొంటాము మరియు ఆటోమేషన్ మరియు కొత్త విధానాల సహాయంతో వాటిని తొలగించడానికి ప్రయత్నిస్తాము.

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

నేను ఇటీవల లాస్ ఏంజిల్స్‌లోని VLDBలో ఉన్నాను. డేటాబేస్‌పై ఇదే అతిపెద్ద సదస్సు. మరియు భవిష్యత్తులో DBMS నిల్వ చేయడమే కాకుండా స్వయంచాలకంగా డేటాను తొలగిస్తుందని ఒక నివేదిక ఉంది. ఇది కొత్త అంశం.

జెట్టాబైట్‌ల ప్రపంచంలో మరింత ఎక్కువ డేటా ఉంది - అది 1 పెటాబైట్‌లు. మరియు ఇప్పుడు మన దగ్గర ప్రపంచంలో 000 కంటే ఎక్కువ జెట్టాబైట్‌ల డేటా నిల్వ ఉందని ఇప్పటికే అంచనా వేయబడింది. మరియు వాటిలో ఎక్కువ ఉన్నాయి.

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

మరియు దానితో ఏమి చేయాలి? సహజంగానే దాన్ని తొలగించాల్సిన అవసరం ఉంది. ఈ ఆసక్తికరమైన నివేదిక లింక్ ఇక్కడ ఉంది. కానీ ఇప్పటి వరకు డీబీఎంఎస్‌లో ఇది అమలు కాలేదు.

డబ్బును లెక్కించగలిగే వారికి రెండు విషయాలు కావాలి. మేము తొలగించాలని వారు కోరుకుంటున్నారు, కాబట్టి సాంకేతికంగా మనం దీన్ని చేయగలగాలి.

నేను తరువాత చెప్పబోయేది వాస్తవ పరిస్థితుల సమూహాన్ని కలిగి ఉన్న కొన్ని నైరూప్య పరిస్థితి, అంటే నాకు మరియు చుట్టుపక్కల డేటాబేస్‌లకు చాలా సార్లు, చాలా సంవత్సరాలు ఏమి జరిగిందో దాని సంకలనం. రేక్‌లు ప్రతిచోటా ఉన్నాయి మరియు ప్రతి ఒక్కరూ వాటిపై ఎప్పటికప్పుడు అడుగులు వేస్తారు.

మనకు ఒక బేస్ లేదా అనేక స్థావరాలు పెరుగుతున్నాయని అనుకుందాం. మరియు కొన్ని రికార్డులు స్పష్టంగా చెత్తగా ఉన్నాయి. ఉదాహరణకు, వినియోగదారు అక్కడ ఏదైనా చేయడం ప్రారంభించారు, కానీ దాన్ని పూర్తి చేయలేదు. మరియు కొంత సమయం తరువాత, ఈ అసంపూర్తి ఇకపై నిల్వ చేయబడదని మాకు తెలుసు. అంటే, స్థలాన్ని ఆదా చేయడం, పనితీరును మెరుగుపరచడం మొదలైన వాటి కోసం మేము కొన్ని చెత్త వస్తువులను శుభ్రం చేయాలనుకుంటున్నాము.

సాధారణంగా, పని నిర్దిష్ట విషయాలు, కొన్ని పట్టికలోని నిర్దిష్ట పంక్తుల తొలగింపును ఆటోమేట్ చేయడం.

మరియు మేము అటువంటి అభ్యర్థనను కలిగి ఉన్నాము, ఈ రోజు మనం మాట్లాడతాము, అంటే చెత్త తొలగింపు గురించి.

మేము దీన్ని చేయమని అనుభవజ్ఞుడైన డెవలపర్‌ని అడిగాము. అతను ఈ అభ్యర్థనను తీసుకున్నాడు, దానిని స్వయంగా తనిఖీ చేసాడు - ప్రతిదీ పనిచేస్తుంది. స్టేజింగ్‌లో పరీక్షించబడింది - అంతా బాగానే ఉంది. రోల్ అవుట్ - ప్రతిదీ పనిచేస్తుంది. రోజుకు ఒకసారి మేము దానిని అమలు చేస్తాము - అంతా బాగానే ఉంది.

డేటాబేస్ పెరుగుతుంది మరియు పెరుగుతుంది. రోజువారీ DELETE కొంచెం నెమ్మదిగా పని చేయడం ప్రారంభిస్తుంది.

మేము ఇప్పుడు మార్కెటింగ్ కంపెనీని కలిగి ఉన్నామని మరియు ట్రాఫిక్ చాలా రెట్లు పెద్దదిగా ఉంటుందని మేము అర్థం చేసుకున్నాము, కాబట్టి మేము అనవసరమైన విషయాలను తాత్కాలికంగా పాజ్ చేయాలని నిర్ణయించుకున్నాము. మరియు తిరిగి రావడం మరచిపోండి.

కొన్ని నెలల తర్వాత వారు గుర్తు చేసుకున్నారు. మరియు ఆ డెవలపర్ నిష్క్రమించారు లేదా వేరే పనిలో బిజీగా ఉన్నారు, దానిని తిరిగి ఇవ్వమని మరొకరికి సూచించాడు.

అతను డెవ్‌లో, స్టేజింగ్‌లో చెక్ చేసాడు - అంతా ఓకే. సహజంగానే, మీరు ఇంకా సేకరించిన వాటిని శుభ్రం చేయాలి. అతను ప్రతిదీ తనిఖీ చేసాడు.

తర్వాత ఏమి జరుగును? అప్పుడు ప్రతిదీ మన కోసం విడిపోతుంది. ఇది పడిపోతుంది కాబట్టి ఏదో ఒక సమయంలో ప్రతిదీ పడిపోయింది. అందరూ షాక్‌లో ఉన్నారు, ఏం జరుగుతుందో ఎవరికీ అర్థం కాలేదు. ఆపై విషయం ఈ డిలీట్‌లో ఉందని తేలింది.

ఎక్కడో తేడ జరిగింది? ఏమి తప్పు జరిగి ఉండవచ్చు అనే జాబితా ఇక్కడ ఉంది. వీటిలో ఏది ముఖ్యమైనది?

• ఉదాహరణకు, సమీక్ష లేదు, అంటే DBA నిపుణుడు దానిని చూడలేదు. అతను అనుభవజ్ఞుడైన కంటితో సమస్యను వెంటనే కనుగొంటాడు, అంతేకాకుండా, అతను ఉత్పత్తికి ప్రాప్యతను కలిగి ఉన్నాడు, ఇక్కడ అనేక మిలియన్ లైన్లు పేరుకుపోయాయి.

• బహుశా వారు ఏదో తప్పుగా తనిఖీ చేసి ఉండవచ్చు.

• బహుశా హార్డ్‌వేర్ పాతది కావచ్చు మరియు మీరు ఈ బేస్‌ను అప్‌గ్రేడ్ చేయాలి.

• లేదా డేటాబేస్‌లోనే ఏదో తప్పు ఉంది మరియు మనం పోస్ట్‌గ్రెస్ నుండి MySQLకి మారాలి.

• లేదా ఆపరేషన్‌లో ఏదో లోపం ఉండవచ్చు.

• పని యొక్క సంస్థలో కొన్ని తప్పులు ఉండవచ్చు మరియు మీరు ఎవరినైనా తొలగించి, ఉత్తమ వ్యక్తులను నియమించాలా?

DBA తనిఖీ లేదు. DBA ఉన్నట్లయితే, అతను ఈ అనేక మిలియన్ లైన్లను చూస్తాడు మరియు ఎటువంటి ప్రయోగాలు లేకుండా కూడా ఇలా అంటాడు: "వారు అలా చేయరు." ఈ కోడ్ GitLab, GitHubలో ఉంటే మరియు కోడ్ రివ్యూ ప్రాసెస్ ఉంటుంది మరియు DBA ఆమోదం లేకుండా ఈ ఆపరేషన్ ప్రోడ్‌లో జరిగే అలాంటిదేమీ లేదు, అప్పుడు స్పష్టంగా DBA ఇలా చెబుతుంది: “ఇది చేయలేము. ."

మరియు అతను మీకు డిస్క్ IOతో సమస్యలను కలిగి ఉంటాడని మరియు అన్ని ప్రక్రియలు వెర్రిబారిపోతాయని, తాళాలు ఉండవచ్చు మరియు మీరు కొన్ని నిమిషాల పాటు ఆటోవాక్యూమ్‌ను బ్లాక్ చేస్తారని చెబుతారు, కాబట్టి ఇది మంచిది కాదు.

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

రెండవ తప్పు - వారు తప్పు స్థానంలో తనిఖీ. ప్రోడ్‌లో చాలా జంక్ డేటా పేరుకుపోయిందని మేము తర్వాత చూశాము, అయితే డెవలపర్ ఈ డేటాబేస్‌లో డేటాను సేకరించలేదు మరియు స్టేజింగ్ సమయంలో ఎవరూ ప్రత్యేకంగా ఈ జంక్‌ని సృష్టించలేదు. దీని ప్రకారం, త్వరగా పని చేసే 1 లైన్లు ఉన్నాయి.

మా పరీక్షలు బలహీనంగా ఉన్నాయని మేము అర్థం చేసుకున్నాము, అంటే, నిర్మించిన ప్రక్రియ సమస్యలను పట్టుకోదు. తగిన DB ప్రయోగం నిర్వహించబడలేదు.

ఆదర్శవంతమైన ప్రయోగం అదే పరికరాలపై ఉత్తమంగా నిర్వహించబడుతుంది. ఒకే పరికరాలలో దీన్ని చేయడం ఎల్లప్పుడూ సాధ్యం కాదు, కానీ ఇది డేటాబేస్ యొక్క పూర్తి-పరిమాణ కాపీగా ఉండటం చాలా ముఖ్యం. ఇది నేను చాలా సంవత్సరాలుగా బోధిస్తున్నాను. మరియు ఒక సంవత్సరం క్రితం నేను దీని గురించి మాట్లాడాను, మీరు YouTubeలో అన్నింటినీ చూడవచ్చు.

బహుశా మా పరికరాలు చెడ్డవి? చూస్తే జాప్యం ఎగిరిపోయింది. వినియోగం 100% అని మేము చూశాము. అయితే, ఇవి ఆధునిక NVMe డ్రైవ్‌లు అయితే, అది మాకు చాలా సులభంగా ఉంటుంది. మరియు బహుశా మేము దాని నుండి పడుకోలేము.

మీకు మేఘాలు ఉంటే, అప్‌గ్రేడ్ చేయడం అక్కడ సులభంగా జరుగుతుంది. కొత్త హార్డ్‌వేర్‌పై కొత్త ప్రతిరూపాలను పెంచారు. మార్చు. మరియు అంతా బాగానే ఉంది. చాలా సులభం.

చిన్న డిస్కులను ఎలాగైనా తాకడం సాధ్యమేనా? మరియు ఇక్కడ, కేవలం DBA సహాయంతో, మేము చెక్‌పాయింట్ ట్యూనింగ్ అనే నిర్దిష్ట అంశంలోకి ప్రవేశిస్తాము. మాకు చెక్‌పాయింట్ ట్యూనింగ్ లేదని తేలింది.

చెక్‌పాయింట్ అంటే ఏమిటి? ఇది ఏదైనా DBMSలో ఉంది. మీరు మెమరీలో డేటాను మార్చినప్పుడు, అది వెంటనే డిస్కుకు వ్రాయబడదు. డేటా మారిన సమాచారం ముందుగా రైట్-ఎహెడ్ లాగ్‌కు వ్రాయబడుతుంది. మరియు ఏదో ఒక సమయంలో, DBMS నిజమైన పేజీలను డిస్క్‌కి డంప్ చేయడానికి సమయం ఆసన్నమైందని నిర్ణయించింది, తద్వారా మనకు వైఫల్యం ఉంటే, మనం తక్కువ రీడో చేయగలము. ఇది ఒక బొమ్మ లాంటిది. మేము చంపబడితే, మేము చివరి చెక్‌పాయింట్ నుండి ఆటను ప్రారంభిస్తాము. మరియు అన్ని DBMS దీన్ని అమలు చేస్తుంది.

పోస్ట్‌గ్రెస్‌లోని సెట్టింగ్‌లు వెనుకబడి ఉన్నాయి. అవి 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 గిగాబైట్లు. మరియు మేము ఒక నిర్దిష్ట వ్యవస్థ యొక్క ప్రవర్తనను పరిశీలిస్తాము. ఇక్కడ పరికరాలు ఉత్పత్తిలో లాగా ఉండాలని స్పష్టంగా తెలుస్తుంది. మీరు తప్పనిసరిగా ఒకే డిస్క్‌లు, అదే మొత్తంలో మెమరీ మరియు అదే పోస్ట్‌గ్రెస్ సెట్టింగ్‌లను కలిగి ఉండాలి.

మరియు ఈ విధంగా మేము మా సిస్టమ్‌ను మార్పిడి చేస్తాము మరియు చెడ్డ ద్రవ్యరాశి తొలగించబడినప్పుడు DBMS ఎలా ప్రవర్తిస్తుందో, అది ఎలా చెక్‌పాయింట్ చేస్తుందో మాకు తెలుసు.

రష్యన్‌లో చెక్‌పాయింట్‌లు చెక్‌పాయింట్‌లు.

ఉదాహరణ: సూచిక ద్వారా అనేక మిలియన్ అడ్డు వరుసలను తొలగించండి, అడ్డు వరుసలు పేజీలలో "చెదురుగా" ఉన్నాయి.

ఇక్కడ ఒక ఉదాహరణ ఉంది. ఇది కొంత ఆధారం. మరియు max_wal_size కోసం 1 గిగాబైట్ డిఫాల్ట్ సెట్టింగ్‌తో, మా డిస్క్‌లు రికార్డింగ్ కోసం షెల్ఫ్‌కు వెళ్తాయని చాలా స్పష్టంగా తెలుస్తుంది. ఈ చిత్రం చాలా జబ్బుపడిన రోగి యొక్క సాధారణ లక్షణం, అంటే, అతను నిజంగా చెడుగా భావించాడు. మరియు ఒకే ఒక్క ఆపరేషన్ ఉంది, అనేక మిలియన్ లైన్ల తొలగింపు మాత్రమే ఉంది.

అటువంటి ఆపరేషన్ ప్రోడ్‌లో అనుమతించబడితే, మేము కేవలం పడుకుంటాము, ఎందుకంటే రెజిమెంట్‌లో ఒక డిలీట్ మమ్మల్ని చంపేస్తుందని స్పష్టంగా తెలుస్తుంది.

ఇంకా, 16 గిగాబైట్లు ఎక్కడ ఉంటే, దంతాలు ఇప్పటికే పోయాయని స్పష్టమవుతుంది. దంతాలు ఇప్పటికే మెరుగ్గా ఉన్నాయి, అంటే, మేము పైకప్పుపై తలక్రిందులు చేస్తున్నాము, కానీ అంత చెడ్డది కాదు. అక్కడ కొంత స్వేచ్ఛ ఉండేది. కుడివైపు రికార్డు ఉంది. మరియు కార్యకలాపాల సంఖ్య - రెండవ గ్రాఫ్. మరియు 16 గిగాబైట్‌లు ఉన్నప్పుడు మనం ఇప్పటికే కొంచెం తేలికగా శ్వాసిస్తున్నామని స్పష్టమవుతుంది.

మరియు 64 గిగాబైట్‌లు పూర్తిగా మెరుగ్గా మారినట్లు చూడవచ్చు. ఇప్పటికే దంతాలు ఉచ్ఛరిస్తారు, ఇతర కార్యకలాపాలను తట్టుకుని, డిస్క్తో ఏదైనా చేయటానికి మరిన్ని అవకాశాలు ఉన్నాయి.

ఎందుకు అలా

నేను వివరాల్లోకి కొంచెం డైవ్ చేస్తాను, కానీ ఈ టాపిక్, చెక్‌పాయింట్ ట్యూనింగ్‌ను ఎలా నిర్వహించాలో, మొత్తం నివేదికకు దారితీయవచ్చు, కాబట్టి నేను ఎక్కువ లోడ్ చేయను, కానీ ఏ ఇబ్బందులు ఉన్నాయో కొంచెం వివరిస్తాను.

చెక్‌పాయింట్ చాలా తరచుగా జరిగితే, మరియు మేము మా పంక్తులను వరుసగా కాకుండా, సూచిక ద్వారా కనుగొంటాము, ఇది మంచిది, ఎందుకంటే మేము మొత్తం పట్టికను తొలగించనందున, మొదట మేము మొదటి పేజీని తాకినట్లు జరగవచ్చు, ఆపై వెయ్యి, ఆపై మొదటిదానికి తిరిగి వచ్చింది. మరియు మొదటి పేజీకి ఈ సందర్శనల మధ్య, చెక్‌పాయింట్ ఇప్పటికే దానిని డిస్క్‌లో సేవ్ చేసి ఉంటే, అది దాన్ని మళ్లీ సేవ్ చేస్తుంది, ఎందుకంటే మేము దానిని రెండవసారి మురికిగా మార్చాము.

మరియు మేము చెక్‌పాయింట్‌ని చాలాసార్లు సేవ్ చేయమని బలవంతం చేస్తాము. అతనికి అనవసరమైన ఆపరేషన్లు ఎలా ఉంటాయి.

అయితే అదంతా కాదు. పోస్ట్‌గ్రెస్‌లో పేజీలు 8 కిలోబైట్‌లు మరియు లైనక్స్‌లో 4 కిలోబైట్‌లు. మరియు full_page_writes సెట్టింగ్ ఉంది. ఇది డిఫాల్ట్‌గా ప్రారంభించబడింది. మరియు ఇది సరైనది, ఎందుకంటే మనం దీన్ని ఆఫ్ చేస్తే, అది క్రాష్ అయితే పేజీలో సగం మాత్రమే సేవ్ చేయబడే ప్రమాదం ఉంది.

ఫార్వార్డ్ లాగ్ యొక్క WALకి వ్రాయడం యొక్క ప్రవర్తన ఏమిటంటే, మనకు చెక్‌పాయింట్ ఉన్నప్పుడు మరియు మేము మొదటి సారి పేజీని మార్చినప్పుడు, మొత్తం పేజీ, అంటే మొత్తం 8 కిలోబైట్‌లు, ఫార్వర్డ్ లాగ్‌లోకి వస్తాయి, అయినప్పటికీ మేము మాత్రమే మార్చాము. లైన్, దీని బరువు 100 బైట్లు . మరియు మేము మొత్తం పేజీని వ్రాయవలసి ఉంటుంది.

తదుపరి మార్పులలో నిర్దిష్ట టుపుల్ మాత్రమే ఉంటుంది, కానీ మొదటి సారి మేము ప్రతిదీ వ్రాస్తాము.

మరియు, తదనుగుణంగా, చెక్‌పాయింట్ మళ్లీ జరిగితే, మేము మొదటి నుండి ప్రతిదీ ప్రారంభించి, మొత్తం పేజీని నెట్టాలి. తరచుగా చెక్‌పాయింట్‌లతో, మేము అదే పేజీల ద్వారా నడిచినప్పుడు, full_page_writes = on దాని కంటే ఎక్కువగా ఉంటుంది, అనగా మేము మరింత WALని ఉత్పత్తి చేస్తాము. మరిన్ని ప్రతిరూపాలకు, ఆర్కైవ్‌కు, డిస్క్‌కి పంపబడతాయి.

మరియు, తదనుగుణంగా, మాకు రెండు రిడెండెన్సీలు ఉన్నాయి.

మేము max_wal_sizeని పెంచినట్లయితే, మేము చెక్‌పాయింట్ మరియు వాల్ రైటర్ రెండింటికీ సులభతరం చేస్తాము. మరియు అది గొప్పది.

టెరాబైట్ పెట్టుకుని బతుకుదాం. దాని గురించి చెడు ఏమిటి? ఇది చెడ్డది, ఎందుకంటే విఫలమైతే, మేము గంటలు ఎక్కుతాము, ఎందుకంటే చెక్‌పాయింట్ చాలా కాలం క్రితం ఉంది మరియు ఇప్పటికే చాలా మారిపోయింది. మరియు మనం ఇవన్నీ REDO చెయ్యాలి. కాబట్టి మేము రెండవ ప్రయోగాల శ్రేణిని చేస్తాము.

మేము ఒక ఆపరేషన్ చేస్తాము మరియు చెక్‌పాయింట్ ఎప్పుడు పూర్తవుతుందో చూస్తాము, మేము ఉద్దేశపూర్వకంగా -9 పోస్ట్‌గ్రెస్‌లను చంపుతాము.

మరియు ఆ తర్వాత మేము దీన్ని మళ్లీ ప్రారంభించాము మరియు ఈ సామగ్రిపై ఎంతకాలం పెరుగుతుందో చూడండి, అంటే ఈ చెడు పరిస్థితిలో ఇది ఎంతవరకు పునరావృతమవుతుంది.

పరిస్థితి చెడ్డదని నేను రెండుసార్లు గమనించాను. ముందుగా, చెక్‌పాయింట్ ముగిసేలోపు మేము క్రాష్ అయ్యాము, కాబట్టి మనం కోల్పోవాల్సింది చాలా ఉంది. మరియు రెండవది, మేము భారీ ఆపరేషన్ చేసాము. మరియు చెక్‌పాయింట్‌లు గడువు ముగిసినట్లయితే, చాలా మటుకు, చివరి చెక్‌పాయింట్ నుండి తక్కువ WAL ఉత్పత్తి అవుతుంది. అంటే, ఇది డబుల్ లూజర్.

మేము వివిధ max_wal_size పరిమాణాల కోసం అటువంటి పరిస్థితిని కొలుస్తాము మరియు max_wal_size 64 గిగాబైట్‌లు అయితే, డబుల్ చెత్త సందర్భంలో మేము 10 నిమిషాలు ఎక్కుతామని అర్థం చేసుకుంటాము. మరియు అది మనకు సరిపోతుందా లేదా అని మేము ఆలోచిస్తాము. ఇది వ్యాపార ప్రశ్న. వ్యాపార నిర్ణయాలకు బాధ్యత వహించే వారికి ఈ చిత్రాన్ని చూపించి, “సమస్య వచ్చినప్పుడు మనం ఎంతసేపు పడుకోవచ్చు? మేము 3-5 నిమిషాలు చెత్త పరిస్థితిలో పడుకోగలమా? మరియు మీరు ఒక నిర్ణయం తీసుకోండి.

మరియు ఇక్కడ ఒక ఆసక్తికరమైన అంశం ఉంది. సమావేశంలో పాత్రోని గురించి మాకు కొన్ని నివేదికలు ఉన్నాయి. మరియు బహుశా మీరు దానిని ఉపయోగిస్తున్నారు. పోస్ట్‌గ్రెస్‌కి ఇది ఆటోఫెయిల్‌ఓవర్. GitLab మరియు Data Egret దీని గురించి మాట్లాడాయి.

మరియు మీరు 30 సెకన్లలో వచ్చే ఆటోఫెయిల్‌ఓవర్‌ని కలిగి ఉంటే, మేము 10 నిమిషాల పాటు పడుకోవచ్చా? ఎందుకంటే మేము ఈ సమయానికి ప్రతిరూపానికి మారతాము మరియు ప్రతిదీ బాగానే ఉంటుంది. ఇది ఒక మూట్ పాయింట్. నాకు స్పష్టమైన సమాధానం తెలియదు. ఈ అంశం క్రాష్ రికవరీకి సంబంధించినది మాత్రమే కాదని నేను భావిస్తున్నాను.

వైఫల్యం తర్వాత మనం చాలా కాలం కోలుకుంటే, అనేక ఇతర పరిస్థితులలో మనకు అసౌకర్యంగా ఉంటుంది. ఉదాహరణకు, అదే ప్రయోగాలలో, మనం ఏదైనా చేసినప్పుడు మరియు కొన్నిసార్లు 10 నిమిషాలు వేచి ఉండాలి.

మేము ఆటోఫెయిల్‌ఓవర్‌ని కలిగి ఉన్నప్పటికీ నేను ఇంకా ఎక్కువ దూరం వెళ్లను. నియమం ప్రకారం, 64, 100 గిగాబైట్ల వంటి విలువలు మంచి విలువలు. కొన్నిసార్లు తక్కువ ఎంచుకోవడం కూడా విలువైనది. సాధారణంగా, ఇది ఒక సూక్ష్మ శాస్త్రం.

పునరావృత్తులు చేయడానికి, ఉదాహరణకు, max_wal_size =1, 8, మీరు మాస్ ఆపరేషన్‌ను చాలాసార్లు పునరావృతం చేయాలి. నువ్వు సాధించావు. మరియు అదే ఆధారంగా మీరు దీన్ని మళ్లీ చేయాలనుకుంటున్నారు, కానీ మీరు ఇప్పటికే ప్రతిదీ తొలగించారు. ఏం చేయాలి?

నేను మా పరిష్కారం గురించి తరువాత మాట్లాడతాను, అటువంటి పరిస్థితుల్లో మళ్ళించడానికి మనం ఏమి చేస్తాము. మరియు ఇది చాలా సరైన విధానం.

కానీ ఈ సందర్భంలో, మేము అదృష్టవంతులం. ఇక్కడ "ప్రారంభం, తొలగించు, రోల్‌బ్యాక్" అని చెప్పినట్లుగా, మేము తొలగించడాన్ని పునరావృతం చేయవచ్చు. అంటే, మనం దానిని మనమే రద్దు చేసుకున్నట్లయితే, మేము దానిని పునరావృతం చేయవచ్చు. మరియు భౌతికంగా మీ వద్ద డేటా అదే స్థలంలో ఉంటుంది. మీకు ఉబ్బరం కూడా రాదు. మీరు అటువంటి DELETEల ద్వారా పునరావృతం చేయవచ్చు.

మీకు సరిగ్గా డేటాబేస్ ల్యాబ్‌లు లేకపోయినా, ROLLBACKతో ఈ తొలగింపు చెక్‌పాయింట్ ట్యూనింగ్ కోసం అనువైనది.

మేము "i" అనే ఒక నిలువు వరుసతో ప్లేట్‌ను తయారు చేసాము. పోస్ట్‌గ్రెస్‌లో యుటిలిటీ కాలమ్‌లు ఉన్నాయి. ప్రత్యేకంగా కోరితే తప్ప అవి కనిపించవు. అవి: ctid, xmid, xmax.

Ctid అనేది భౌతిక చిరునామా. జీరో పేజీ, పేజీలోని మొదటి టుపుల్.

రూల్‌బ్యాక్ తర్వాత టుపుల్ అదే స్థానంలో ఉన్నట్లు చూడవచ్చు. అంటే, మనం మళ్లీ ప్రయత్నించవచ్చు, అది అదే విధంగా ప్రవర్తిస్తుంది. ఇది ప్రధాన విషయం.

Xmax అనేది టుపుల్ యొక్క మరణ సమయం. ఇది స్టాంప్ చేయబడింది, అయితే లావాదేవీని వెనక్కి తీసుకున్నట్లు పోస్ట్‌గ్రెస్‌కు తెలుసు, కాబట్టి అది 0 అయినా లేదా రోల్డ్ బ్యాక్ లావాదేవీ అయినా పర్వాలేదు. DELETE ద్వారా పునరావృతం చేయడం మరియు సిస్టమ్ ప్రవర్తన యొక్క బల్క్ ఆపరేషన్‌లను తనిఖీ చేయడం సాధ్యమవుతుందని ఇది సూచిస్తుంది. మీరు పేదల కోసం డేటాబేస్ ల్యాబ్‌లను తయారు చేయవచ్చు.

ఇది ప్రోగ్రామర్ల గురించి. DBA గురించి కూడా, వారు ఎల్లప్పుడూ దీని కోసం ప్రోగ్రామర్‌లను తిట్టారు: "మీరు ఎందుకు ఇంత సుదీర్ఘమైన మరియు కష్టమైన ఆపరేషన్లు చేస్తున్నారు?". ఇది పూర్తిగా భిన్నమైన లంబ అంశం. గతంలో పరిపాలన ఉంది, ఇప్పుడు అభివృద్ధి ఉంటుంది.

సహజంగానే, మేము ముక్కలుగా విడిపోలేదు. అది స్పష్టమైనది. లక్షలాది పంక్తుల కుప్ప కోసం అటువంటి DELETEని భాగాలుగా విభజించకుండా ఉండటం అసాధ్యం. ఇది 20 నిమిషాలు చేయబడుతుంది, మరియు ప్రతిదీ పడుకుని ఉంటుంది. కానీ, దురదృష్టవశాత్తు, అనుభవజ్ఞులైన డెవలపర్లు కూడా చాలా పెద్ద కంపెనీలలో కూడా తప్పులు చేస్తారు.

విచ్ఛిన్నం చేయడం ఎందుకు ముఖ్యం?

• డిస్క్ గట్టిగా ఉందని మనం చూస్తే, దాన్ని నెమ్మదిద్దాం. మరియు మనం విచ్ఛిన్నమైతే, మేము పాజ్‌లను జోడించవచ్చు, థ్రోట్లింగ్‌ను నెమ్మది చేయవచ్చు.

• మరియు మేము ఇతరులను ఎక్కువ కాలం నిరోధించము. కొన్ని సందర్భాల్లో ఇది పట్టింపు లేదు, మీరు ఎవరూ పని చేయని నిజమైన చెత్తను తొలగిస్తే, చాలా మటుకు మీరు ఆటోవాక్యూమ్ పనిని మినహాయించి ఎవరినీ నిరోధించలేరు, ఎందుకంటే ఇది లావాదేవీ పూర్తయ్యే వరకు వేచి ఉంటుంది. కానీ మీరు వేరొకరు అభ్యర్థించగల దాన్ని తీసివేస్తే, వారు బ్లాక్ చేయబడతారు, ఒక రకమైన చైన్ రియాక్షన్ ఉంటుంది. వెబ్‌సైట్‌లు మరియు మొబైల్ అప్లికేషన్‌లలో సుదీర్ఘ లావాదేవీలను నివారించాలి.

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

ఇది ఆసక్తికరంగా ఉంది. డెవలపర్లు ఇలా అడగడం నేను తరచుగా చూస్తాను: "నేను ఏ ప్యాక్ పరిమాణాన్ని ఎంచుకోవాలి?".

పెద్ద బండిల్ పరిమాణం, లావాదేవీ ఓవర్‌హెడ్ చిన్నది, అంటే లావాదేవీల నుండి అదనపు ఓవర్‌హెడ్ అని స్పష్టంగా తెలుస్తుంది. కానీ అదే సమయంలో, ఈ లావాదేవీకి సమయం పెరుగుతుంది.

నాకు చాలా సులభమైన నియమం ఉంది: మీకు వీలైనంత ఎక్కువ తీసుకోండి, కానీ సెకనుకు ఎక్జిక్యూటబుల్స్‌పైకి వెళ్లవద్దు.

ఒక సెకను ఎందుకు? వివరణ చాలా సులభం మరియు అందరికీ అర్థమయ్యేలా ఉంది, సాంకేతికత లేని వ్యక్తులకు కూడా. మేము ప్రతిచర్యను చూస్తాము. 50 మిల్లీసెకన్లు తీసుకుందాం. ఏదైనా మారినట్లయితే, మన కన్ను ప్రతిస్పందిస్తుంది. తక్కువ ఉంటే, మరింత కష్టం. 100 మిల్లీసెకన్ల తర్వాత ఏదైనా ప్రతిస్పందిస్తే, ఉదాహరణకు, మీరు మౌస్‌ని క్లిక్ చేసి, 100 మిల్లీసెకన్ల తర్వాత అది మీకు సమాధానం ఇచ్చినట్లయితే, మీరు ఇప్పటికే ఈ స్వల్ప ఆలస్యాన్ని అనుభవిస్తున్నారు. సెకను ఇప్పటికే బ్రేక్‌లుగా గుర్తించబడింది.

దీని ప్రకారం, మేము మా సామూహిక కార్యకలాపాలను 10-సెకన్ల పేలుళ్లుగా విచ్ఛిన్నం చేస్తే, మనం ఎవరినైనా నిరోధించే ప్రమాదం ఉంది. మరియు ఇది కొన్ని సెకన్ల పాటు పని చేస్తుంది మరియు ప్రజలు దీనిని ఇప్పటికే గమనిస్తారు. అందువల్ల, నేను సెకను కంటే ఎక్కువ చేయకూడదని ఇష్టపడతాను. కానీ అదే సమయంలో, దానిని చాలా చక్కగా విచ్ఛిన్నం చేయవద్దు, ఎందుకంటే లావాదేవీ ఓవర్ హెడ్ గుర్తించదగినదిగా ఉంటుంది. బేస్ కష్టంగా ఉంటుంది మరియు ఇతర విభిన్న సమస్యలు తలెత్తవచ్చు.

మేము ప్యాక్ యొక్క పరిమాణాన్ని ఎంచుకుంటాము. ప్రతి సందర్భంలో, మేము దానిని భిన్నంగా చేయవచ్చు. స్వయంచాలకంగా చేయవచ్చు. మరియు మేము ఒక ప్యాక్ యొక్క ప్రాసెసింగ్ యొక్క సామర్థ్యాన్ని ఒప్పించాము. అంటే, మేము ఒక ప్యాక్‌ని డిలీట్ చేస్తాము లేదా అప్‌డేట్ చేస్తాము.

చెప్పాలంటే, నేను మాట్లాడుతున్నదంతా డిలీట్ గురించి మాత్రమే కాదు. మీరు ఊహించినట్లుగా, ఇవి డేటాపై ఏవైనా భారీ కార్యకలాపాలు.

మరియు ప్రణాళిక అద్భుతమైనదని మేము చూస్తాము. మీరు ఇండెక్స్ స్కాన్‌ను చూడవచ్చు, ఇండెక్స్ మాత్రమే స్కాన్ చేయడం ఇంకా మంచిది. మరియు మేము చిన్న మొత్తంలో డేటాను కలిగి ఉన్నాము. మరియు సెకను కంటే తక్కువ నెరవేరుతుంది. సూపర్.

మరియు మేము ఇంకా ఎటువంటి అధోకరణం లేదని నిర్ధారించుకోవాలి. మొదటి ప్యాక్‌లు త్వరగా పని చేస్తాయి, ఆపై అది అధ్వాన్నంగా, అధ్వాన్నంగా మరియు అధ్వాన్నంగా మారుతుంది. ప్రక్రియ మీరు చాలా పరీక్షించవలసి ఉంటుంది. డేటాబేస్ ల్యాబ్‌లు సరిగ్గా దీని కోసమే.

మరియు మేము ఇంకా ఏదైనా సిద్ధం చేయాలి, తద్వారా ఉత్పత్తిలో దీన్ని సరిగ్గా అనుసరించడానికి ఇది అనుమతిస్తుంది. ఉదాహరణకు, మనం లాగ్‌లో సమయాన్ని వ్రాయవచ్చు, మనం ఇప్పుడు ఎక్కడ ఉన్నాము మరియు ఇప్పుడు మనం ఎవరిని తొలగించాము అని వ్రాయవచ్చు. మరియు ఇది తరువాత ఏమి జరుగుతుందో అర్థం చేసుకోవడానికి అనుమతిస్తుంది. మరియు ఏదైనా తప్పు జరిగితే, త్వరగా సమస్యను కనుగొనండి.

మేము అభ్యర్థనల సామర్థ్యాన్ని తనిఖీ చేయవలసి వస్తే మరియు మేము చాలాసార్లు పునరావృతం చేయవలసి వస్తే, అప్పుడు తోటి బోట్ వంటి విషయం ఉంది. అతను ఇప్పటికే సిద్ధంగా ఉన్నాడు. ఇది రోజువారీ డజన్ల కొద్దీ డెవలపర్‌లచే ఉపయోగించబడుతుంది. మరియు మీ స్వంత కాపీని 30 సెకన్లలో అభ్యర్థనపై భారీ టెరాబైట్ డేటాబేస్ ఎలా ఇవ్వాలో అతనికి తెలుసు. మరియు మీరు అక్కడ ఏదైనా తొలగించవచ్చు మరియు రీసెట్ అని చెప్పవచ్చు మరియు దానిని మళ్లీ తొలగించవచ్చు. మీరు ఈ విధంగా ప్రయోగాలు చేయవచ్చు. నేను ఈ విషయానికి భవిష్యత్తును చూస్తున్నాను. మరియు మేము ఇప్పటికే చేస్తున్నాము.

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

విభజన వ్యూహాలు ఏమిటి? ప్యాక్‌లోని డెవలపర్‌లు ఉపయోగిస్తున్న 3 విభిన్న విభజన వ్యూహాలను నేను చూస్తున్నాను.

మొదటిది చాలా సులభం. మా వద్ద సంఖ్యా ID ఉంది. మరియు దానిని వేర్వేరు విరామాలుగా విభజించి, దానితో పని చేద్దాం. ప్రతికూలత స్పష్టంగా ఉంది. మొదటి సెగ్‌మెంట్‌లో, మనకు 100 లైన్ల నిజమైన చెత్త ఉండవచ్చు, రెండవ 5 లైన్‌లలో లేదా అస్సలు ఉండకపోవచ్చు లేదా మొత్తం 1 లైన్‌లు చెత్తగా మారతాయి. చాలా అసమాన పని, కానీ అది విచ్ఛిన్నం సులభం. మాగ్జిమమ్ ఐడీని తీసుకుని పగలగొట్టారు. ఇది అమాయక విధానం.

రెండవ వ్యూహం సమతుల్య విధానం. ఇది గిట్లాబ్‌లో ఉపయోగించబడుతుంది. వాళ్ళు టేబుల్ తీసుకుని స్కాన్ చేశారు. మేము ID ప్యాక్‌ల సరిహద్దులను కనుగొన్నాము, తద్వారా ప్రతి ప్యాక్‌లో ఖచ్చితంగా 10 రికార్డ్‌లు ఉన్నాయి. మరియు వాటిని క్యూలో ఉంచండి. ఆపై మేము ప్రాసెస్ చేస్తాము. మీరు దీన్ని బహుళ థ్రెడ్‌లలో చేయవచ్చు.

మొదటి వ్యూహంలో, మార్గం ద్వారా, మీరు దీన్ని అనేక థ్రెడ్‌లలో చేయవచ్చు. ఇది కష్టం కాదు.

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

కానీ ఒక చల్లని మరియు మెరుగైన విధానం ఉంది. ఇది మూడో వ్యూహం. మరియు సాధ్యమైనప్పుడు, దానిని ఎంచుకోవడం మంచిది. మేము దీన్ని ప్రత్యేక సూచిక ఆధారంగా చేస్తాము. ఈ సందర్భంలో, ఇది చాలావరకు మన చెత్త పరిస్థితి మరియు ID ప్రకారం సూచికగా ఉంటుంది. మేము IDని చేర్చుతాము, కనుక ఇది సూచిక మాత్రమే స్కాన్ చేయబడుతుంది, తద్వారా మేము కుప్పకు వెళ్లము.

సాధారణంగా, ఇండెక్స్ స్కాన్ కంటే ఇండెక్స్ మాత్రమే స్కాన్ వేగంగా ఉంటుంది.

మరియు మేము తొలగించాలనుకుంటున్న మా IDలను త్వరగా కనుగొంటాము. BATCH_SIZE మేము ముందుగానే ఎంచుకుంటాము. మరియు మేము వాటిని పొందడం మాత్రమే కాదు, మేము వాటిని ప్రత్యేక మార్గంలో పొందుతాము మరియు వెంటనే వాటిని హ్యాక్ చేస్తాము. కానీ మేము లాక్ చేస్తున్నాము కాబట్టి అవి ఇప్పటికే లాక్ చేయబడి ఉంటే, మేము వాటిని లాక్ చేయకుండా, ముందుకు వెళ్లి తదుపరి వాటిని తీసుకుంటాము. ఇది అప్‌డేట్ స్కిప్ లాక్ కోసం ఉద్దేశించబడింది. పోస్ట్‌గ్రెస్ యొక్క ఈ సూపర్ ఫీచర్ మనకు కావాలంటే అనేక థ్రెడ్‌లలో పని చేయడానికి అనుమతిస్తుంది. ఇది ఒక ప్రవాహంలో సాధ్యమవుతుంది. మరియు ఇక్కడ ఒక CTE ఉంది - ఇది ఒక అభ్యర్థన. మరియు మేము ఈ CTE యొక్క రెండవ అంతస్తులో నిజమైన తొలగింపును కలిగి ఉన్నాము - returning *. మీరు idని తిరిగి ఇవ్వవచ్చు, కానీ ఇది మంచిది *ప్రతి లైన్‌లో మీకు ఎక్కువ డేటా లేకపోతే.

మనకు అది ఎందుకు అవసరం? ఇది మేము తిరిగి నివేదించాల్సిన అవసరం ఉంది. మేము ఇప్పుడు చాలా పంక్తులను తొలగించాము. మరియు మేము ID ద్వారా లేదా ఇలా create_at ద్వారా సరిహద్దులను కలిగి ఉన్నాము. మీరు నిమి, గరిష్టంగా చేయవచ్చు. ఇంకేదో చేయవచ్చు. మీరు ఇక్కడ చాలా విషయాలు చేయవచ్చు. మరియు ఇది పర్యవేక్షణ కోసం చాలా సౌకర్యవంతంగా ఉంటుంది.

ఇండెక్స్ గురించి మరొక గమనిక ఉంది. ఈ పని కోసం మాకు ప్రత్యేక సూచిక అవసరమని మేము నిర్ణయించుకుంటే, అది కుప్ప మాత్రమే టుపుల్స్ నవీకరణలను పాడు చేయదని మేము నిర్ధారించుకోవాలి. అంటే, Postgres అటువంటి గణాంకాలను కలిగి ఉంది. ఇది మీ టేబుల్ కోసం pg_stat_user_tablesలో చూడవచ్చు. హాట్ అప్‌డేట్‌లు ఉపయోగించబడుతున్నాయా లేదా అని మీరు చూడవచ్చు.

మీ కొత్త సూచిక వాటిని తగ్గించగల సందర్భాలు ఉన్నాయి. మరియు మీరు ఇప్పటికే పని చేస్తున్న అన్ని ఇతర నవీకరణలను కలిగి ఉన్నారు, వేగాన్ని తగ్గించండి. ఇండెక్స్ కనిపించినందున మాత్రమే కాదు (ప్రతి ఇండెక్స్ నవీకరణలను కొద్దిగా తగ్గిస్తుంది, కానీ కొద్దిగా), కానీ ఇక్కడ అది ఇప్పటికీ దానిని నాశనం చేస్తుంది. మరియు ఈ పట్టిక కోసం ప్రత్యేక ఆప్టిమైజేషన్ చేయడం అసాధ్యం. ఇది కొన్నిసార్లు జరుగుతుంది. ఇది చాలా తక్కువ మందికి గుర్తుండే సూక్ష్మం. మరియు ఈ రేక్ అడుగు పెట్టడం సులభం. కొన్నిసార్లు మీరు మరొక వైపు నుండి ఒక విధానాన్ని కనుగొనవలసి ఉంటుంది మరియు ఇప్పటికీ ఈ కొత్త సూచిక లేకుండా చేయవలసి ఉంటుంది, లేదా మరొక సూచికను తయారు చేయండి లేదా మరొక విధంగా, ఉదాహరణకు, మీరు రెండవ పద్ధతిని ఉపయోగించవచ్చు.

కానీ ఇది చాలా సరైన వ్యూహం, బ్యాచ్‌లుగా విభజించడం మరియు ఒక అభ్యర్థనతో బ్యాచ్‌లలో షూట్ చేయడం, కొంచెం తొలగించడం మొదలైనవి.

సుదీర్ఘ లావాదేవీలు https://gitlab.com/snippets/1890447

నిరోధించబడిన ఆటోవాక్యూమ్ - https://gitlab.com/snippets/1889668

నిరోధించే సమస్య - https://gitlab.com/snippets/1890428

తప్పు #5 పెద్దది. Okmeter నుండి Nikolai Postgres పర్యవేక్షణ గురించి మాట్లాడారు. ఐడియల్ పోస్ట్‌గ్రెస్ పర్యవేక్షణ, దురదృష్టవశాత్తు, ఉనికిలో లేదు. కొన్ని దగ్గరగా ఉన్నాయి, కొన్ని దూరంగా ఉన్నాయి. ఓక్‌మీటర్ పరిపూర్ణంగా ఉండటానికి దగ్గరగా ఉంది, కానీ చాలా లేదు మరియు జోడించాల్సిన అవసరం ఉంది. దీనికి మీరు సిద్ధంగా ఉండాలి.

ఉదాహరణకు, చనిపోయిన టుపుల్స్ ఉత్తమంగా పర్యవేక్షించబడతాయి. మీరు పట్టికలో చనిపోయిన విషయాలు చాలా ఉంటే, అప్పుడు ఏదో తప్పు. ఇప్పుడే స్పందించడం మంచిది, లేకపోతే అధోకరణం ఉండవచ్చు, మనం పడుకోవచ్చు. అది జరుగుతుంది.

పెద్ద IO ఉంటే, ఇది మంచిది కాదని స్పష్టమవుతుంది.

సుదీర్ఘ లావాదేవీలు కూడా. OLTPలో సుదీర్ఘ లావాదేవీలను అనుమతించకూడదు. మరియు మీరు ఈ స్నిప్పెట్‌ని తీసుకోవడానికి మరియు ఇప్పటికే సుదీర్ఘ లావాదేవీల యొక్క కొంత ట్రాకింగ్ చేయడానికి మిమ్మల్ని అనుమతించే స్నిప్పెట్‌కి లింక్ ఇక్కడ ఉంది.

సుదీర్ఘ లావాదేవీలు ఎందుకు చెడ్డవి? ఎందుకంటే అన్ని తాళాలు చివర్లో మాత్రమే విడుదల చేయబడతాయి. మరియు మేము ప్రతి ఒక్కరినీ చిత్తు చేస్తాము. అదనంగా, మేము అన్ని టేబుల్‌ల కోసం ఆటోవాక్యూమ్‌ని బ్లాక్ చేస్తాము. ఇది అస్సలు మంచిది కాదు. మీరు ప్రతిరూపంలో హాట్ స్టాండ్‌బైని ప్రారంభించినప్పటికీ, ఇది ఇప్పటికీ చెడ్డది. సాధారణంగా, సుదీర్ఘ లావాదేవీలను నివారించడం ఎక్కడా మంచిది కాదు.

వాక్యూమ్ చేయని అనేక పట్టికలు మన వద్ద ఉంటే, అప్పుడు మనకు హెచ్చరిక అవసరం. ఇక్కడ అలాంటి పరిస్థితి సాధ్యమే. మేము ఆటోవాక్యూమ్ యొక్క ఆపరేషన్‌ను పరోక్షంగా ప్రభావితం చేయవచ్చు. ఇది Avito నుండి స్నిప్పెట్, నేను కొద్దిగా మెరుగుపరిచాను. మరియు ఆటోవాక్యూమ్‌తో మనకు ఏమి ఉందో చూడటానికి ఇది ఒక ఆసక్తికరమైన సాధనంగా మారింది. ఉదాహరణకు, కొన్ని పట్టికలు అక్కడ వేచి ఉన్నాయి మరియు వాటి వంతు కోసం వేచి ఉండవు. మీరు దీన్ని మానిటరింగ్‌లో ఉంచి, హెచ్చరికను కూడా కలిగి ఉండాలి.

మరియు బ్లాక్‌లను జారీ చేస్తుంది. బ్లాక్ చెట్ల అడవి. నేను ఒకరి నుండి ఏదైనా తీసుకొని దానిని మెరుగుపరచడం ఇష్టం. ఇక్కడ నేను డేటా ఎగ్రెట్ నుండి కూల్ రికర్సివ్ CTE తీసుకున్నాను, అది తాళం చెట్లు ఉన్న అడవిని చూపుతుంది. ఇది మంచి రోగనిర్ధారణ సాధనం. మరియు దాని ఆధారంగా, మీరు పర్యవేక్షణను కూడా నిర్మించవచ్చు. కానీ ఇది జాగ్రత్తగా చేయాలి. మీరు మీ కోసం ఒక చిన్న స్టేట్‌మెంట్_టైమ్ అవుట్ చేయాలి. మరియు lock_timeout కావాల్సినది.

కొన్నిసార్లు ఈ దోషాలన్నీ మొత్తంగా జరుగుతాయి.

నా అభిప్రాయం ప్రకారం, ఇక్కడ ప్రధాన తప్పు సంస్థాగతమైనది. ఇది సంస్థాగతమైనది, ఎందుకంటే సాంకేతికత లాగదు. ఇది నంబర్ 2 - వారు తప్పు స్థానంలో తనిఖీ చేసారు.

మేము తప్పు స్థలంలో తనిఖీ చేసాము, ఎందుకంటే మా వద్ద ప్రొడక్షన్ క్లోన్ లేదు, దాన్ని తనిఖీ చేయడం సులభం. డెవలపర్‌కు ఉత్పత్తికి అస్సలు యాక్సెస్ ఉండకపోవచ్చు.

మరియు మేము అక్కడ తనిఖీ చేయలేదు. అక్కడ చెక్ చేసి ఉంటే మనమే చూసేవాళ్లం. డెవలపర్ ఒక మంచి వాతావరణంలో, అదే మొత్తంలో డేటా మరియు ఒకే లొకేషన్ ఉన్న చోట తనిఖీ చేస్తే DBA లేకుండా కూడా అన్నింటినీ చూసారు. ఈ అధోగతి అంతా చూసి సిగ్గుపడేవాడు.

Autovacuum గురించి మరింత. మేము అనేక మిలియన్ లైన్ల భారీ స్వీప్ చేసిన తర్వాత, మేము ఇంకా రీప్యాక్ చేయాలి. సూచికలకు ఇది చాలా ముఖ్యమైనది. మేము అక్కడ ప్రతిదీ శుభ్రం చేసిన తర్వాత వారు బాధపడతారు.

మరియు మీరు రోజువారీ శుభ్రపరిచే పనిని తిరిగి తీసుకురావాలనుకుంటే, నేను దీన్ని మరింత తరచుగా చేయాలని సూచిస్తున్నాను, కానీ చిన్నది. ఇది నిమిషానికి ఒకసారి లేదా చాలా తరచుగా కొంచెం కావచ్చు. మరియు మీరు రెండు విషయాలను పర్యవేక్షించవలసి ఉంటుంది: ఈ విషయానికి లోపాలు లేవు మరియు ఇది వెనుకబడి ఉండదు. నేను చూపిన ఉపాయం దీనిని పరిష్కరిస్తుంది.

మనం చేసేది ఓపెన్ సోర్స్. ఇది GitLabలో పోస్ట్ చేయబడింది. DBA లేకుండా కూడా ప్రజలు తనిఖీ చేసేలా మేము దీన్ని తయారు చేస్తాము. మేము డేటాబేస్ ల్యాబ్‌ని చేస్తున్నాము, అంటే జో ప్రస్తుతం పనిచేస్తున్న బేస్ కాంపోనెంట్‌ని పిలుస్తాము. మరియు మీరు ఉత్పత్తి కాపీని పట్టుకోవచ్చు. ఇప్పుడు జో ఫర్ స్లాక్ అమలులో ఉంది, మీరు అక్కడ ఇలా చెప్పవచ్చు: “అటువంటి అభ్యర్థనను వివరించండి” మరియు వెంటనే మీ డేటాబేస్ కాపీ కోసం ఫలితాన్ని పొందండి. మీరు అక్కడ కూడా తొలగించవచ్చు మరియు ఎవరూ దానిని గమనించలేరు.

మీ వద్ద 10 టెరాబైట్‌లు ఉన్నాయని అనుకుందాం, మేము డేటాబేస్ ల్యాబ్‌ను కూడా 10 టెరాబైట్‌లను తయారు చేస్తాము. మరియు ఏకకాలంలో 10 టెరాబైట్ డేటాబేస్‌లతో, 10 మంది డెవలపర్‌లు ఏకకాలంలో పని చేయవచ్చు. ప్రతి ఒక్కరూ తమకు కావలసినది చేయగలరు. తొలగించడం, వదలడం మొదలైనవి చేయవచ్చు. అదో ఫాంటసీ. దీని గురించి రేపు మాట్లాడుకుందాం.

దీన్నే థిన్ ప్రొవిజనింగ్ అంటారు. ఇది సూక్ష్మమైన కేటాయింపు. ఇది ఒక రకమైన ఫాంటసీ, ఇది అభివృద్ధిలో, పరీక్షలో జాప్యాన్ని బాగా తొలగిస్తుంది మరియు ఈ విషయంలో ప్రపంచాన్ని మెరుగైన ప్రదేశంగా చేస్తుంది. అంటే, ఇది సమూహ కార్యకలాపాలతో సమస్యలను నివారించడానికి మిమ్మల్ని అనుమతిస్తుంది.

ఉదాహరణ: 5 టెరాబైట్ డేటాబేస్, 30 సెకన్లలోపు కాపీని పొందడం. మరియు ఇది పరిమాణంపై కూడా ఆధారపడదు, అంటే, ఎన్ని టెరాబైట్‌లు ఉన్నా పట్టింపు లేదు.

ఈ రోజు మీరు వెళ్ళవచ్చు postgres.ai మరియు మా సాధనాలను తీయండి. అక్కడ ఏమి ఉందో చూడటానికి మీరు నమోదు చేసుకోవచ్చు. మీరు ఈ బోట్‌ని ఇన్‌స్టాల్ చేసుకోవచ్చు. ఇది ఉచితం. వ్రాయడానికి.

మీ ప్రశ్నలు

చాలా తరచుగా వాస్తవ పరిస్థితులలో పట్టికలో ఉండవలసిన డేటా తొలగించాల్సిన దానికంటే చాలా తక్కువగా ఉందని తేలింది. అంటే, అటువంటి పరిస్థితిలో, అటువంటి విధానాన్ని అమలు చేయడం చాలా సులభం, కొత్త వస్తువును సృష్టించడం సులభం అయినప్పుడు, అక్కడ అవసరమైన డేటాను మాత్రమే కాపీ చేసి, పాత పట్టికను ట్రంక్ చేయండి. మీరు మారుతున్నప్పుడు ఈ క్షణానికి ప్రోగ్రామాటిక్ విధానం అవసరమని స్పష్టంగా ఉంది. ఈ విధానం ఎలా ఉంది?

ఇది చాలా మంచి విధానం మరియు చాలా మంచి పని. ఇది pg_repack చేసే దానికి చాలా పోలి ఉంటుంది, మీరు IDలను 4 బైట్‌లను తయారు చేసినప్పుడు మీరు ఏమి చేయాలి అనే దానితో ఇది చాలా పోలి ఉంటుంది. చాలా ఫ్రేమ్‌వర్క్‌లు కొన్ని సంవత్సరాల క్రితం దీన్ని చేశాయి మరియు ప్లేట్లు పెరిగాయి మరియు వాటిని 8 బైట్‌లుగా మార్చాలి.

ఈ పని చాలా కష్టం. మేము చేసాము. మరియు మీరు చాలా జాగ్రత్తగా ఉండాలి. తాళాలు వగైరా ఉన్నాయి కానీ చేస్తున్నారు. అంటే, pg_repackతో వెళ్లడమే ప్రామాణిక విధానం. మీరు అలాంటి లేబుల్‌ని ప్రకటించండి. మరియు మీరు స్నాప్‌షాట్ డేటాను అప్‌లోడ్ చేయడం ప్రారంభించే ముందు, మీరు అన్ని మార్పులను ట్రాక్ చేసే ఒక ప్లేట్‌ను కూడా ప్రకటించండి. మీరు కొన్ని మార్పులను కూడా ట్రాక్ చేయలేని ట్రిక్ ఉంది. సూక్ష్మబేధాలు ఉన్నాయి. ఆపై మీరు రోలింగ్ మార్పుల ద్వారా మారండి. మేము ప్రతి ఒక్కరినీ మూసివేసినప్పుడు చిన్న విరామం ఉంటుంది, కానీ సాధారణంగా ఇది చేయబడుతుంది.

మీరు GitHubలో pg_repackని చూస్తే, అక్కడ, IDని int 4 నుండి int 8కి మార్చే పని ఉన్నప్పుడు, pg_repackని ఉపయోగించాలనే ఆలోచన వచ్చింది. ఇది కూడా సాధ్యమే, కానీ ఇది కొంచెం హ్యాక్, కానీ దీని కోసం కూడా ఇది పని చేస్తుంది. మీరు pg_repack ఉపయోగించే ట్రిగ్గర్‌లో జోక్యం చేసుకుని, అక్కడ ఇలా చెప్పవచ్చు: "మాకు ఈ డేటా అవసరం లేదు", అంటే మేము మనకు అవసరమైన వాటిని మాత్రమే బదిలీ చేస్తాము. ఆపై అతను కేవలం మారతాడు మరియు అంతే.

ఈ విధానంతో, మేము ఇప్పటికీ పట్టిక యొక్క రెండవ కాపీని పొందుతాము, దీనిలో డేటా ఇప్పటికే ఇండెక్స్ చేయబడింది మరియు అందమైన సూచికలతో చాలా సమానంగా పేర్చబడి ఉంటుంది.

ఉబ్బరం లేదు, ఇది మంచి విధానం. కానీ దీని కోసం ఆటోమేషన్‌ను అభివృద్ధి చేయడానికి, అంటే సార్వత్రిక పరిష్కారాన్ని రూపొందించడానికి ప్రయత్నాలు జరుగుతున్నాయని నాకు తెలుసు. నేను ఈ ఆటోమేషన్‌తో మిమ్మల్ని సంప్రదించగలను. ఇది పైథాన్‌లో వ్రాయబడింది, ఇది మంచి విషయం.

నేను MySQL ప్రపంచం నుండి కొంచెం ఉన్నాను, కాబట్టి నేను వినడానికి వచ్చాను. మరియు మేము ఈ విధానాన్ని ఉపయోగిస్తాము.

కానీ అది మనకు 90% ఉంటే మాత్రమే. మనకు 5% ఉంటే, దానిని ఉపయోగించడం చాలా మంచిది కాదు.

నివేదికకు ధన్యవాదాలు! ఉత్పత్తి యొక్క పూర్తి కాపీని చేయడానికి వనరులు లేకుంటే, లోడ్ లేదా పరిమాణాన్ని లెక్కించడానికి ఏదైనా అల్గోరిథం లేదా ఫార్ములా ఉందా?

మంచి ప్రశ్న. ఇప్పటివరకు, మేము బహుళ-టెరాబైట్ డేటాబేస్‌లను కనుగొనగలుగుతున్నాము. అక్కడ హార్డ్‌వేర్ ఒకేలా లేకపోయినా, ఉదాహరణకు, తక్కువ మెమరీ, తక్కువ ప్రాసెసర్ మరియు డిస్క్‌లు సరిగ్గా ఒకే విధంగా ఉండవు, కానీ ఇప్పటికీ మేము దీన్ని చేస్తాము. ఖచ్చితంగా ఎక్కడా లేనట్లయితే, మీరు ఆలోచించాలి. రేపటి దాకా ఆలోచిద్దాం, నువ్వు వచ్చావు, మనం మాట్లాడుకుందాం, ఇది మంచి ప్రశ్న.

నివేదికకు ధన్యవాదాలు! అటువంటి మరియు అటువంటి పరిమితులను కలిగి ఉన్న చల్లని పోస్ట్‌గ్రెస్ ఉందని మీరు మొదట ప్రారంభించారు, కానీ అది అభివృద్ధి చెందుతోంది. మరియు ఇదంతా పెద్ద ఊతకర్ర. పోస్ట్‌గ్రెస్ అభివృద్ధితో ఇవన్నీ వైరుధ్యం కాదా, దీనిలో కొన్ని డిలీట్ డిఫెరెంట్‌లు కనిపిస్తాయి లేదా మనం ఇక్కడ మన వింత మార్గాలలో కొన్నింటిని స్మెర్ చేయడానికి ప్రయత్నిస్తున్న వాటిని తక్కువ స్థాయిలో ఉంచాలి?

ఒక లావాదేవీలో అనేక రికార్డులను తొలగించాలని లేదా అప్‌డేట్ చేయాలని మేము SQLలో చెప్పినట్లయితే, పోస్ట్‌గ్రెస్ దానిని అక్కడ ఎలా పంపిణీ చేస్తుంది? మేము కార్యకలాపాలలో భౌతికంగా పరిమితం. మేము ఇంకా చాలా కాలం పాటు చేస్తాము. మరియు మేము ఈ సమయంలో లాక్ చేస్తాము, మొదలైనవి.

సూచికలతో పూర్తయింది.

అదే చెక్‌పాయింట్ ట్యూనింగ్ స్వయంచాలకంగా ఉంటుందని నేను ఊహించగలను. ఏదో ఒకరోజు అది కావచ్చు. కానీ అప్పుడు నాకు ప్రశ్న నిజంగా అర్థం కాలేదు.

ప్రశ్న ఏమిటంటే, అటువంటి అభివృద్ధి వెక్టర్ ఇక్కడ మరియు అక్కడకు వెళుతుంది మరియు ఇక్కడ మీది సమాంతరంగా వెళుతుందా? ఆ. వారు ఇంకా దాని గురించి ఆలోచించలేదా?

నేను ఇప్పుడు ఉపయోగించగల సూత్రాల గురించి మాట్లాడాను. మరొక బోట్ ఉంది నాన్సీ, దీనితో మీరు ఆటోమేటెడ్ చెక్‌పాయింట్ ట్యూనింగ్ చేయవచ్చు. ఇది ఏదో ఒక రోజు పోస్ట్‌గ్రెస్‌లో ఉంటుందా? నాకు తెలియదు, ఇది ఇంకా చర్చించబడలేదు. దానికి మనం ఇంకా దూరంగానే ఉన్నాం. కానీ కొత్త వ్యవస్థలను తయారు చేసే శాస్త్రవేత్తలు ఉన్నారు. మరియు వారు మమ్మల్ని ఆటోమేటిక్ ఇండెక్స్‌లలోకి నెట్టారు. పరిణామాలు ఉన్నాయి. ఉదాహరణకు, మీరు ఆటో ట్యూనింగ్‌ను చూడవచ్చు. ఇది స్వయంచాలకంగా పారామితులను ఎంచుకుంటుంది. కానీ అతను ఇంకా మీ కోసం చెక్‌పాయింట్ ట్యూనింగ్ చేయడు. అంటే, ఇది పనితీరు, షెల్ బఫర్ మొదలైన వాటి కోసం ఎంపిక చేయబడుతుంది.

మరియు చెక్‌పాయింట్ ట్యూనింగ్ కోసం, మీరు దీన్ని చేయవచ్చు: మీకు క్లౌడ్‌లో వెయ్యి క్లస్టర్‌లు మరియు విభిన్న హార్డ్‌వేర్, విభిన్న వర్చువల్ మిషన్లు ఉంటే, మీరు మా బోట్‌ని ఉపయోగించవచ్చు నాన్సీ ఆటోమేషన్ చేయండి. మరియు max_wal_size మీ లక్ష్య సెట్టింగ్‌ల ప్రకారం స్వయంచాలకంగా ఎంపిక చేయబడుతుంది. కానీ ఇప్పటివరకు ఇది దురదృష్టవశాత్తు కోర్‌లో కూడా దగ్గరగా లేదు.

శుభ మద్యాహ్నం మీరు సుదీర్ఘ లావాదేవీల ప్రమాదాల గురించి మాట్లాడారు. తొలగింపుల విషయంలో ఆటోవాక్యూమ్ బ్లాక్ చేయబడిందని మీరు చెప్పారు. అది మనకెలా హాని చేస్తుంది? ఎందుకంటే మేము స్థలాన్ని ఖాళీ చేయడం మరియు దానిని ఉపయోగించగలగడం గురించి ఎక్కువగా మాట్లాడుతున్నాము. మనం ఇంకా ఏమి కోల్పోతున్నాము?

Autovacuum బహుశా ఇక్కడ అతిపెద్ద సమస్య కాదు. మరియు సుదీర్ఘ లావాదేవీ ఇతర లావాదేవీలను లాక్ చేయగలదనే వాస్తవం, ఈ అవకాశం మరింత ప్రమాదకరమైనది. ఆమె కలవవచ్చు లేదా కలవకపోవచ్చు. ఆమె కలుసుకున్నట్లయితే, అది చాలా చెడ్డది కావచ్చు. మరియు ఆటోవాక్యూమ్‌తో - ఇది కూడా సమస్య. OLTPలో సుదీర్ఘ లావాదేవీలతో రెండు సమస్యలు ఉన్నాయి: తాళాలు మరియు ఆటోవాక్యూమ్. మరియు మీరు ప్రతిరూపంపై హాట్ స్టాండ్‌బై ఫీడ్‌బ్యాక్ ఎనేబుల్ చేసి ఉంటే, అప్పుడు ఆటోవాక్యూమ్ లాక్ కూడా మాస్టర్‌పైకి వస్తుంది, అది ప్రతిరూపం నుండి వస్తుంది. కానీ కనీసం తాళాలు కూడా ఉండవు. మరియు లోకులు ఉంటాయి. మేము డేటా మార్పుల గురించి మాట్లాడుతున్నాము, కాబట్టి లాక్‌లు ఇక్కడ ముఖ్యమైన అంశం. మరియు ఇవన్నీ ఎక్కువ కాలం, ఎక్కువ కాలం ఉంటే, మరింత ఎక్కువ లావాదేవీలు లాక్ చేయబడతాయి. వారు ఇతరులను దొంగిలించగలరు. మరియు లోక్ చెట్లు కనిపిస్తాయి. నేను స్నిప్పెట్‌కి లింక్ అందించాను. మరియు ఈ సమస్య ఆటోవాక్యూమ్‌తో సమస్య కంటే వేగంగా గుర్తించదగినదిగా మారుతుంది, ఇది మాత్రమే పేరుకుపోతుంది.

నివేదికకు ధన్యవాదాలు! మీరు తప్పుగా పరీక్షించారని చెప్పడం ద్వారా మీ నివేదికను ప్రారంభించారు. మేము అదే పరికరాలను, అదే విధంగా బేస్‌తో తీసుకోవాలని మా ఆలోచనను కొనసాగించాము. మేము డెవలపర్‌కు ఆధారాన్ని ఇచ్చామని అనుకుందాం. మరియు అతను అభ్యర్థనకు కట్టుబడి ఉన్నాడు. మరియు అతను బాగానే ఉన్నట్లు అనిపిస్తుంది. కానీ అతను ప్రత్యక్షంగా తనిఖీ చేయడు, కానీ ప్రత్యక్ష ప్రసారం కోసం, ఉదాహరణకు, మనకు 60-70% లోడ్ ఉంది. మరియు మనం ఈ ట్యూనింగ్‌ని ఉపయోగించినప్పటికీ, అది బాగా పని చేయదు.

బృందంలో నిపుణుడిని కలిగి ఉండటం మరియు నిజమైన నేపథ్య లోడ్‌తో ఏమి జరుగుతుందో అంచనా వేయగల DBA నిపుణులను ఉపయోగించడం ముఖ్యం. మేము మా క్లీన్ మార్పులను డ్రైవ్ చేసినప్పుడు, మేము చిత్రాన్ని చూస్తాము. కానీ మరింత అధునాతన విధానం, మేము మళ్లీ అదే పనిని చేసినప్పుడు, కానీ ఉత్పత్తితో అనుకరించబడిన లోడ్‌తో. ఇది చాలా బాగుంది. అప్పటిదాకా ఎదగాలి. ఇది పెద్దల వంటిది. మేము మా వద్ద ఉన్న వాటిని మాత్రమే చూశాము మరియు మనకు తగినంత వనరులు ఉన్నాయా లేదా అని కూడా చూశాము. అది మంచి ప్రశ్న.

మేము ఇప్పటికే చెత్తను ఎంపిక చేస్తున్నప్పుడు, ఉదాహరణకు, తొలగించబడిన ఫ్లాగ్‌ని కలిగి ఉన్నాము

పోస్ట్‌గ్రెస్‌లో ఆటోవాక్యూమ్ స్వయంచాలకంగా చేస్తుంది.

ఓహ్, అతను చేస్తాడా?

ఆటోవాక్యూమ్ చెత్త సేకరించేవాడు.

ధన్యవాదాలు!

నివేదికకు ధన్యవాదాలు! చెత్త అంతా మెయిన్ టేబుల్ నుండి పక్కకు ఎక్కడో మురికిగా ఉండే విధంగా విభజనతో డేటాబేస్‌ను వెంటనే రూపొందించే అవకాశం ఉందా?

కోర్సు యొక్క కలిగి.

ఉపయోగించకూడని టేబుల్‌ను మనం లాక్ చేసి ఉంటే మనల్ని మనం రక్షించుకోవడం సాధ్యమేనా?

కోర్సు యొక్క కలిగి. అయితే ఇది కోడి గుడ్డు ప్రశ్న లాంటిది. భవిష్యత్తులో ఏమి జరుగుతుందో మనందరికీ తెలిస్తే, మేము ప్రతిదీ చల్లగా చేస్తాము. కానీ వ్యాపారం మారుతోంది, కొత్త నిలువు వరుసలు, కొత్త అభ్యర్థనలు ఉన్నాయి. ఆపై - అయ్యో, మేము దానిని తీసివేయాలనుకుంటున్నాము. కానీ ఈ ఆదర్శ పరిస్థితి, జీవితంలో ఇది సంభవిస్తుంది, కానీ ఎల్లప్పుడూ కాదు. కానీ మొత్తంగా ఇది మంచి ఆలోచన. కేవలం కత్తిరించండి మరియు అంతే.

మూలం: www.habr.com