DBA బోట్ జో. అనటోలీ స్టాన్స్లర్ (Postgres.ai)

DBA బోట్ జో. అనటోలీ స్టాన్స్లర్ (Postgres.ai)

SQL ప్రశ్న "ప్రొడ్"లో బాగా పని చేస్తుందని బ్యాకెండ్ డెవలపర్ ఎలా అర్థం చేసుకుంటాడు? పెద్ద లేదా వేగంగా అభివృద్ధి చెందుతున్న కంపెనీలలో, ప్రతి ఒక్కరికీ "ఉత్పత్తి"కి ప్రాప్యత లేదు. మరియు యాక్సెస్‌తో, అన్ని అభ్యర్థనలు నొప్పిలేకుండా తనిఖీ చేయబడవు మరియు డేటాబేస్ కాపీని సృష్టించడానికి తరచుగా గంటలు పడుతుంది. ఈ సమస్యలను పరిష్కరించడానికి, మేము ఒక కృత్రిమ DBAని సృష్టించాము - జో. ఇది ఇప్పటికే అనేక కంపెనీలలో విజయవంతంగా అమలు చేయబడింది మరియు డజనుకు పైగా డెవలపర్‌లకు సహాయపడుతుంది.

వీడియోలు:

DBA బోట్ జో. అనటోలీ స్టాన్స్లర్ (Postgres.ai)

అందరికి వందనాలు! నా పేరు అనాటోలీ స్టాన్స్లర్. నేను ఒక కంపెనీలో పని చేస్తున్నాను postgres.ai. డెవలపర్‌లు, DBAలు మరియు QAల నుండి పోస్ట్‌గ్రెస్ పనికి సంబంధించిన జాప్యాలను తొలగించడం ద్వారా అభివృద్ధి ప్రక్రియను వేగవంతం చేయడానికి మేము కట్టుబడి ఉన్నాము.

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

DBA బోట్ జో. అనటోలీ స్టాన్స్లర్ (Postgres.ai)

మేము సంక్లిష్టమైన అధిక-లోడ్ వలసలను అభివృద్ధి చేస్తున్నప్పుడు మరియు చేస్తున్నప్పుడు, మనల్ని మనం ప్రశ్నించుకుంటాము: "ఈ వలసలు బయలుదేరుతాయా?". మేము సమీక్షను ఉపయోగిస్తాము, మేము మరింత అనుభవజ్ఞులైన సహచరులు, DBA నిపుణుల జ్ఞానాన్ని ఉపయోగిస్తాము. మరియు అది ఎగురుతుందో లేదో వారు చెప్పగలరు.

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

DBA బోట్ జో. అనటోలీ స్టాన్స్లర్ (Postgres.ai)

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

DBA బోట్ జో. అనటోలీ స్టాన్స్లర్ (Postgres.ai)

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

DBA బోట్ జో. అనటోలీ స్టాన్స్లర్ (Postgres.ai)

ఇది బాధిస్తుంది, ఇది ఖరీదైనది. ఇది బహుశా ఉత్తమం కాదు.

మరియు దీన్ని చేయడానికి ఉత్తమ మార్గం ఏమిటి?

DBA బోట్ జో. అనటోలీ స్టాన్స్లర్ (Postgres.ai)

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

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

సమస్యలు ఏమిటి?

  • సమస్య ఏమిటంటే, మేము ఈ స్టేజింగ్‌ని సహోద్యోగులతో పంచుకుంటాము. మరియు చాలా తరచుగా మీరు మార్పు రకమైన, బామ్ చేసే జరుగుతుంది - మరియు డేటా లేదు, పని కాలువ డౌన్ ఉంది. స్టేజింగ్ మల్టీ-టెరాబైట్. మరి అది మళ్లీ పుంజుకోవాలంటే చాలా కాలం ఆగాల్సిందే. మరియు మేము దానిని రేపు ఖరారు చేయాలని నిర్ణయించుకున్నాము. అంతే, మనకు అభివృద్ధి ఉంది.
  • మరియు, వాస్తవానికి, మాకు అక్కడ చాలా మంది సహోద్యోగులు పని చేస్తున్నారు, చాలా జట్లు ఉన్నాయి. మరియు ఇది మానవీయంగా చేయాలి. మరియు ఇది అసౌకర్యంగా ఉంది.

DBA బోట్ జో. అనటోలీ స్టాన్స్లర్ (Postgres.ai)

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

ఇది మునుపటి విధానం కంటే మెరుగ్గా ఉంది, కానీ ఒక రకమైన లోపం ఉత్పత్తికి వెళ్ళే అధిక సంభావ్యత ఇప్పటికీ ఉంది.

DBA బోట్ జో. అనటోలీ స్టాన్స్లర్ (Postgres.ai)

