గమనిక. అనువాదం.: జానా డోగన్ Googleలో అనుభవజ్ఞుడైన ఇంజనీర్, అతను ప్రస్తుతం గోలో వ్రాసిన కంపెనీ ఉత్పత్తి సేవలను పరిశీలించడానికి పని చేస్తున్నాడు. ఇంగ్లీష్ మాట్లాడే ప్రేక్షకులలో గొప్ప ప్రజాదరణ పొందిన ఈ కథనంలో, ఆమె పెద్ద/డిమాండింగ్ అప్లికేషన్‌ల డెవలపర్‌ల కోసం పరిగణలోకి తీసుకోవడానికి ఉపయోగపడే DBMSలకు (మరియు కొన్నిసార్లు పంపిణీ చేయబడిన వ్యవస్థలు సాధారణంగా) సంబంధించి 17 పాయింట్ల ముఖ్యమైన సాంకేతిక వివరాలను సేకరించింది.
చాలా వరకు కంప్యూటర్ సిస్టమ్‌లు వాటి స్థితిని ట్రాక్ చేస్తాయి మరియు తదనుగుణంగా, ఒకరకమైన డేటా నిల్వ వ్యవస్థ అవసరం. నేను చాలా కాలం పాటు డేటాబేస్‌ల గురించి జ్ఞానాన్ని కూడగట్టుకున్నాను, అలాగే డేటా నష్టం మరియు అంతరాయాలకు దారితీసిన డిజైన్ పొరపాట్లు చేయడం. పెద్ద మొత్తంలో సమాచారాన్ని ప్రాసెస్ చేసే సిస్టమ్‌లలో, డేటాబేస్‌లు సిస్టమ్ ఆర్కిటెక్చర్ యొక్క గుండె వద్ద ఉంటాయి మరియు సరైన పరిష్కారాన్ని ఎంచుకోవడంలో కీలక అంశంగా పనిచేస్తాయి. డేటాబేస్ యొక్క పనిపై చాలా శ్రద్ధ చూపుతున్నప్పటికీ, అప్లికేషన్ డెవలపర్లు ఊహించడానికి ప్రయత్నించే సమస్యలు తరచుగా మంచుకొండ యొక్క కొన మాత్రమే. ఈ కథనాల శ్రేణిలో, ఈ రంగంలో నైపుణ్యం లేని డెవలపర్‌లకు ఉపయోగపడే కొన్ని ఆలోచనలను నేను పంచుకుంటాను.
- 99,999% సమయం నెట్‌వర్క్ సమస్యలను కలిగించకపోతే మీరు అదృష్టవంతులు.
- ACID అంటే చాలా విభిన్న విషయాలు.
- ప్రతి డేటాబేస్ స్థిరత్వం మరియు ఐసోలేషన్‌ను నిర్ధారించడానికి దాని స్వంత యంత్రాంగాలను కలిగి ఉంటుంది.
- సాధారణమైన దానిని నిర్వహించడం కష్టంగా ఉన్నప్పుడు ఆశావాద నిరోధం రక్షించబడుతుంది.
- డర్టీ రీడ్‌లు మరియు డేటా నష్టంతో పాటు ఇతర క్రమరాహిత్యాలు కూడా ఉన్నాయి.
- చర్య యొక్క కోర్సుపై డేటాబేస్ మరియు వినియోగదారు ఎల్లప్పుడూ అంగీకరించరు.
- అప్లికేషన్-స్థాయి షార్డింగ్‌ను అప్లికేషన్ వెలుపల తరలించవచ్చు.
- ఆటోఇన్‌క్రిమెంటింగ్ ప్రమాదకరం.
- పాత డేటా ఉపయోగకరంగా ఉంటుంది మరియు లాక్ చేయవలసిన అవసరం లేదు.
- వక్రీకరణలు ఏ సమయ మూలాలకైనా విలక్షణమైనవి.
- ఆలస్యం అనే పదానికి చాలా అర్థాలు ఉన్నాయి.
- నిర్దిష్ట లావాదేవీ కోసం పనితీరు అవసరాలు మూల్యాంకనం చేయాలి.
- సమీకృత లావాదేవీలు ప్రమాదకరమైనవి కావచ్చు.
- లావాదేవీలు అప్లికేషన్ స్థితితో ముడిపడి ఉండకూడదు.
- క్వెరీ ప్లానర్‌లు మీకు డేటాబేస్‌ల గురించి చాలా చెప్పగలరు.
- ఆన్‌లైన్ మైగ్రేషన్ కష్టం, కానీ సాధ్యమే.
- డేటాబేస్లో గణనీయమైన పెరుగుదల అనూహ్యతను పెంచుతుంది.
ఈ కథనం యొక్క మునుపటి సంస్కరణపై వారి అభిప్రాయానికి నేను ఇమ్మాన్యుయేల్ ఒడెకే, రెయిన్ హెన్రిచ్స్ మరియు ఇతరులకు ధన్యవాదాలు చెప్పాలనుకుంటున్నాను.
99,999% సమయం నెట్‌వర్క్ సమస్యలను కలిగించకపోతే మీరు అదృష్టవంతులు.
ఆధునిక నెట్‌వర్క్ సాంకేతికతలు ఎంత నమ్మదగినవి మరియు నెట్‌వర్క్ వైఫల్యాల కారణంగా సిస్టమ్‌లు ఎంత తరచుగా డౌన్ అవుతాయి అనే ప్రశ్న మిగిలి ఉంది. ఈ సమస్యపై సమాచారం చాలా తక్కువగా ఉంటుంది మరియు ప్రత్యేక నెట్‌వర్క్‌లు, పరికరాలు మరియు సిబ్బందితో కూడిన పెద్ద సంస్థలచే పరిశోధన తరచుగా ఆధిపత్యం చెలాయిస్తుంది.
స్పానర్ (గూగుల్ యొక్క ప్రపంచవ్యాప్తంగా పంపిణీ చేయబడిన డేటాబేస్) కోసం 99,999% లభ్యత రేటుతో, Google క్లెయిమ్ చేస్తుంది సమస్యలు నెట్‌వర్క్‌కు సంబంధించినవి. అదే సమయంలో, కంపెనీ తన ప్రత్యేక నెట్‌వర్క్‌ను అధిక లభ్యత యొక్క "ప్రధాన స్తంభం" అని పిలుస్తుంది. చదువు , 2014లో నిర్వహించబడింది, "", దీనిని పీటర్ డ్యూచ్ 1994లో రూపొందించారు. నెట్‌వర్క్ నిజంగా నమ్మదగినదేనా?
విస్తృత ఇంటర్నెట్ కోసం నిర్వహించబడిన దిగ్గజం కంపెనీల వెలుపల సమగ్ర పరిశోధన కేవలం ఉనికిలో లేదు. ప్రధాన ఆటగాళ్ల నుండి వారి కస్టమర్ల సమస్యలు ఎంత శాతం నెట్‌వర్క్‌కు సంబంధించినవి అనే దాని గురించి తగినంత డేటా కూడా లేదు. పెద్ద క్లౌడ్ ప్రొవైడర్ల నెట్‌వర్క్ స్టాక్‌లోని అంతరాయాలను గురించి మాకు బాగా తెలుసు. నెట్‌వర్క్ అంతరాయాలు చాలా సందర్భాలలో సమస్యలను కలిగిస్తాయి, ఆ కేసులన్నీ దృష్టిలో లేనప్పటికీ. క్లౌడ్ సేవల ఖాతాదారులకు సమస్యల కారణాల గురించి కూడా ఏమీ తెలియదు. వైఫల్యం ఉన్నట్లయితే, సర్వీస్ ప్రొవైడర్ వైపున ఉన్న నెట్‌వర్క్ లోపానికి దానిని ఆపాదించడం దాదాపు అసాధ్యం. వారికి, మూడవ పార్టీ సేవలు బ్లాక్ బాక్స్‌లు. పెద్ద సర్వీస్ ప్రొవైడర్ లేకుండా ప్రభావాన్ని అంచనా వేయడం అసాధ్యం.
పెద్ద ప్లేయర్‌లు తమ సిస్టమ్‌ల గురించి నివేదించిన దాని ప్రకారం, నెట్‌వర్క్ ఇబ్బందులు తక్కువ శాతాన్ని మాత్రమే డౌన్‌టైమ్ సమస్యలకు కారణమైతే మీరు అదృష్టవంతులు అని చెప్పడం సురక్షితం. నెట్‌వర్క్ కమ్యూనికేషన్‌లు ఇప్పటికీ హార్డ్‌వేర్ వైఫల్యాలు, టోపోలాజీ మార్పులు, అడ్మినిస్ట్రేటివ్ కాన్ఫిగరేషన్ మార్పులు మరియు పవర్ అంతరాయాలు వంటి ప్రాపంచిక విషయాలతో బాధపడుతున్నాయి. ఇటీవల, సాధ్యమయ్యే సమస్యల జాబితా జోడించబడిందని తెలుసుకుని నేను ఆశ్చర్యపోయాను (అవును, మీరు విన్నది నిజమే).
ACID అంటే చాలా భిన్నమైన విషయాలు
ACID ఎక్రోనిం అంటే అటామిసిటీ, కన్సిస్టెన్సీ, ఐసోలేషన్, రిలయబిలిటీ. లావాదేవీల యొక్క ఈ లక్షణాలు వైఫల్యాలు, లోపాలు, హార్డ్‌వేర్ వైఫల్యాలు మొదలైన వాటి యొక్క చెల్లుబాటును నిర్ధారించడానికి ఉద్దేశించబడ్డాయి. ACID లేదా ఇలాంటి స్కీమ్‌లు లేకుండా, అప్లికేషన్ డెవలపర్లు దేనికి బాధ్యత వహిస్తారు మరియు డేటాబేస్ దేనికి బాధ్యత వహిస్తారు అనే దాని మధ్య తేడాను గుర్తించడం కష్టం. చాలా రిలేషనల్ లావాదేవీల డేటాబేస్‌లు ACID కంప్లైంట్‌గా ఉండటానికి ప్రయత్నిస్తాయి, అయితే NoSQL వంటి కొత్త విధానాలు ACID లావాదేవీలు లేకుండా అనేక డేటాబేస్‌లకు దారితీశాయి ఎందుకంటే అవి అమలు చేయడానికి ఖరీదైనవి.
నేను పరిశ్రమలోకి ప్రవేశించినప్పుడు, మా టెక్నికల్ లీడ్ ACID కాన్సెప్ట్ ఎంత సందర్భోచితంగా ఉంది అనే దాని గురించి మాట్లాడింది. నిజం చెప్పాలంటే, ACID అనేది కఠినమైన అమలు ప్రమాణంగా కాకుండా స్థూల వివరణగా పరిగణించబడుతుంది. ఈ రోజు నేను దీనిని చాలా ఉపయోగకరంగా భావిస్తున్నాను ఎందుకంటే ఇది ఒక నిర్దిష్ట వర్గ సమస్యలను లేవనెత్తుతుంది (మరియు సాధ్యమయ్యే పరిష్కారాల శ్రేణిని సూచిస్తుంది).
ప్రతి DBMS ACID కంప్లైంట్ కాదు; అదే సమయంలో, ACIDకి మద్దతిచ్చే డేటాబేస్ ఇంప్లిమెంటేషన్‌లు అవసరాల సమితిని విభిన్నంగా అర్థం చేసుకుంటాయి. ACID అమలులు అస్తవ్యస్తంగా ఉండటానికి ఒక కారణం, ACID అవసరాలను అమలు చేయడానికి అనేక ట్రేడ్-ఆఫ్‌లు చేయాల్సి ఉంటుంది. సృష్టికర్తలు తమ డేటాబేస్‌లను ACID-కంప్లైంట్‌గా ప్రదర్శించవచ్చు, కానీ ఎడ్జ్ కేసుల యొక్క వివరణ నాటకీయంగా మారవచ్చు, అలాగే "అసంభవ" ఈవెంట్‌లను నిర్వహించడానికి మెకానిజం కూడా మారవచ్చు. కనీసం, డెవలపర్లు వారి ప్రత్యేక ప్రవర్తన మరియు డిజైన్ ట్రేడ్-ఆఫ్‌ల గురించి సరైన అవగాహన పొందడానికి బేస్ ఇంప్లిమెంటేషన్‌ల యొక్క చిక్కుల గురించి ఉన్నత-స్థాయి అవగాహనను పొందవచ్చు.
MongoDB ACID అవసరాలకు అనుగుణంగా ఉందా లేదా అనే చర్చ వెర్షన్ 4 విడుదల తర్వాత కూడా కొనసాగుతుంది. MongoDBకి చాలా కాలంగా మద్దతు లేదు , డిఫాల్ట్‌గా డేటా ప్రతి 60 సెకన్లకు ఒకసారి కంటే ఎక్కువసార్లు డిస్క్‌కు కట్టుబడి ఉంటుంది. కింది దృష్టాంతాన్ని ఊహించండి: ఒక అప్లికేషన్ రెండు వ్రాతలను పోస్ట్ చేస్తుంది (w1 మరియు w2). MongoDB w1ని విజయవంతంగా నిల్వ చేస్తుంది, కానీ హార్డ్‌వేర్ వైఫల్యం కారణంగా w2 పోతుంది.
దృష్టాంతాన్ని వివరించే రేఖాచిత్రం. MongoDB డిస్క్‌కి డేటాను వ్రాయడానికి ముందే క్రాష్ అవుతుంది
డిస్క్‌కు కట్టుబడి ఉండటం ఖరీదైన ప్రక్రియ. తరచుగా చేసే కమిట్‌లను నివారించడం ద్వారా, డెవలపర్లు విశ్వసనీయత కారణంగా రికార్డింగ్ పనితీరును మెరుగుపరుస్తారు. MongoDB ప్రస్తుతం లాగింగ్‌కు మద్దతు ఇస్తుంది, అయితే లాగ్‌లు డిఫాల్ట్‌గా ప్రతి 100ms క్యాప్చర్ చేయబడినందున డర్టీ రైట్‌లు ఇప్పటికీ డేటా సమగ్రతను ప్రభావితం చేస్తాయి. అంటే, ప్రమాదం చాలా తక్కువగా ఉన్నప్పటికీ, లాగ్‌లు మరియు వాటిలో సమర్పించబడిన మార్పులకు ఇదే విధమైన దృశ్యం ఇప్పటికీ సాధ్యమే.
ప్రతి డేటాబేస్ దాని స్వంత స్థిరత్వం మరియు ఐసోలేషన్ మెకానిజమ్‌లను కలిగి ఉంటుంది
ACID అవసరాలలో, స్థిరత్వం మరియు ఐసోలేషన్ అత్యధిక సంఖ్యలో వివిధ అమలులను కలిగి ఉన్నాయి, ఎందుకంటే ట్రేడ్-ఆఫ్‌ల పరిధి విస్తృతంగా ఉంటుంది. స్థిరత్వం మరియు ఒంటరితనం చాలా ఖరీదైన విధులు అని చెప్పాలి. వాటికి సమన్వయం అవసరం మరియు డేటా స్థిరత్వం కోసం పోటీని పెంచుతుంది. బహుళ డేటా కేంద్రాలలో (ముఖ్యంగా అవి వేర్వేరు భౌగోళిక ప్రాంతాలలో ఉన్నట్లయితే) డేటాబేస్‌ను అడ్డంగా స్కేల్ చేయడానికి అవసరమైనప్పుడు సమస్య యొక్క సంక్లిష్టత గణనీయంగా పెరుగుతుంది. అధిక స్థాయి స్థిరత్వాన్ని సాధించడం చాలా కష్టం, ఎందుకంటే ఇది లభ్యతను తగ్గిస్తుంది మరియు నెట్‌వర్క్ విభజనను పెంచుతుంది. ఈ దృగ్విషయం యొక్క మరింత సాధారణ వివరణ కోసం, నేను మీకు సూచించమని సలహా ఇస్తున్నాను . అప్లికేషన్‌లు చిన్న మొత్తంలో అస్థిరతను నిర్వహించగలవని మరియు ప్రోగ్రామర్లు డేటాబేస్‌పై ఎక్కువగా ఆధారపడకుండా అస్థిరతను నిర్వహించడానికి అప్లికేషన్‌లో అదనపు లాజిక్‌ను అమలు చేయడానికి తగినంతగా సమస్య యొక్క సూక్ష్మ నైపుణ్యాలను అర్థం చేసుకోగలరని కూడా గమనించాలి.
DBMSలు తరచుగా వివిధ స్థాయిల ఐసోలేషన్‌ను అందిస్తాయి. అప్లికేషన్ డెవలపర్లు వారి ప్రాధాన్యతల ఆధారంగా అత్యంత ప్రభావవంతమైనదాన్ని ఎంచుకోవచ్చు. తక్కువ ఐసోలేషన్ వేగాన్ని పెంచడానికి అనుమతిస్తుంది, కానీ డేటా రేస్ ప్రమాదాన్ని కూడా పెంచుతుంది. అధిక ఇన్సులేషన్ ఈ సంభావ్యతను తగ్గిస్తుంది, కానీ పనిని తగ్గిస్తుంది మరియు పోటీకి దారి తీస్తుంది, ఇది వైఫల్యాలు ప్రారంభమయ్యే బేస్లో ఇటువంటి బ్రేక్లకు దారి తీస్తుంది.
ఇప్పటికే ఉన్న కాన్కరెన్సీ మోడల్స్ మరియు వాటి మధ్య సంబంధాల సమీక్ష
SQL ప్రమాణం కేవలం నాలుగు ఐసోలేషన్ స్థాయిలను మాత్రమే నిర్వచిస్తుంది, అయితే సిద్ధాంతం మరియు ఆచరణలో ఇంకా చాలా ఉన్నాయి. ఇప్పటికే ఉన్న కాన్కరెన్సీ మోడల్‌ల యొక్క అద్భుతమైన అవలోకనాన్ని అందిస్తుంది. ఉదాహరణకు, Google Spanner క్లాక్ సింక్రొనైజేషన్‌తో బాహ్య సీరియలైజేషన్‌కు హామీ ఇస్తుంది మరియు ఇది కఠినమైన ఐసోలేషన్ లేయర్ అయినప్పటికీ, ఇది ప్రామాణిక ఐసోలేషన్ లేయర్‌లలో నిర్వచించబడలేదు.
SQL ప్రమాణం క్రింది ఐసోలేషన్ స్థాయిలను సూచిస్తుంది:
- సీరియలైజబుల్ (అత్యంత కఠినమైన మరియు ఖరీదైనది): సీరియలైజబుల్ ఎగ్జిక్యూషన్ కొన్ని సీక్వెన్షియల్ లావాదేవీల అమలుతో సమానమైన ప్రభావాన్ని కలిగి ఉంటుంది. సీక్వెన్షియల్ ఎగ్జిక్యూషన్ అంటే ప్రతి తదుపరి లావాదేవీ మునుపటిది పూర్తయిన తర్వాత మాత్రమే ప్రారంభమవుతుంది. స్థాయి అని గమనించాలి సీరియలైజబుల్ వివరణలో తేడాల కారణంగా తరచుగా స్నాప్‌షాట్ ఐసోలేషన్ అని పిలవబడే (ఉదాహరణకు, ఒరాకిల్‌లో) అమలు చేయబడుతుంది, అయినప్పటికీ స్నాప్‌షాట్ ఐసోలేషన్ అనేది SQL ప్రమాణంలో సూచించబడదు.
- పునరావృతమయ్యే రీడ్‌లు: ప్రస్తుత లావాదేవీలో నిబద్ధత లేని రికార్డులు ప్రస్తుత లావాదేవీకి అందుబాటులో ఉన్నాయి, కానీ ఇతర లావాదేవీల ద్వారా చేసిన మార్పులు (కొత్త వరుసలు వంటివి) .
- నిబద్ధతతో చదివారు: లావాదేవీలకు కట్టుబడి లేని డేటా అందుబాటులో లేదు. ఈ సందర్భంలో, లావాదేవీలు కట్టుబడి ఉన్న డేటాను మాత్రమే చూడగలవు మరియు ఫాంటమ్ రీడ్‌లు సంభవించవచ్చు. లావాదేవీ కొత్త అడ్డు వరుసలను చొప్పించి, కట్టుబడి ఉంటే, ప్రస్తుత లావాదేవీని ప్రశ్నించినప్పుడు వాటిని చూడగలుగుతారు.
- నిబద్ధత లేకుండా చదవండి (కనీసం కఠినమైన మరియు ఖరీదైన స్థాయి): డర్టీ రీడ్‌లు అనుమతించబడతాయి, లావాదేవీలు ఇతర లావాదేవీల ద్వారా చేయని మార్పులను చూడగలవు. ఆచరణలో, ఈ స్థాయి ప్రశ్నల వంటి స్థూల అంచనాలకు ఉపయోగపడుతుంది
COUNT(*)బల్ల మీద.
స్థాయి సీరియలైజబుల్ డేటా రేసుల ప్రమాదాన్ని తగ్గిస్తుంది, అదే సమయంలో అమలు చేయడానికి అత్యంత ఖరీదైనది మరియు సిస్టమ్‌పై అత్యధిక పోటీ భారాన్ని కలిగిస్తుంది. ఇతర ఐసోలేషన్ స్థాయిలు అమలు చేయడం సులభం, కానీ డేటా రేసుల సంభావ్యతను పెంచుతాయి. కొన్ని DBMSలు అనుకూల ఐసోలేషన్ స్థాయిని సెట్ చేయడానికి మిమ్మల్ని అనుమతిస్తాయి, మరికొన్ని బలమైన ప్రాధాన్యతలను కలిగి ఉంటాయి మరియు అన్ని స్థాయిలు మద్దతు ఇవ్వవు.
ఐసోలేషన్ స్థాయిలకు మద్దతు ఇవ్వబడిన DBMSలో తరచుగా ప్రచారం చేయబడుతుంది, అయితే దాని ప్రవర్తనను జాగ్రత్తగా అధ్యయనం చేయడం మాత్రమే వాస్తవానికి ఏమి జరుగుతుందో వెల్లడిస్తుంది.
విభిన్న DBMSల కోసం వేర్వేరు ఐసోలేషన్ స్థాయిలలో కాన్కరెన్సీ క్రమరాహిత్యాల సమీక్ష
మార్టిన్ క్లెప్‌మాన్ తన ప్రాజెక్ట్‌లో విభిన్న ఐసోలేషన్ స్థాయిలను పోల్చి, కాన్కరెన్సీ క్రమరాహిత్యాల గురించి మాట్లాడుతుంది మరియు డేటాబేస్ నిర్దిష్ట ఐసోలేషన్ స్థాయికి కట్టుబడి ఉండగలదా. క్లెప్‌మాన్ పరిశోధన డేటాబేస్ డెవలపర్లు ఐసోలేషన్ స్థాయిల గురించి ఎంత భిన్నంగా ఆలోచిస్తున్నారో చూపిస్తుంది.
సాధారణమైన దానిని నిర్వహించడం కష్టంగా ఉన్నప్పుడు ఆశావాద నిరోధం రక్షించబడుతుంది.
బ్లాక్ చేయడం చాలా ఖరీదైనది, ఎందుకంటే ఇది డేటాబేస్లో పోటీని పెంచడమే కాకుండా, అప్లికేషన్ సర్వర్లు డేటాబేస్‌కు నిరంతరం కనెక్ట్ అవ్వడం అవసరం కాబట్టి. నెట్‌వర్క్ సెగ్మెంటేషన్ ప్రత్యేకమైన లాకింగ్ పరిస్థితులను మరింత తీవ్రతరం చేస్తుంది మరియు గుర్తించడం మరియు పరిష్కరించడం కష్టతరమైన డెడ్‌లాక్‌లకు దారి తీస్తుంది. ప్రత్యేకమైన లాకింగ్ సరిపోని సందర్భాల్లో, ఆశావాద లాకింగ్ సహాయపడుతుంది.
స్ట్రింగ్‌ను చదివేటప్పుడు, అది దాని వెర్షన్, చెక్‌సమ్ లేదా చివరి సవరణ సమయాన్ని పరిగణనలోకి తీసుకునే పద్ధతి. ఎంట్రీని మార్చడానికి ముందు అటామిక్ వెర్షన్ మార్పు లేదని నిర్ధారించుకోవడానికి ఇది మిమ్మల్ని అనుమతిస్తుంది:
UPDATE products
SET name = 'Telegraph receiver', version = 2
WHERE id = 1 AND version = 1
ఈ సందర్భంలో, పట్టికను నవీకరిస్తోంది products ఇంతకు ముందు ఈ వరుసలో మరొక ఆపరేషన్ మార్పులు చేసినట్లయితే అమలు చేయబడదు. ఈ అడ్డు వరుసలో ఇతర కార్యకలాపాలు ఏవీ చేయకుంటే, ఒక అడ్డు వరుసకు మార్పు జరుగుతుంది మరియు నవీకరణ విజయవంతమైందని మేము చెప్పగలం.
డర్టీ రీడ్‌లు మరియు డేటా నష్టంతో పాటు ఇతర క్రమరాహిత్యాలు కూడా ఉన్నాయి
డేటా అనుగుణ్యత విషయానికి వస్తే, డర్టీ రీడ్‌లు మరియు డేటా నష్టానికి దారితీసే జాతి పరిస్థితుల సంభావ్యతపై దృష్టి కేంద్రీకరించబడుతుంది. అయితే, డేటా క్రమరాహిత్యాలు అక్కడ ఆగవు.
అటువంటి క్రమరాహిత్యాలకు ఒక ఉదాహరణ రికార్డింగ్ వక్రీకరణ (వక్రతలను వ్రాయండి). వక్రీకరణలను గుర్తించడం కష్టం ఎందుకంటే అవి సాధారణంగా చురుకుగా వెతకవు. అవి డర్టీ రీడ్‌లు లేదా డేటా నష్టం వల్ల కాదు, డేటాపై ఉంచబడిన తార్కిక పరిమితుల ఉల్లంఘనల వల్ల.
ఉదాహరణకు, అన్ని సమయాల్లో ఒక ఆపరేటర్ ఆన్-కాల్‌గా ఉండాల్సిన పర్యవేక్షణ అప్లికేషన్‌ను పరిశీలిద్దాం:
BEGIN tx1; BEGIN tx2;
SELECT COUNT(*)
FROM operators
WHERE oncall = true;
0 SELECT COUNT(*)
FROM operators
WHERE oncall = TRUE;
0
UPDATE operators UPDATE operators
SET oncall = TRUE SET oncall = TRUE
WHERE userId = 4; WHERE userId = 2;
COMMIT tx1; COMMIT tx2;పై పరిస్థితిలో, రెండు లావాదేవీలు విజయవంతంగా కట్టుబడి ఉంటే రికార్డు అవినీతి జరుగుతుంది. డర్టీ రీడ్‌లు లేదా డేటా నష్టం లేనప్పటికీ, డేటా యొక్క సమగ్రత రాజీ పడింది: ఇప్పుడు ఇద్దరు వ్యక్తులు ఒకే సమయంలో ఆన్-కాల్‌గా పరిగణించబడ్డారు.
సీరియలైజ్ చేయదగిన ఐసోలేషన్, స్కీమా డిజైన్ లేదా డేటాబేస్ పరిమితులు వ్రాత అవినీతిని తొలగించడంలో సహాయపడతాయి. ఉత్పత్తిలో వాటిని నివారించడానికి డెవలపర్లు అభివృద్ధి సమయంలో ఇటువంటి క్రమరాహిత్యాలను గుర్తించగలగాలి. అదే సమయంలో, రికార్డింగ్ వక్రీకరణలు కోడ్ బేస్లో చూడటం చాలా కష్టం. ప్రత్యేకించి పెద్ద సిస్టమ్‌లలో, ఒకే టేబుల్‌ల ఆధారంగా ఫంక్షన్‌లను అమలు చేయడానికి వివిధ అభివృద్ధి బృందాలు బాధ్యత వహిస్తున్నప్పుడు మరియు డేటా యాక్సెస్ యొక్క ప్రత్యేకతలను అంగీకరించనప్పుడు.
ఏమి చేయాలో డేటాబేస్ మరియు వినియోగదారు ఎల్లప్పుడూ అంగీకరించరు
డేటాబేస్‌ల యొక్క ముఖ్య లక్షణాలలో ఒకటి ఎగ్జిక్యూషన్ ఆర్డర్ యొక్క హామీ, అయితే ఈ ఆర్డర్ సాఫ్ట్‌వేర్ డెవలపర్‌కు పారదర్శకంగా ఉండకపోవచ్చు. డేటాబేస్‌లు ప్రోగ్రామర్లు ఉద్దేశించిన క్రమంలో కాకుండా, అందుకున్న క్రమంలో లావాదేవీలను అమలు చేస్తాయి. లావాదేవీల క్రమాన్ని అంచనా వేయడం కష్టం, ముఖ్యంగా అధిక లోడ్ చేయబడిన సమాంతర వ్యవస్థలలో.
అభివృద్ధి సమయంలో, ప్రత్యేకించి నాన్-బ్లాకింగ్ లైబ్రరీలతో పని చేస్తున్నప్పుడు, పేలవమైన శైలి మరియు తక్కువ రీడబిలిటీ కారణంగా లావాదేవీలు వరుసగా అమలు చేయబడతాయని వినియోగదారులు విశ్వసించవచ్చు, వాస్తవానికి అవి ఏ క్రమంలోనైనా డేటాబేస్‌లోకి వస్తాయి.
మొదటి చూపులో, దిగువ ప్రోగ్రామ్‌లో, T1 మరియు T2 వరుసగా పిలువబడతాయి, అయితే ఈ ఫంక్షన్‌లు నిరోధించబడకపోతే మరియు వెంటనే ఫలితాన్ని రూపంలో తిరిగి ఇవ్వండి , అప్పుడు కాల్‌ల క్రమం వారు డేటాబేస్‌లోకి ప్రవేశించిన క్షణాల ద్వారా నిర్ణయించబడుతుంది:
ఫలితం1 = T1() // నిజమైన ఫలితాలు వాగ్దానాలు
ఫలితం2 = T2()
పరమాణుత్వం అవసరమైతే (అంటే, అన్ని కార్యకలాపాలను పూర్తి చేయాలి లేదా రద్దు చేయాలి) మరియు క్రమం ముఖ్యమైనది అయితే, T1 మరియు T2 ఆపరేషన్‌లను ఒకే లావాదేవీలో నిర్వహించాలి.
అప్లికేషన్-స్థాయి షార్డింగ్‌ను అప్లికేషన్ వెలుపల తరలించవచ్చు
షార్డింగ్ అనేది డేటాబేస్‌ను క్షితిజ సమాంతరంగా విభజించే పద్ధతి. కొన్ని డేటాబేస్‌లు స్వయంచాలకంగా డేటాను క్షితిజ సమాంతరంగా విభజించగలవు, మరికొందరు చేయలేరు లేదా చాలా మంచివి కావు. డేటా ఆర్కిటెక్ట్‌లు/డెవలపర్లు డేటా ఎలా యాక్సెస్ చేయబడుతుందో ఖచ్చితంగా అంచనా వేయగలిగినప్పుడు, వారు ఈ పనిని డేటాబేస్‌కు అప్పగించడానికి బదులుగా వినియోగదారు స్థలంలో క్షితిజ సమాంతర విభజనలను సృష్టించగలరు. ఈ ప్రక్రియను "అప్లికేషన్-స్థాయి షార్డింగ్" అంటారు. (అప్లికేషన్-స్థాయి షార్డింగ్).
దురదృష్టవశాత్తూ, ఈ పేరు తరచుగా అప్లికేషన్ సేవల్లో నివసిస్తుందనే అపోహను సృష్టిస్తుంది. వాస్తవానికి, ఇది డేటాబేస్ ముందు ప్రత్యేక పొరగా అమలు చేయబడుతుంది. డేటా పెరుగుదల మరియు స్కీమా పునరావృతాలపై ఆధారపడి, షేడింగ్ అవసరాలు చాలా క్లిష్టంగా మారవచ్చు. కొన్ని వ్యూహాలు అప్లికేషన్ సర్వర్‌లను మళ్లీ అమలు చేయకుండా పునరావృతం చేయగల సామర్థ్యం నుండి ప్రయోజనం పొందవచ్చు.
అప్లికేషన్ సర్వర్లు షార్డింగ్ సేవ నుండి వేరు చేయబడిన ఆర్కిటెక్చర్ యొక్క ఉదాహరణ
షార్డింగ్‌ని ప్రత్యేక సేవలోకి తరలించడం వలన అప్లికేషన్‌లను మళ్లీ అమర్చాల్సిన అవసరం లేకుండానే విభిన్న భాగస్వామ్య వ్యూహాలను ఉపయోగించే సామర్థ్యాన్ని విస్తరిస్తుంది. అప్లికేషన్ స్థాయిలో అటువంటి షార్డింగ్ సిస్టమ్‌కి ఉదాహరణ. Vitess MySQL కోసం క్షితిజ సమాంతర భాగస్వామ్యాన్ని అందిస్తుంది మరియు MySQL ప్రోటోకాల్ ద్వారా క్లయింట్‌లను దానికి కనెక్ట్ చేయడానికి అనుమతిస్తుంది. సిస్టమ్ డేటాను ఒకదానికొకటి ఏమీ తెలియని విభిన్న MySQL నోడ్‌లుగా విభజిస్తుంది.
ఆటోఇన్‌క్రిమెంటింగ్ ప్రమాదకరం
AUTOINCREMENT అనేది ప్రాథమిక కీలను రూపొందించడానికి ఒక సాధారణ మార్గం. డేటాబేస్‌లను ID జనరేటర్‌లుగా ఉపయోగించినప్పుడు తరచుగా సందర్భాలు ఉన్నాయి మరియు డేటాబేస్ ఐడెంటిఫైయర్‌లను రూపొందించడానికి రూపొందించిన పట్టికలను కలిగి ఉంటుంది. ఆటో-ఇంక్రిమెంటింగ్‌ని ఉపయోగించి ప్రాథమిక కీలను రూపొందించడం ఆదర్శానికి దూరంగా ఉండటానికి అనేక కారణాలు ఉన్నాయి:
- పంపిణీ చేయబడిన డేటాబేస్లో, స్వీయ-పెంపు అనేది తీవ్రమైన సమస్య. IDని రూపొందించడానికి, గ్లోబల్ లాక్ అవసరం. బదులుగా, మీరు UUIDని రూపొందించవచ్చు: దీనికి వివిధ డేటాబేస్ నోడ్‌ల మధ్య పరస్పర చర్య అవసరం లేదు. లాక్‌లతో స్వయంచాలకంగా పెంచడం వివాదానికి దారి తీస్తుంది మరియు పంపిణీ చేయబడిన పరిస్థితుల్లో ఇన్‌సర్ట్‌లపై పనితీరును గణనీయంగా తగ్గిస్తుంది. కొన్ని DBMSలు (ఉదాహరణకు, MySQL) మాస్టర్-మాస్టర్ రెప్లికేషన్‌ను సరిగ్గా నిర్వహించడానికి ప్రత్యేక కాన్ఫిగరేషన్ మరియు మరింత జాగ్రత్తగా శ్రద్ధ వహించాల్సి ఉంటుంది. మరియు కాన్ఫిగర్ చేసేటప్పుడు తప్పులు చేయడం సులభం, ఇది రికార్డింగ్ వైఫల్యాలకు దారి తీస్తుంది.
- కొన్ని డేటాబేస్‌లు ప్రాథమిక కీల ఆధారంగా విభజన అల్గారిథమ్‌లను కలిగి ఉంటాయి. వరుస IDలు ఊహించలేని హాట్ స్పాట్‌లకు దారి తీయవచ్చు మరియు కొన్ని విభజనలపై లోడ్ పెరగవచ్చు, మరికొన్ని నిష్క్రియంగా ఉంటాయి.
- ప్రాథమిక కీ అనేది డేటాబేస్లో అడ్డు వరుసను యాక్సెస్ చేయడానికి వేగవంతమైన మార్గం. రికార్డులను గుర్తించడానికి మెరుగైన మార్గాలతో, సీక్వెన్షియల్ IDలు టేబుల్‌లలోని అత్యంత ముఖ్యమైన కాలమ్‌ను అర్థరహిత విలువలతో నిండిన పనికిరాని కాలమ్‌గా మార్చగలవు. కాబట్టి, సాధ్యమైనప్పుడల్లా, దయచేసి ప్రపంచవ్యాప్తంగా ప్రత్యేకమైన మరియు సహజమైన ప్రాథమిక కీని ఎంచుకోండి (ఉదా. వినియోగదారు పేరు).
విధానాన్ని నిర్ణయించే ముందు, స్వయంచాలకంగా పెంచే IDలు మరియు UUIDల ఇండెక్సింగ్, విభజన మరియు షార్డింగ్‌ల ప్రభావాన్ని పరిగణించండి.
పాత డేటా ఉపయోగకరంగా ఉంటుంది మరియు లాకింగ్ అవసరం లేదు
మల్టీవర్షన్ కరెన్సీ కంట్రోల్ (MVCC) పైన క్లుప్తంగా చర్చించబడిన అనేక స్థిరత్వ అవసరాలను అమలు చేస్తుంది. కొన్ని డేటాబేస్‌లు (ఉదాహరణకు, పోస్ట్‌గ్రెస్, స్పానర్) స్నాప్‌షాట్‌లతో లావాదేవీలను "ఫీడ్" చేయడానికి MVCCని ఉపయోగిస్తాయి—డేటాబేస్ యొక్క పాత సంస్కరణలు. స్థిరత్వాన్ని నిర్ధారించడానికి స్నాప్‌షాట్ లావాదేవీలను కూడా క్రమీకరించవచ్చు. పాత స్నాప్‌షాట్ నుండి చదువుతున్నప్పుడు, పాత డేటా చదవబడుతుంది.
కొద్దిగా పాత డేటాను చదవడం ఉపయోగకరంగా ఉంటుంది, ఉదాహరణకు, డేటా నుండి విశ్లేషణలను రూపొందించేటప్పుడు లేదా సుమారుగా మొత్తం విలువలను లెక్కించేటప్పుడు.
లెగసీ డేటాతో పని చేసే మొదటి ప్రయోజనం తక్కువ జాప్యం (ముఖ్యంగా డేటాబేస్ వివిధ భౌగోళిక ప్రాంతాలలో పంపిణీ చేయబడితే). రెండోది రీడ్-ఓన్లీ లావాదేవీలు లాక్-ఫ్రీ. పాత డేటాను హ్యాండిల్ చేయగలిగినంత వరకు, ఎక్కువగా చదివే అప్లికేషన్‌లకు ఇది ఒక ముఖ్యమైన ప్రయోజనం.
తాజా వెర్షన్ పసిఫిక్ మహాసముద్రం యొక్క అవతలి వైపు అందుబాటులో ఉన్నప్పటికీ, అప్లికేషన్ సర్వర్ స్థానిక ప్రతిరూపం నుండి 5 సెకన్ల గడువు ముగిసిన డేటాను రీడ్ చేస్తుంది
DBMSలు పాత సంస్కరణలను స్వయంచాలకంగా ప్రక్షాళన చేస్తాయి మరియు కొన్ని సందర్భాల్లో, అభ్యర్థనపై దీన్ని చేయడానికి మిమ్మల్ని అనుమతిస్తాయి. ఉదాహరణకు, Postgres వినియోగదారులు దీన్ని అనుమతిస్తుంది VACUUM అభ్యర్థనపై, మరియు క్రమానుగతంగా ఈ ఆపరేషన్ను స్వయంచాలకంగా నిర్వహిస్తుంది. ఒక గంట కంటే పాత స్నాప్‌షాట్‌లను వదిలించుకోవడానికి స్పానర్ చెత్త సేకరించే యంత్రాన్ని నడుపుతుంది.
ఏదైనా సమయ మూలాలు వక్రీకరణకు లోబడి ఉంటాయి
కంప్యూటర్ సైన్స్‌లో అత్యుత్తమంగా ఉంచబడిన రహస్యం ఏమిటంటే, అన్ని సమయ APIలు అబద్ధం. వాస్తవానికి, మా యంత్రాలకు ఖచ్చితమైన ప్రస్తుత సమయం తెలియదు. కంప్యూటర్లు క్వార్ట్జ్ స్ఫటికాలను కలిగి ఉంటాయి, ఇవి సమయాన్ని ఉంచడానికి ఉపయోగించే కంపనాలను ఉత్పత్తి చేస్తాయి. అయినప్పటికీ, అవి తగినంత ఖచ్చితమైనవి కావు మరియు ఖచ్చితమైన సమయం కంటే ముందు/వెనక్కి ఉండవచ్చు. షిఫ్ట్ రోజుకు 20 సెకన్లకు చేరుకుంటుంది. అందువల్ల, మా కంప్యూటర్‌లలోని సమయం తప్పనిసరిగా నెట్‌వర్క్‌తో సమకాలీకరించబడాలి.
సమకాలీకరణ కోసం NTP సర్వర్లు ఉపయోగించబడతాయి, అయితే సమకాలీకరణ ప్రక్రియ కూడా నెట్‌వర్క్ జాప్యాలకు లోబడి ఉంటుంది. అదే డేటా సెంటర్‌లో NTP సర్వర్‌తో సమకాలీకరించడానికి కూడా కొంత సమయం పడుతుంది. పబ్లిక్ NTP సర్వర్‌తో పని చేయడం మరింత పెద్ద వక్రీకరణకు దారితీస్తుందని స్పష్టమైంది.
అటామిక్ గడియారాలు మరియు వాటి GPS ప్రతిరూపాలు ప్రస్తుత సమయాన్ని నిర్ణయించడానికి ఉత్తమం, కానీ అవి ఖరీదైనవి మరియు సంక్లిష్టమైన సెటప్ అవసరం, కాబట్టి అవి ప్రతి కారులో ఇన్‌స్టాల్ చేయబడవు. దీని కారణంగా, డేటా సెంటర్లు టైర్డ్ విధానాన్ని ఉపయోగిస్తాయి. అటామిక్ మరియు/లేదా GPS గడియారాలు ఖచ్చితమైన సమయాన్ని చూపుతాయి, ఆ తర్వాత అది సెకండరీ సర్వర్‌ల ద్వారా ఇతర యంత్రాలకు ప్రసారం చేయబడుతుంది. దీని అర్థం ప్రతి యంత్రం ఖచ్చితమైన సమయం నుండి నిర్దిష్ట ఆఫ్‌సెట్‌ను అనుభవిస్తుంది.
అప్లికేషన్‌లు మరియు డేటాబేస్‌లు తరచుగా వేర్వేరు మెషీన్‌లలో (వేరే డేటా సెంటర్లలో కాకపోతే) ఉన్నందున పరిస్థితి మరింత తీవ్రతరం అవుతుంది. అందువల్ల, సమయం వేర్వేరు యంత్రాలలో పంపిణీ చేయబడిన DB నోడ్‌లపై మాత్రమే కాకుండా భిన్నంగా ఉంటుంది. అప్లికేషన్ సర్వర్‌లో కూడా ఇది భిన్నంగా ఉంటుంది.
Google TrueTime పూర్తిగా భిన్నమైన విధానాన్ని తీసుకుంటుంది. ఈ దిశలో Google యొక్క పురోగతి పరమాణు మరియు GPS గడియారాలకు సామాన్యమైన పరివర్తన ద్వారా వివరించబడిందని చాలా మంది నమ్ముతారు, అయితే ఇది పెద్ద చిత్రంలో ఒక భాగం మాత్రమే. TrueTime ఎలా పని చేస్తుందో ఇక్కడ ఉంది:
- TrueTime రెండు విభిన్న మూలాధారాలను ఉపయోగిస్తుంది: GPS మరియు పరమాణు గడియారాలు. ఈ గడియారాలు పరస్పర సంబంధం లేని వైఫల్య మోడ్‌లను కలిగి ఉంటాయి. [వివరాల కోసం పేజీ 5 చూడండి - సుమారు అనువాదం.), కాబట్టి వారి ఉమ్మడి ఉపయోగం విశ్వసనీయతను పెంచుతుంది.
- TrueTime అసాధారణమైన APIని కలిగి ఉంది. ఇది అంతర్నిర్మిత కొలత లోపం మరియు అనిశ్చితితో సమయాన్ని విరామంగా అందిస్తుంది. సమయం యొక్క వాస్తవ క్షణం విరామం యొక్క ఎగువ మరియు దిగువ సరిహద్దుల మధ్య ఎక్కడో ఉంటుంది. Google యొక్క పంపిణీ చేయబడిన డేటాబేస్ అయిన స్పానర్, ప్రస్తుత సమయం పరిధి దాటిందని చెప్పడానికి సురక్షితంగా ఉండే వరకు వేచి ఉంటుంది. ఈ పద్ధతి సిస్టమ్‌లో కొంత జాప్యాన్ని ప్రవేశపెడుతుంది, ప్రత్యేకించి మాస్టర్స్‌పై అనిశ్చితి ఎక్కువగా ఉంటే, కానీ ప్రపంచవ్యాప్తంగా పంపిణీ చేయబడిన పరిస్థితిలో కూడా ఖచ్చితత్వాన్ని నిర్ధారిస్తుంది.
స్పానర్ కాంపోనెంట్‌లు TrueTimeని ఉపయోగిస్తాయి, ఇక్కడ TT.now() విరామాన్ని అందిస్తుంది, కాబట్టి ప్రస్తుత సమయం ఒక నిర్దిష్ట బిందువును దాటిందని నిశ్చయించుకునేంత వరకు స్పేనర్ నిద్రపోతుంది.
ప్రస్తుత సమయాన్ని నిర్ణయించడంలో తగ్గిన ఖచ్చితత్వం అంటే స్పానర్ కార్యకలాపాల వ్యవధిలో పెరుగుదల మరియు పనితీరులో తగ్గుదల. అందుకే పూర్తిగా ఖచ్చితమైన గడియారాన్ని పొందడం అసాధ్యం అయినప్పటికీ అత్యధిక ఖచ్చితత్వాన్ని నిర్వహించడం చాలా ముఖ్యం.
ఆలస్యం అనే పదానికి చాలా అర్థాలు ఉన్నాయి
ఆలస్యం అంటే ఏమిటి అని మీరు డజను మంది నిపుణులను అడిగితే, మీరు బహుశా భిన్నమైన సమాధానాలను పొందుతారు. DBMSలో జాప్యం తరచుగా "డేటాబేస్ జాప్యం" అని పిలువబడుతుంది మరియు క్లయింట్ గ్రహించిన దానికి భిన్నంగా ఉంటుంది. వాస్తవం ఏమిటంటే క్లయింట్ నెట్‌వర్క్ ఆలస్యం మరియు డేటాబేస్ ఆలస్యం మొత్తాన్ని గమనిస్తాడు. పెరుగుతున్న సమస్యలను డీబగ్ చేసేటప్పుడు జాప్యం రకాన్ని వేరుచేసే సామర్థ్యం చాలా కీలకం. కొలమానాలను సేకరించి, ప్రదర్శించేటప్పుడు, ఎల్లప్పుడూ రెండు రకాలను గమనించడానికి ప్రయత్నించండి.
నిర్దిష్ట లావాదేవీ కోసం పనితీరు అవసరాలు మూల్యాంకనం చేయాలి
కొన్నిసార్లు DBMS యొక్క పనితీరు లక్షణాలు మరియు దాని పరిమితులు రైట్/రీడ్ త్రూపుట్ మరియు జాప్యం పరంగా పేర్కొనబడతాయి. ఇది కీ సిస్టమ్ పారామితుల యొక్క సాధారణ అవలోకనాన్ని అందిస్తుంది, అయితే కొత్త DBMS యొక్క పనితీరును మూల్యాంకనం చేసేటప్పుడు, క్లిష్టమైన కార్యకలాపాలను (ప్రతి ప్రశ్న మరియు/లేదా లావాదేవీకి) విడిగా మూల్యాంకనం చేయడం మరింత సమగ్రమైన విధానం. ఉదాహరణలు:
- సంబంధిత పట్టికలలో పేర్కొన్న పరిమితులు మరియు అడ్డు వరుసల ప్యాడింగ్‌తో టేబుల్ X (50 మిలియన్ అడ్డు వరుసలతో)లో కొత్త అడ్డు వరుసను చొప్పించినప్పుడు నిర్గమాంశ మరియు జాప్యాన్ని వ్రాయండి.
- స్నేహితుల సగటు సంఖ్య 500 ఉన్నప్పుడు నిర్దిష్ట వినియోగదారు స్నేహితుల స్నేహితులను ప్రదర్శించడంలో ఆలస్యం.
- వినియోగదారు గంటకు X ఎంట్రీలతో 100 మంది ఇతర వినియోగదారులను అనుసరించినప్పుడు వినియోగదారు చరిత్ర నుండి టాప్ 500 ఎంట్రీలను తిరిగి పొందడంలో జాప్యం.
డేటాబేస్ పనితీరు అవసరాలకు అనుగుణంగా ఉందని మీరు విశ్వసించే వరకు మూల్యాంకనం మరియు ప్రయోగాలు అటువంటి క్లిష్టమైన కేసులను కలిగి ఉండవచ్చు. జాప్యం కొలమానాలను సేకరించేటప్పుడు మరియు SLOలను నిర్ణయించేటప్పుడు కూడా ఇదే విధమైన సూత్రం ఈ విచ్ఛిన్నతను పరిగణనలోకి తీసుకుంటుంది.
ప్రతి ఆపరేషన్ కోసం కొలమానాలను సేకరించేటప్పుడు అధిక కార్డినాలిటీ గురించి తెలుసుకోండి. అధిక-పవర్ డీబగ్గింగ్ డేటాను పొందడానికి లాగ్‌లు, ఈవెంట్ సేకరణ లేదా పంపిణీ చేయబడిన ట్రేసింగ్‌ను ఉపయోగించండి. వ్యాసంలో "» ఆలస్యం డీబగ్గింగ్ మెథడాలజీలను మీరు తెలుసుకోవచ్చు.
సమీకృత లావాదేవీలు ప్రమాదకరమైనవి కావచ్చు
ప్రతి DBMS సమూహ లావాదేవీలకు మద్దతు ఇవ్వదు, కానీ అవి చేసినప్పుడు, అటువంటి లావాదేవీలు ఊహించని లోపాలను కలిగిస్తాయి, అవి ఎల్లప్పుడూ సులభంగా గుర్తించబడవు (అంటే, ఒక రకమైన క్రమరాహిత్యం ఉందని స్పష్టంగా ఉండాలి).
క్లయింట్ లైబ్రరీలను ఉపయోగించి వాటిని గుర్తించి మరియు దాటవేయగల సమూహ లావాదేవీలను ఉపయోగించకుండా మీరు నివారించవచ్చు. సమూహ లావాదేవీలను విడిచిపెట్టలేకపోతే, పూర్తి చేసిన లావాదేవీలు అనుకోకుండా నెస్టెడ్ వాటి కారణంగా ఆగిపోయే ఊహించని పరిస్థితులను నివారించడానికి వాటి అమలులో ప్రత్యేక శ్రద్ధ వహించండి.
వివిధ లేయర్‌లలో లావాదేవీలను ఎన్‌క్యాప్సులేట్ చేయడం వలన ఊహించని సమూహ లావాదేవీలకు దారితీయవచ్చు మరియు కోడ్ రీడబిలిటీ కోణం నుండి, రచయిత ఉద్దేశాలను అర్థం చేసుకోవడం కష్టతరం చేస్తుంది. కింది ప్రోగ్రామ్‌ను పరిశీలించండి:
with newTransaction():
Accounts.create("609-543-222")
with newTransaction():
Accounts.create("775-988-322")
throw Rollback();పై కోడ్ అవుట్‌పుట్ ఎలా ఉంటుంది? ఇది రెండు లావాదేవీలను వెనక్కి తీసుకుంటుందా లేదా కేవలం అంతర్గత లావాదేవీని వెనక్కి తీసుకుంటుందా? మన కోసం లావాదేవీల సృష్టిని సంగ్రహించే లైబ్రరీల యొక్క బహుళ లేయర్‌లపై మనం ఆధారపడినట్లయితే ఏమి జరుగుతుంది? అటువంటి కేసులను గుర్తించి మెరుగుపరచగలమా?
బహుళ కార్యకలాపాలతో కూడిన డేటా లేయర్‌ను ఊహించండి (ఉదా. newAccount) ఇప్పటికే దాని స్వంత లావాదేవీలలో అమలు చేయబడింది. మీరు వాటిని దాని స్వంత లావాదేవీలో అమలు చేసే ఉన్నత-స్థాయి వ్యాపార లాజిక్‌లో భాగంగా అమలు చేస్తే ఏమి జరుగుతుంది? ఈ సందర్భంలో ఒంటరితనం మరియు స్థిరత్వం ఏమిటి?
function newAccount(id string) {
with newTransaction():
Accounts.create(id)
}ఇలాంటి అంతులేని ప్రశ్నలకు సమాధానాల కోసం వెతకడం కంటే, నెస్టెడ్ లావాదేవీలకు దూరంగా ఉండటం మంచిది. అన్నింటికంటే, మీ డేటా లేయర్ దాని స్వంత లావాదేవీలను సృష్టించకుండా సులభంగా ఉన్నత-స్థాయి కార్యకలాపాలను నిర్వహించగలదు. అదనంగా, వ్యాపార తర్కం ఒక లావాదేవీని ప్రారంభించడం, దానిపై కార్యకలాపాలు నిర్వహించడం, లావాదేవీకి పాల్పడడం లేదా రద్దు చేయడం వంటివి చేయగలదు.
function newAccount(id string) {
Accounts.create(id)
}
// In main application:
with newTransaction():
// Read some data from database for configuration.
// Generate an ID from the ID service.
Accounts.create(id)
Uploads.create(id) // create upload queue for the user.లావాదేవీలు అప్లికేషన్ స్థితితో ముడిపడి ఉండకూడదు
కొన్ని విలువలను మార్చడానికి లేదా ప్రశ్న పారామితులను సర్దుబాటు చేయడానికి లావాదేవీలలో అప్లికేషన్ స్థితిని ఉపయోగించడం కొన్నిసార్లు ఉత్సాహం కలిగిస్తుంది. పరిగణించవలసిన క్లిష్టమైన స్వల్పభేదం అప్లికేషన్ యొక్క సరైన పరిధి. నెట్‌వర్క్ సమస్యలు ఉన్నప్పుడు క్లయింట్లు తరచుగా లావాదేవీలను పునఃప్రారంభిస్తారు. లావాదేవీ ఏదైనా ఇతర ప్రక్రియ ద్వారా మార్చబడే స్థితిపై ఆధారపడి ఉంటే, అది డేటా రేస్ యొక్క అవకాశాన్ని బట్టి తప్పు విలువను ఎంచుకోవచ్చు. లావాదేవీలు తప్పనిసరిగా అప్లికేషన్‌లోని డేటా రేస్ పరిస్థితుల ప్రమాదాన్ని పరిగణనలోకి తీసుకోవాలి.
var seq int64
with newTransaction():
newSeq := atomic.Increment(&seq)
Entries.query(newSeq)
// Other operations...పై లావాదేవీ తుది ఫలితంతో సంబంధం లేకుండా, అమలు చేయబడిన ప్రతిసారీ క్రమ సంఖ్యను పెంచుతుంది. నెట్‌వర్క్ సమస్యల కారణంగా కమిట్ విఫలమైతే, మీరు మళ్లీ ప్రయత్నించినప్పుడు అభ్యర్థన వేరే సీక్వెన్స్ నంబర్‌తో అమలు చేయబడుతుంది.
క్వెరీ ప్లానర్‌లు మీకు డేటాబేస్ గురించి చాలా చెప్పగలరు
డేటాబేస్లో ప్రశ్న ఎలా అమలు చేయబడుతుందో క్వరీ ప్లానర్‌లు నిర్ణయిస్తారు. వారు అభ్యర్థనలను కూడా విశ్లేషిస్తారు మరియు వాటిని పంపే ముందు వాటిని ఆప్టిమైజ్ చేస్తారు. ప్లానర్‌లు తమ వద్ద ఉన్న సిగ్నల్‌ల ఆధారంగా కొన్ని సాధ్యమైన అంచనాలను మాత్రమే అందించగలరు. ఉదాహరణకు, కింది ప్రశ్న కోసం ఉత్తమ శోధన పద్ధతి ఏది?
SELECT * FROM articles where author = "rakyll" order by title;ఫలితాలను రెండు విధాలుగా పొందవచ్చు:
- పూర్తి టేబుల్ స్కాన్: మీరు పట్టికలోని ప్రతి ఎంట్రీని చూడవచ్చు మరియు సరిపోలే రచయిత పేరుతో కథనాలను తిరిగి ఇవ్వవచ్చు, ఆపై వాటిని ఆర్డర్ చేయవచ్చు.
- ఇండెక్స్ స్కాన్: సరిపోలే IDలను కనుగొనడానికి, ఆ అడ్డు వరుసలను పొందడానికి, ఆపై వాటిని ఆర్డర్ చేయడానికి మీరు సూచికను ఉపయోగించవచ్చు.
క్వెరీ ప్లానర్ యొక్క పని ఏ వ్యూహం ఉత్తమమో నిర్ణయించడం. క్వెరీ ప్లానర్‌లు పరిమిత అంచనా సామర్థ్యాలను మాత్రమే కలిగి ఉంటారని పరిగణనలోకి తీసుకోవడం విలువ. ఇది తప్పుడు నిర్ణయాలకు దారి తీస్తుంది. DBAలు లేదా డెవలపర్లు పనితీరు సరిగా లేని ప్రశ్నలను నిర్ధారించడానికి మరియు చక్కగా ట్యూన్ చేయడానికి వాటిని ఉపయోగించవచ్చు. DBMS యొక్క కొత్త సంస్కరణలు క్వెరీ ప్లానర్‌లను కాన్ఫిగర్ చేయగలవు మరియు కొత్త వెర్షన్ పనితీరు సమస్యలకు దారితీసినట్లయితే డేటాబేస్‌ను నవీకరించేటప్పుడు స్వీయ-నిర్ధారణ సహాయపడుతుంది. స్లో క్వెరీ లాగ్‌లు, లేటెన్సీ ఇష్యూ రిపోర్ట్‌లు లేదా ఎగ్జిక్యూషన్ టైమ్ గణాంకాలు ఆప్టిమైజేషన్ అవసరమయ్యే ప్రశ్నలను గుర్తించడంలో సహాయపడతాయి.
క్వెరీ ప్లానర్ సమర్పించిన కొన్ని కొలమానాలు శబ్దానికి లోబడి ఉండవచ్చు (ముఖ్యంగా జాప్యం లేదా CPU సమయాన్ని అంచనా వేసేటప్పుడు). షెడ్యూలర్‌లకు మంచి జోడింపు అనేది అమలు మార్గాన్ని గుర్తించడం మరియు ట్రాక్ చేయడం కోసం సాధనాలు. అటువంటి సమస్యలను నిర్ధారించడానికి అవి మిమ్మల్ని అనుమతిస్తాయి (అయ్యో, అన్ని DBMSలు అలాంటి సాధనాలను అందించవు).
ఆన్‌లైన్ మైగ్రేషన్ కష్టం కానీ సాధ్యమే
ఆన్‌లైన్ మైగ్రేషన్, లైవ్ మైగ్రేషన్ లేదా రియల్ టైమ్ మైగ్రేషన్ అంటే ఒక డేటాబేస్ నుండి మరొక డేటాబేస్‌కు డౌన్‌టైమ్ లేదా డేటా కరప్షన్ లేకుండా మారడం. అదే DBMS/ఇంజిన్‌లో మార్పు జరిగితే లైవ్ మైగ్రేషన్ నిర్వహించడం సులభం. విభిన్న పనితీరు మరియు స్కీమా అవసరాలతో కొత్త DBMSకి తరలించాల్సిన అవసరం వచ్చినప్పుడు పరిస్థితి మరింత క్లిష్టంగా మారుతుంది.
విభిన్న ఆన్‌లైన్ మైగ్రేషన్ మోడల్‌లు ఉన్నాయి. వాటిలో ఒకటి ఇక్కడ ఉంది:
- రెండు డేటాబేస్‌లలో డబుల్ ఎంట్రీని ప్రారంభించండి. ఈ దశలో ఉన్న కొత్త డేటాబేస్ మొత్తం డేటాను కలిగి ఉండదు, కానీ తాజా డేటాను మాత్రమే అంగీకరిస్తుంది. మీరు దీన్ని నిర్ధారించుకున్న తర్వాత, మీరు తదుపరి దశకు వెళ్లవచ్చు.
- రెండు డేటాబేస్‌ల నుండి చదవడాన్ని ప్రారంభించండి.
- సిస్టమ్‌ను కాన్ఫిగర్ చేయండి, తద్వారా చదవడం మరియు వ్రాయడం ప్రాథమికంగా కొత్త డేటాబేస్లో నిర్వహించబడతాయి.
- పాత డేటాబేస్ నుండి డేటాను చదవడం కొనసాగించేటప్పుడు దానికి వ్రాయడం ఆపివేయండి. ఈ దశలో, కొత్త డేటాబేస్ ఇప్పటికీ కొంత డేటా లేకుండా ఉంది. అవి పాత డేటాబేస్ నుండి కాపీ చేయబడాలి.
- పాత డేటాబేస్ చదవడానికి మాత్రమే. పాత డేటాబేస్ నుండి తప్పిపోయిన డేటాను కొత్తదానికి కాపీ చేయండి. మైగ్రేషన్ పూర్తయిన తర్వాత, పాత్‌లను కొత్త డేటాబేస్‌కి మార్చండి మరియు పాతదాన్ని ఆపివేసి సిస్టమ్ నుండి తొలగించండి.
అదనపు సమాచారం కోసం, నేను సంప్రదించమని సిఫార్సు చేస్తున్నాను , ఇది ఈ మోడల్ ఆధారంగా స్ట్రిప్ యొక్క మైగ్రేషన్ వ్యూహాన్ని వివరిస్తుంది.
డేటాబేస్లో గణనీయమైన పెరుగుదల అనూహ్యతను పెంచుతుంది
డేటాబేస్ యొక్క పెరుగుదల దాని స్థాయికి సంబంధించిన అనూహ్య సమస్యలకు దారితీస్తుంది. డేటాబేస్ యొక్క అంతర్గత నిర్మాణం గురించి మనకు ఎంత ఎక్కువ తెలిస్తే, అది ఎలా స్కేల్ అవుతుందో అంత బాగా అంచనా వేయవచ్చు. అయితే, కొన్ని క్షణాలు ఊహించడం ఇప్పటికీ అసాధ్యం.
బేస్ పెరుగుతున్న కొద్దీ, డేటా వాల్యూమ్ మరియు నెట్‌వర్క్ బ్యాండ్‌విడ్త్ అవసరాలకు సంబంధించి మునుపటి అంచనాలు మరియు అంచనాలు పాతవి కావచ్చు. సంభావ్య సమస్యలను నివారించడానికి ప్రధాన డిజైన్ సవరణలు, పెద్ద-స్థాయి కార్యాచరణ మెరుగుదలలు, విస్తరణలను పునరాలోచించడం లేదా ఇతర DBMSలకు వలసలు వంటి ప్రశ్న తలెత్తినప్పుడు ఇది జరుగుతుంది.
కానీ ఇప్పటికే ఉన్న డేటాబేస్ యొక్క అంతర్గత నిర్మాణం యొక్క అద్భుతమైన జ్ఞానం మాత్రమే అవసరమని భావించవద్దు. కొత్త ప్రమాణాలు వారితో కొత్త తెలియని వాటిని తెస్తాయి. ఊహించలేని నొప్పి పాయింట్లు, అసమాన డేటా పంపిణీ, ఊహించని బ్యాండ్‌విడ్త్ మరియు హార్డ్‌వేర్ సమస్యలు, ఎప్పటికప్పుడు పెరుగుతున్న ట్రాఫిక్ మరియు కొత్త నెట్‌వర్క్ విభాగాలు మీ డేటాబేస్ విధానం, డేటా మోడల్, విస్తరణ మోడల్ మరియు డేటాబేస్ పరిమాణాన్ని పునరాలోచించవలసి వస్తుంది.
...
నేను ఈ కథనాన్ని ప్రచురించడం గురించి ఆలోచించడం ప్రారంభించిన సమయంలో, నా అసలు జాబితాలో ఇప్పటికే ఐదు అంశాలు ఉన్నాయి. అప్పుడు భారీ సంఖ్యలో వచ్చింది ఇంకా ఏమి కవర్ చేయవచ్చు అనే దాని గురించి. అందువల్ల, గరిష్ట శ్రద్ధ అవసరమయ్యే అతి తక్కువ స్పష్టమైన సమస్యలపై వ్యాసం తాకింది. అయినప్పటికీ, అంశం అయిపోయిందని దీని అర్థం కాదు మరియు నేను ఇకపై నా భవిష్యత్ మెటీరియల్‌లలో దానికి తిరిగి రాను మరియు ప్రస్తుతానికి మార్పులు చేయను.
PS
మా బ్లాగులో కూడా చదవండి:
- «";
- «";
- «".
మూలం: www.habr.com