ప్రతి డెవలపర్‌కు టెస్ట్ బెంచ్, పూర్తి-పరిమాణ కాపీని ఇవ్వకుండా మమ్మల్ని ఏది నిరోధిస్తుంది? మార్గంలో ఏమి జరుగుతుందో స్పష్టంగా ఉందని నేను భావిస్తున్నాను.

టెరాబైట్ కంటే పెద్ద డేటాబేస్ ఎవరి వద్ద ఉంది? సగానికి పైగా గది.

మరియు ప్రతి డెవలపర్ కోసం యంత్రాలను ఉంచడం, ఇంత పెద్ద ఉత్పత్తి ఉన్నప్పుడు, చాలా ఖరీదైనది, అంతేకాకుండా, ఇది చాలా సమయం పడుతుంది.

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

DBA బోట్ జో. అనటోలీ స్టాన్స్లర్ (Postgres.ai)

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

కానీ వారు ఈ విధానాన్ని ఉపయోగిస్తారు ఎందుకంటే ఇది ఉత్పత్తిని నమ్మదగినదిగా ఉంచడానికి అనుమతిస్తుంది.

మేము ఇక్కడ ఏమి చేయవచ్చు? టెస్ట్ బెంచ్‌లను చౌకగా చేద్దాం మరియు ప్రతి డెవలపర్‌కు వారి స్వంత టెస్ట్ బెంచ్ ఇద్దాం.

మరియు ఇది సాధ్యమే.

DBA బోట్ జో. అనటోలీ స్టాన్స్లర్ (Postgres.ai)

మరియు ఈ విధానంలో, మేము ప్రతి డెవలపర్ కోసం సన్నని క్లోన్‌లను తయారు చేసినప్పుడు, మేము దానిని ఒక మెషీన్‌లో పంచుకోవచ్చు. ఉదాహరణకు, మీ వద్ద 10TB డేటాబేస్ ఉండి, దానిని 10 మంది డెవలపర్‌లకు ఇవ్వాలనుకుంటే, మీరు XNUMX x XNUMXTB డేటాబేస్‌లను కలిగి ఉండాల్సిన అవసరం లేదు. ఒక మెషీన్‌ని ఉపయోగించి ప్రతి డెవలపర్ కోసం సన్నని వివిక్త కాపీలను చేయడానికి మీకు ఒక మెషీన్ మాత్రమే అవసరం. ఇది ఎలా పని చేస్తుందో కొంచెం తర్వాత చెబుతాను.

DBA బోట్ జో. అనటోలీ స్టాన్స్లర్ (Postgres.ai)

నిజమైన ఉదాహరణ:

  • DB - 4,5 టెరాబైట్లు.

  • మేము 30 సెకన్లలో స్వతంత్ర కాపీలను పొందవచ్చు.

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

ఇది చాలా గొప్ప విషయం. ఇక్కడ మనం మేజిక్ మరియు సమాంతర విశ్వం గురించి మాట్లాడుతున్నాము.

DBA బోట్ జో. అనటోలీ స్టాన్స్లర్ (Postgres.ai)

మా విషయంలో, ఇది OpenZFS సిస్టమ్‌ను ఉపయోగించి పని చేస్తుంది.

DBA బోట్ జో. అనటోలీ స్టాన్స్లర్ (Postgres.ai)

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

ఇతర ఎంపికలు ఉన్నాయి:

  • lvm,

  • నిల్వ (ఉదాహరణకు, స్వచ్ఛమైన నిల్వ).

నేను మాట్లాడుతున్న డేటాబేస్ ల్యాబ్ మాడ్యులర్. ఈ ఎంపికలను ఉపయోగించి అమలు చేయవచ్చు. అయితే ప్రస్తుతానికి, మేము OpenZFSపై దృష్టి సారించాము, ఎందుకంటే ప్రత్యేకంగా LVMతో సమస్యలు ఉన్నాయి.

DBA బోట్ జో. అనటోలీ స్టాన్స్లర్ (Postgres.ai)

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

మరియు భవిష్యత్తులో, మేము రోల్‌బ్యాక్ చేయాలనుకున్నప్పుడు లేదా ఏదైనా పాత వెర్షన్ నుండి కొత్త క్లోన్‌ని తయారు చేయాలనుకున్నప్పుడు, మేము ఇలా చెబుతాము: "సరే, ఇలా మార్క్ చేయబడిన ఈ డేటా బ్లాక్‌లను మాకు ఇవ్వండి."

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

మరియు మేము శాఖ చేస్తాము. మా విషయంలో ప్రతి డెవలపర్‌కు అతను సవరించే స్వంత క్లోన్‌ని కలిగి ఉండే అవకాశం ఉంటుంది మరియు భాగస్వామ్యం చేయబడిన డేటా అందరి మధ్య భాగస్వామ్యం చేయబడుతుంది.

DBA బోట్ జో. అనటోలీ స్టాన్స్లర్ (Postgres.ai)

ఇంట్లో అటువంటి వ్యవస్థను అమలు చేయడానికి, మీరు రెండు సమస్యలను పరిష్కరించాలి:

  • మొదటిది డేటా యొక్క మూలం, మీరు దానిని ఎక్కడ నుండి తీసుకుంటారు. మీరు ఉత్పత్తితో ప్రతిరూపణను సెటప్ చేయవచ్చు. మీరు ఇప్పటికే కాన్ఫిగర్ చేసిన బ్యాకప్‌లను ఉపయోగించవచ్చు, నేను ఆశిస్తున్నాను. WAL-E, WAL-G లేదా బార్మాన్. మరియు మీరు RDS లేదా Cloud SQL వంటి క్లౌడ్ సొల్యూషన్‌ని ఉపయోగిస్తున్నప్పటికీ, మీరు లాజికల్ డంప్‌లను ఉపయోగించవచ్చు. కానీ మేము ఇప్పటికీ మీకు బ్యాకప్‌లను ఉపయోగించమని సలహా ఇస్తున్నాము, ఎందుకంటే ఈ విధానంతో మీరు ఫైల్‌ల భౌతిక నిర్మాణాన్ని కూడా నిలుపుకుంటారు, ఇది ఉనికిలో ఉన్న సమస్యలను పట్టుకోవడానికి మీరు ఉత్పత్తిలో చూసే కొలమానాలకు మరింత దగ్గరగా ఉండటానికి మిమ్మల్ని అనుమతిస్తుంది.

  • రెండవది మీరు డేటాబేస్ ల్యాబ్‌ను ఎక్కడ హోస్ట్ చేయాలనుకుంటున్నారు. అది క్లౌడ్ కావచ్చు, ఆన్-ప్రిమైజ్ కావచ్చు. ZFS డేటా కంప్రెషన్‌కు మద్దతు ఇస్తుందని ఇక్కడ చెప్పడం ముఖ్యం. మరియు అది చాలా బాగా చేస్తుంది.

అటువంటి ప్రతి క్లోన్ కోసం, మేము బేస్‌తో చేసే కార్యకలాపాలను బట్టి, ఒక రకమైన దేవ్ పెరుగుతుందని ఊహించండి. దీని కోసం, devకి స్థలం కూడా అవసరం. కానీ మేము 4,5 టెరాబైట్‌ల బేస్ తీసుకున్నందున, ZFS దానిని 3,5 టెరాబైట్‌లకు కంప్రెస్ చేస్తుంది. ఇది సెట్టింగ్‌లను బట్టి మారవచ్చు. మరియు మాకు ఇంకా దేవ్ కోసం స్థలం ఉంది.

ఇటువంటి వ్యవస్థ వివిధ సందర్భాలలో ఉపయోగించవచ్చు.

  • ఇవి డెవలపర్లు, ప్రశ్న ధ్రువీకరణ కోసం, ఆప్టిమైజేషన్ కోసం DBAలు.

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

  • మరియు మరొక కేసు. కంపెనీకి అనలిటిక్స్ సిస్టమ్ సెటప్ చేయనట్లయితే, మేము ఉత్పత్తి స్థావరం యొక్క సన్నని క్లోన్‌ను వేరుచేసి, విశ్లేషణలలో ఉపయోగించగల సుదీర్ఘ ప్రశ్నలకు లేదా ప్రత్యేక సూచికలకు అందించవచ్చు.

DBA బోట్ జో. అనటోలీ స్టాన్స్లర్ (Postgres.ai)

ఈ విధానంతో:

  1. "ప్రొడ్"లో లోపాల సంభావ్యత తక్కువగా ఉంటుంది, ఎందుకంటే మేము పూర్తి-పరిమాణ డేటాలో అన్ని మార్పులను పరీక్షించాము.

  2. మాకు పరీక్షా సంస్కృతి ఉంది, ఎందుకంటే ఇప్పుడు మీరు మీ స్వంత స్టాండ్ కోసం గంటల తరబడి వేచి ఉండాల్సిన అవసరం లేదు.

  3. మరియు పరీక్షల మధ్య ఎటువంటి అవరోధం లేదు, వేచి ఉండదు. మీరు నిజంగా వెళ్లి తనిఖీ చేయవచ్చు. మరియు మేము అభివృద్ధిని వేగవంతం చేస్తున్నప్పుడు ఈ విధంగా మెరుగ్గా ఉంటుంది.

  • తక్కువ రీఫ్యాక్టరింగ్ ఉంటుంది. తక్కువ బగ్‌లు ఉత్పత్తిలో ముగుస్తాయి. మేము వాటిని తర్వాత తక్కువ రీఫాక్టర్ చేస్తాము.

  • మేము కోలుకోలేని మార్పులను తిప్పికొట్టవచ్చు. ఇది ప్రామాణిక విధానం కాదు.

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

ఇప్పటికే మంచిది, కానీ ఇంకా ఏమి వేగవంతం చేయవచ్చు?

DBA బోట్ జో. అనటోలీ స్టాన్స్లర్ (Postgres.ai)

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

ఇప్పుడు ఒక దుర్మార్గపు వృత్తం ఉంది, డెవలపర్, నిజమైన పూర్తి-పరిమాణ డేటాకు ప్రాప్యత పొందడానికి, తప్పనిసరిగా నిపుణుడిగా మారాలి. అటువంటి ప్రాప్యతతో అతను తప్పనిసరిగా విశ్వసించబడాలి.

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

DBA బోట్ జో. అనటోలీ స్టాన్స్లర్ (Postgres.ai)

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

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

మరియు స్లాక్ మాకు సహకారం కోసం అవకాశాలను అందిస్తుంది. ఇది కేవలం ఒక ఛానెల్ కాబట్టి, మీరు ఈ అభ్యర్థనను అటువంటి అభ్యర్థన కోసం థ్రెడ్‌లో చర్చించడం ప్రారంభించవచ్చు, కంపెనీ లోపల ఉన్న మీ సహోద్యోగులకు, DBAలకు పింగ్ చేయండి.

DBA బోట్ జో. అనటోలీ స్టాన్స్లర్ (Postgres.ai)

కానీ, వాస్తవానికి, సమస్యలు ఉన్నాయి. ఇది వాస్తవ ప్రపంచం మరియు మేము ఒకేసారి అనేక క్లోన్‌లను హోస్ట్ చేసే సర్వర్‌ని ఉపయోగిస్తున్నందున, మేము క్లోన్‌లకు అందుబాటులో ఉన్న మెమరీ మరియు CPU పవర్ మొత్తాన్ని కుదించవలసి ఉంటుంది.

కానీ ఈ పరీక్షలు ఆమోదయోగ్యంగా ఉండాలంటే, మీరు ఈ సమస్యను ఎలాగైనా పరిష్కరించాలి.

ముఖ్యమైన అంశం అదే డేటా అని స్పష్టమైంది. కానీ మనకు ఇది ఇప్పటికే ఉంది. మరియు మేము అదే కాన్ఫిగరేషన్‌ను సాధించాలనుకుంటున్నాము. మరియు మేము అలాంటి దాదాపు ఒకే విధమైన కాన్ఫిగరేషన్‌ను ఇవ్వగలము.

ఉత్పత్తిలో ఉన్న అదే హార్డ్‌వేర్‌ను కలిగి ఉండటం చాలా బాగుంది, కానీ అది భిన్నంగా ఉండవచ్చు.

DBA బోట్ జో. అనటోలీ స్టాన్స్లర్ (Postgres.ai)

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

మీరు కాన్ఫిగరేషన్‌లో పేర్కొన్న పరిమాణాన్ని బట్టి పోస్ట్‌గ్రెస్ ప్రారంభమైనప్పుడు షేర్డ్ బఫర్ కాష్ కేటాయించబడుతుందని గమనించడం ముఖ్యం.

మరియు రెండవ కాష్ అందుబాటులో ఉన్న అన్ని స్థలాన్ని ఉపయోగిస్తుంది.

DBA బోట్ జో. అనటోలీ స్టాన్స్లర్ (Postgres.ai)

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

మరియు మేము ఈ పరామితిని మార్చకపోతే, మేము ఒక మెషీన్‌లో కేవలం 4 సందర్భాలను మాత్రమే అమలు చేయగలము, అంటే అటువంటి అన్ని సన్నని క్లోన్‌లలో 4. మరియు ఇది చెడ్డది, ఎందుకంటే మేము వాటిలో చాలా ఎక్కువ కలిగి ఉండాలనుకుంటున్నాము.

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

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

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

DBA బోట్ జో. అనటోలీ స్టాన్స్లర్ (Postgres.ai)

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

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

కానీ ఇది సమయాన్ని ప్రభావితం చేయవచ్చు. మరియు మేము ప్రశ్నలను టైమింగ్ ద్వారా ఆప్టిమైజ్ చేస్తాము, అయితే సమయం అనేక అంశాలపై ఆధారపడి ఉండటం ముఖ్యం:

  • ఇది ప్రస్తుతం ఉత్పత్తిపై ఉన్న లోడ్‌పై ఆధారపడి ఉంటుంది.

  • ఇది యంత్రం యొక్క లక్షణాలపై ఆధారపడి ఉంటుంది.

మరియు ఇది పరోక్ష పరామితి, కానీ వాస్తవానికి ఫలితాన్ని పొందడానికి ఈ ప్రశ్న చదివే డేటా మొత్తాన్ని మనం ఖచ్చితంగా ఆప్టిమైజ్ చేయవచ్చు.

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

జో ప్రత్యేకంగా ఎలా ఆప్టిమైజ్ చేయబడిందో చూద్దాం.

DBA బోట్ జో. అనటోలీ స్టాన్స్లర్ (Postgres.ai)

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

DBA బోట్ జో. అనటోలీ స్టాన్స్లర్ (Postgres.ai)

మేము ఛానెల్‌కి సందేశం వ్రాస్తున్నాము, మా కోసం ఒక క్లోన్ నియోగించబడింది. మరియు అటువంటి అభ్యర్థన 2,5 నిమిషాల్లో పూర్తవుతుందని మేము చూస్తాము. ఇది మనం గమనించే మొదటి విషయం.

B Joe మీకు ప్లాన్ మరియు మెట్రిక్‌ల ఆధారంగా ఆటోమేటిక్ సిఫార్సులను చూపుతుంది.

సాపేక్షంగా తక్కువ సంఖ్యలో అడ్డు వరుసలను పొందడానికి ప్రశ్న చాలా ఎక్కువ డేటాను ప్రాసెస్ చేస్తుందని మేము చూస్తాము. మరియు ప్రశ్నలో చాలా ఫిల్టర్ చేసిన అడ్డు వరుసలు ఉన్నాయని మేము గమనించినందున, ఒక రకమైన ప్రత్యేక సూచిక అవసరం.

DBA బోట్ జో. అనటోలీ స్టాన్స్లర్ (Postgres.ai)

ఏమి జరిగిందో నిశితంగా పరిశీలిద్దాం. నిజానికి, మేము ఫైల్ కాష్ నుండి లేదా డిస్క్ నుండి కూడా దాదాపు ఒకటిన్నర గిగాబైట్ల డేటాను చదివినట్లు చూస్తాము. మరియు ఇది మంచిది కాదు, ఎందుకంటే మనకు 142 లైన్లు మాత్రమే వచ్చాయి.

DBA బోట్ జో. అనటోలీ స్టాన్స్లర్ (Postgres.ai)

మరియు, మేము ఇక్కడ ఇండెక్స్ స్కాన్‌ని కలిగి ఉన్నాము మరియు త్వరగా పని చేసి ఉండాలి, కానీ మేము చాలా పంక్తులను ఫిల్టర్ చేసినందున (మేము వాటిని లెక్కించవలసి వచ్చింది), అభ్యర్థన నెమ్మదిగా పని చేస్తుంది.

DBA బోట్ జో. అనటోలీ స్టాన్స్లర్ (Postgres.ai)

మరియు ప్రశ్నలోని పరిస్థితులు మరియు సూచికలోని పరిస్థితులు పాక్షికంగా సరిపోలడం లేదు అనే వాస్తవం కారణంగా ఇది ప్లాన్‌లో జరిగింది.

DBA బోట్ జో. అనటోలీ స్టాన్స్లర్ (Postgres.ai)

ఇండెక్స్‌ను మరింత ఖచ్చితమైనదిగా చేయడానికి ప్రయత్నిద్దాం మరియు ఆ తర్వాత ప్రశ్న అమలు ఎలా మారుతుందో చూద్దాం.

DBA బోట్ జో. అనటోలీ స్టాన్స్లర్ (Postgres.ai)

సూచిక యొక్క సృష్టికి చాలా సమయం పట్టింది, కానీ ఇప్పుడు మేము ప్రశ్నను తనిఖీ చేస్తాము మరియు 2,5 నిమిషాలకు బదులుగా సమయం 156 మిల్లీసెకన్లు మాత్రమే ఉందని చూస్తాము, ఇది సరిపోతుంది. మరియు మేము 6 మెగాబైట్ల డేటాను మాత్రమే చదువుతాము.

DBA బోట్ జో. అనటోలీ స్టాన్స్లర్ (Postgres.ai)

మరియు ఇప్పుడు మేము ఇండెక్స్ మాత్రమే స్కాన్ ఉపయోగిస్తాము.

మరో ముఖ్యమైన కథనం ఏమిటంటే, మేము ప్లాన్‌ను మరింత అర్థమయ్యే రీతిలో ప్రదర్శించాలనుకుంటున్నాము. మేము ఫ్లేమ్ గ్రాఫ్‌లను ఉపయోగించి విజువలైజేషన్‌ని అమలు చేసాము.

DBA బోట్ జో. అనటోలీ స్టాన్స్లర్ (Postgres.ai)

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

ఇక్కడ మనం నిర్దిష్ట నోడ్‌లను ఒకదానితో ఒకటి పోల్చవచ్చు. మరియు వాటిలో ఏది ఎక్కువ లేదా తక్కువ తీసుకుంటుందో స్పష్టంగా తెలుస్తుంది, ఇది సాధారణంగా ఇతర రెండరింగ్ పద్ధతులలో చేయడం కష్టం.

DBA బోట్ జో. అనటోలీ స్టాన్స్లర్ (Postgres.ai)

అయితే, ప్రతి ఒక్కరికి explan.depesz.com తెలుసు. ఈ విజువలైజేషన్ యొక్క మంచి లక్షణం ఏమిటంటే, మేము టెక్స్ట్ ప్లాన్‌ను సేవ్ చేస్తాము మరియు కొన్ని ప్రాథమిక పారామితులను టేబుల్‌లో ఉంచాము, తద్వారా మనం క్రమబద్ధీకరించవచ్చు.

ఇంకా ఈ అంశాన్ని లోతుగా పరిశోధించని డెవలపర్‌లు explain.depesz.comని కూడా ఉపయోగిస్తున్నారు, ఎందుకంటే ఏ కొలమానాలు ముఖ్యమైనవి మరియు ఏవి కావు అని గుర్తించడం వారికి సులభం.

DBA బోట్ జో. అనటోలీ స్టాన్స్లర్ (Postgres.ai)

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

సహకారం

DBA బోట్ జో. అనటోలీ స్టాన్స్లర్ (Postgres.ai)

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

DBA బోట్ జో. అనటోలీ స్టాన్స్లర్ (Postgres.ai)

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

డెల్ఫిక్స్ ఉన్నందున పరిష్కారం విప్లవాత్మకమైనది కాదని కూడా గమనించడం ముఖ్యం, కానీ ఇది ఒక సంస్థ పరిష్కారం. ఇది పూర్తిగా మూసివేయబడింది, ఇది చాలా ఖరీదైనది. మేము ప్రత్యేకంగా పోస్ట్‌గ్రెస్‌లో ప్రత్యేకత కలిగి ఉన్నాము. ఇవన్నీ ఓపెన్ సోర్స్ ఉత్పత్తులు. మాతో చేరండి!

ఇక్కడే నేను ముగించాను. ధన్యవాదాలు!

మీ ప్రశ్నలు

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

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

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

అవును, నాకు ఒక సమూహ ప్రశ్న ఉంది. అంటే, మీరు ఈ మాడ్యూళ్ల జీవిత చక్రాన్ని ఎలా నిర్ధారిస్తారు? మాకు ఈ సమస్య మరియు పూర్తి ప్రత్యేక కథ ఉంది. ఇది ఎలా జరుగుతుంది?

ప్రతి క్లోన్‌కి కొంత ttl ఉంటుంది. ప్రాథమికంగా, మనకు స్థిరమైన ttl ఉంది.

రహస్యం కాకపోతే ఏమిటి?

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

నేను టెక్నాలజీల ఎంపికపై కూడా ఆసక్తి కలిగి ఉన్నాను, ఎందుకంటే, ఉదాహరణకు, మేము ఒక కారణం లేదా మరొక కారణంగా సమాంతరంగా అనేక పద్ధతులను ఉపయోగిస్తాము. ZFS ఎందుకు? మీరు LVMని ఎందుకు ఉపయోగించలేదు? LVMతో సమస్యలు ఉన్నాయని మీరు పేర్కొన్నారు. సమస్యలు ఏమిటి? నా అభిప్రాయం ప్రకారం, పనితీరు పరంగా నిల్వతో అత్యంత సరైన ఎంపిక.

ZFSతో ప్రధాన సమస్య ఏమిటి? మీరు తప్పనిసరిగా ఒకే హోస్ట్‌పై అమలు చేయాలి, అంటే అన్ని సందర్భాలు ఒకే OSలో ఉంటాయి. మరియు నిల్వ విషయంలో, మీరు వివిధ పరికరాలను కనెక్ట్ చేయవచ్చు. మరియు అడ్డంకి అనేది నిల్వ సిస్టమ్‌లో ఉన్న బ్లాక్‌లు మాత్రమే. మరియు టెక్నాలజీల ఎంపిక ప్రశ్న ఆసక్తికరంగా ఉంటుంది. ఎందుకు LVM కాదు?

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

నికోలాయ్ సమోఖ్వలోవ్: నేను మరింత వ్యాఖ్యానించవచ్చా? నా పేరు నికోలాయ్, మేము అనాటోలీతో కలిసి పని చేస్తాము. నిల్వ గొప్పదని నేను అంగీకరిస్తున్నాను. మరియు మా కస్టమర్‌లలో కొందరు స్వచ్ఛమైన నిల్వను కలిగి ఉన్నారు.

మేము మాడ్యులారిటీపై దృష్టి సారించామని అనాటోలీ సరిగ్గా పేర్కొన్నాడు. మరియు భవిష్యత్తులో, మీరు ఒక ఇంటర్‌ఫేస్‌ని అమలు చేయవచ్చు - స్నాప్‌షాట్ తీసుకోండి, క్లోన్ చేయండి, క్లోన్‌ను నాశనం చేయండి. ఇది అన్ని సులభం. మరియు నిల్వ ఉంటే చల్లగా ఉంటుంది.

కానీ ZFS అందరికీ అందుబాటులో ఉంది. DelPhix ఇప్పటికే సరిపోతుంది, వారికి 300 మంది క్లయింట్లు ఉన్నారు. వీటిలో, ఫార్చ్యూన్ 100కి 50 మంది క్లయింట్లు ఉన్నారు, అనగా వారు NASA మొదలైనవాటిని లక్ష్యంగా చేసుకున్నారు. ప్రతి ఒక్కరూ ఈ సాంకేతికతను పొందే సమయం ఇది. అందుకే మనకు ఓపెన్ సోర్స్ కోర్ ఉంది. మాకు ఓపెన్ సోర్స్ లేని ఇంటర్‌ఫేస్ భాగం ఉంది. ఇది మేము చూపించే వేదిక. కానీ అందరికీ అందుబాటులో ఉండాలని మేము కోరుకుంటున్నాము. టెస్టర్‌లందరూ ల్యాప్‌టాప్‌లపై ఊహించడం ఆపే విధంగా మేము విప్లవం చేయాలనుకుంటున్నాము. మనం SELECT అని వ్రాసి, అది నెమ్మదిగా ఉందని వెంటనే చూడాలి. DBA దాని గురించి మీకు చెప్పే వరకు వేచి ఉండకండి. ఇక్కడ ప్రధాన లక్ష్యం ఉంది. మరియు మనమందరం దీనికి వస్తామని నేను అనుకుంటున్నాను. మరియు ప్రతి ఒక్కరూ కలిగి ఉండేలా మేము ఈ వస్తువును తయారు చేస్తాము. అందువల్ల ZFS, ఎందుకంటే ఇది ప్రతిచోటా అందుబాటులో ఉంటుంది. సమస్యలను పరిష్కరించినందుకు మరియు ఓపెన్ సోర్స్ లైసెన్స్ మొదలైనవి కలిగి ఉన్నందుకు సంఘానికి ధన్యవాదాలు.*

శుభాకాంక్షలు! నివేదికకు ధన్యవాదాలు! నా పేరు మాగ్జిమ్. మేము అదే సమస్యలతో వ్యవహరించాము. వారే స్వయంగా నిర్ణయించుకున్నారు. మీరు ఈ క్లోన్‌ల మధ్య వనరులను ఎలా పంచుకుంటారు? ప్రతి క్లోన్ ఏ సమయంలోనైనా దాని స్వంత పనిని చేయగలదు: ఒకరు ఒక విషయాన్ని పరీక్షిస్తారు, మరొకరు మరొకరు, ఎవరైనా ఇండెక్స్‌ని నిర్మిస్తారు, ఎవరికైనా భారీ ఉద్యోగం ఉంది. మరియు మీరు ఇప్పటికీ CPU ద్వారా విభజించగలిగితే, IO ద్వారా, మీరు ఎలా విభజించాలి? ఇది మొదటి ప్రశ్న.

మరియు రెండవ ప్రశ్న స్టాండ్‌ల అసమానత గురించి. నేను ఇక్కడ ZFSని కలిగి ఉన్నాను మరియు ప్రతిదీ బాగుంది, కానీ ప్రోడ్‌లోని క్లయింట్‌లో ZFS లేదు, కానీ ext4, ఉదాహరణకు. ఈ సందర్భంలో ఎలా?

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

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

నాకు రెండు ప్రశ్నలు ఉన్నాయి. ఇది చాలా కూల్ స్టఫ్. క్రెడిట్ కార్డ్ నంబర్‌ల వంటి ఉత్పత్తి డేటా కీలకమైన సందర్భాలు ఉన్నాయా? ఇప్పటికే ఏదైనా సిద్ధంగా ఉందా లేదా అది వేరే పని కాదా? మరియు రెండవ ప్రశ్న - MySQL కోసం ఇలాంటిదేమైనా ఉందా?

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

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

కానీ సిస్టమ్ పొడిగించదగినది కనుక, దీనిని MySQL కోసం కూడా ఉపయోగించవచ్చు. మరియు అలాంటి ఉదాహరణలు ఉన్నాయి. Yandex ఇదే విషయాన్ని కలిగి ఉంది, కానీ వారు దానిని ఎక్కడా ప్రచురించరు. వారు దానిని Yandex.Metrica లోపల ఉపయోగిస్తారు. మరియు MySQL గురించి కేవలం ఒక కథ ఉంది. కానీ సాంకేతికతలు ఒకే విధంగా ఉంటాయి, ZFS.

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

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

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

సరే, కొన్ని నిమిషాలు ఆగిపోయేంత భయం లేని సన్నని క్లోన్‌ని తయారు చేద్దాం. మరియు విశ్లేషణలను చదవడం మరింత సౌకర్యవంతంగా చేయడానికి, మేము డేటాపై ఆసక్తి ఉన్న నిలువు వరుసల కోసం సూచికలను జోడిస్తాము.

ప్రతిసారీ సూచిక సృష్టించబడుతుందా?

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

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

ఇక్కడ మరో సమస్య ఉంది. మీరు క్లౌడ్ పరిష్కారాన్ని ఉపయోగిస్తే, అక్కడ లాజికల్ డంప్‌లు మాత్రమే అందుబాటులో ఉంటాయి, ఎందుకంటే Google, Amazon భౌతిక కాపీని తీసుకోవడానికి మిమ్మల్ని అనుమతించవు. సమస్య ఉంటుంది.

నివేదికకు ధన్యవాదాలు. MySQL మరియు వనరుల భాగస్వామ్యం గురించి ఇక్కడ రెండు మంచి ప్రశ్నలు ఉన్నాయి. కానీ, వాస్తవానికి, ఇది నిర్దిష్ట DBMS యొక్క అంశం కాదు, కానీ మొత్తం ఫైల్ సిస్టమ్‌కు సంబంధించినది. మరియు, తదనుగుణంగా, వనరుల భాగస్వామ్య సమస్యలు కూడా పోస్ట్‌గ్రెస్ అని చివరలో కాకుండా ఫైల్ సిస్టమ్‌లో, సర్వర్‌లో, ఉదాహరణకు పరిష్కరించబడాలి.

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

ZFS ఎలా పనిచేస్తుంది కాబట్టి వారు వెళ్లరు. రెప్లికేషన్ వల్ల వచ్చే ఫైల్ సిస్టమ్ మార్పులను మనం ఒక థ్రెడ్‌లో విడిగా ఉంచవచ్చు. మరియు డెవలపర్‌లు ఉపయోగించే క్లోన్‌లను పాత డేటా వెర్షన్‌లలో ఉంచండి. మరియు ఇది మాకు పని చేస్తుంది, ప్రతిదీ ఈ క్రమంలో ఉంది.

నవీకరణ అదనపు లేయర్‌గా జరుగుతుందని మరియు ఈ లేయర్ ఆధారంగా అన్ని కొత్త చిత్రాలు ఇప్పటికే వెళ్తాయని తేలింది, సరియైనదా?

మునుపటి ప్రతిరూపాల నుండి వచ్చిన మునుపటి లేయర్‌ల నుండి.

మునుపటి లేయర్‌లు పడిపోతాయి, కానీ అవి పాత లేయర్‌ని సూచిస్తాయి మరియు నవీకరణలో అందుకున్న చివరి లేయర్ నుండి కొత్త చిత్రాలను తీసుకుంటారా?

సాధారణంగా, అవును.

అప్పుడు పర్యవసానంగా మనం పొరల అత్తి వరకు ఉంటుంది. మరియు కాలక్రమేణా వారు కుదించబడాలి?

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

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

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

శుభ మద్యాహ్నం నివేదికకు ధన్యవాదాలు! నాకు ఒక చిన్న ప్రశ్న ఉంది. కంపెనీ స్లాక్‌ని ఉపయోగించకుంటే, ఇప్పుడు దానికి ఏదైనా బైండింగ్ ఉందా లేదా డేటాబేస్‌లకు టెస్ట్ అప్లికేషన్‌ను కనెక్ట్ చేయడానికి డెవలపర్‌లు ఇన్‌స్టాన్స్‌లను అమలు చేయడం సాధ్యమేనా?

ఇప్పుడు స్లాక్‌కి లింక్ ఉంది, అంటే వేరే మెసెంజర్ లేదు, కానీ నేను నిజంగా ఇతర మెసెంజర్‌లకు కూడా సపోర్ట్ చేయాలనుకుంటున్నాను. నీవు ఏమి చేయగలవు? మీరు జో లేకుండానే DB ల్యాబ్‌ని అమలు చేయవచ్చు, REST API సహాయంతో లేదా మా ప్లాట్‌ఫారమ్ సహాయంతో వెళ్లి క్లోన్‌లను సృష్టించవచ్చు మరియు PSQLతో కనెక్ట్ అవ్వవచ్చు. కానీ మీరు మీ డెవలపర్‌లకు డేటాకు యాక్సెస్ ఇవ్వడానికి సిద్ధంగా ఉంటే ఇది చేయవచ్చు, ఎందుకంటే ఇకపై స్క్రీన్ ఉండదు.

నాకు ఈ పొర అవసరం లేదు, కానీ నాకు అలాంటి అవకాశం అవసరం.

అప్పుడు అవును, అది చేయవచ్చు.

మూలం: www.habr.com

ఒక వ్యాఖ్యను జోడించండి