ఏదో విధంగా, చారిత్రాత్మకంగా, IT పరిశ్రమ ఏ కారణం చేతనైనా రెండు షరతులతో కూడిన శిబిరాలుగా విభజించబడింది: "కోసం" మరియు "వ్యతిరేకంగా" ఉన్నవారు. అంతేకాకుండా, వివాదాల విషయం పూర్తిగా ఏకపక్షంగా ఉంటుంది. ఏ OS ఉత్తమం: Win లేదా Linux? Android లేదా iOS స్మార్ట్ఫోన్లో? మీరు ప్రతిదీ మేఘాలలో నిల్వ చేయాలా లేదా కోల్డ్ RAID నిల్వలో ఉంచాలా మరియు స్క్రూలను సురక్షితంగా ఉంచాలా? PHP వ్యక్తులకు ప్రోగ్రామర్లు అని పిలవబడే హక్కు ఉందా? ఈ వివాదాలు కొన్ని సమయాల్లో, ప్రకృతిలో ప్రత్యేకంగా అస్తిత్వానికి సంబంధించినవి మరియు క్రీడా ఆసక్తికి మించిన ఆధారాన్ని కలిగి ఉండవు.
కంటైనర్లు మరియు డాకర్ మరియు షరతులతో కూడిన k8 లతో ఈ ప్రియమైన వంటకాలు రావడంతో, బ్యాకెండ్లోని వివిధ ప్రాంతాలలో కొత్త సామర్థ్యాల ఉపయోగం కోసం "కోసం" మరియు "వ్యతిరేకంగా" చర్చలు ప్రారంభమయ్యాయి. (ఈ చర్చలో Kubernetes తరచుగా ఆర్కెస్ట్రేటర్గా సూచించబడుతున్నప్పటికీ, ఈ ప్రత్యేక సాధనం యొక్క ఎంపిక ప్రాథమిక ప్రాముఖ్యత లేనిది అని ముందుగానే రిజర్వేషన్ చేద్దాం. బదులుగా, మీరు మీకు అత్యంత అనుకూలమైన మరియు సుపరిచితమైనదిగా అనిపించే ఏదైనా మరొక దానిని భర్తీ చేయవచ్చు. .)
మరియు, ఇది ఒకే నాణెం యొక్క రెండు వైపుల మధ్య సాధారణ వివాదం అని అనిపిస్తుంది. విన్ vs లైనక్స్ మధ్య జరిగే శాశ్వతమైన ఘర్షణ వలె తెలివిలేనిది మరియు కనికరం లేనిది, మధ్యలో ఎక్కడో ఒకచోట తగినంత మంది వ్యక్తులు ఉంటారు. కానీ కంటైనర్ విషయంలో, ప్రతిదీ చాలా సులభం కాదు. సాధారణంగా ఇటువంటి వివాదాలలో కుడి వైపు ఉండదు, కానీ డేటాబేస్లను నిల్వ చేయడానికి "ఉపయోగించు" లేదా "ఉపయోగించవద్దు" కంటైనర్ల విషయంలో, ప్రతిదీ తలక్రిందులుగా మారుతుంది. ఎందుకంటే ఒక నిర్దిష్ట కోణంలో, ఈ విధానం యొక్క మద్దతుదారులు మరియు ప్రత్యర్థులు ఇద్దరూ సరైనవారు.
ప్రకాశవంతమైన వైపు
లైట్ సైడ్ యొక్క వాదనను ఒక పదబంధంలో క్లుప్తంగా వివరించవచ్చు: "హలో, 2k19 విండో వెలుపల ఉంది!" ఇది పాపులిజం లాగా అనిపిస్తుంది, అయితే మీరు పరిస్థితిని వివరంగా పరిశీలిస్తే, దాని ప్రయోజనాలు ఉన్నాయి. ఇప్పుడు వాటిని క్రమబద్ధీకరించుదాం.
మీకు పెద్ద వెబ్ ప్రాజెక్ట్ ఉందని అనుకుందాం. ఇది ప్రారంభంలో మైక్రోసర్వీస్ విధానం ఆధారంగా నిర్మించబడి ఉండవచ్చు లేదా ఏదో ఒక సమయంలో అది పరిణామ మార్గం ద్వారా వచ్చింది - వాస్తవానికి ఇది చాలా ముఖ్యమైనది కాదు. మీరు మా ప్రాజెక్ట్ను ప్రత్యేక మైక్రోసర్వీస్లుగా విభజించారు, ఆర్కెస్ట్రేషన్, లోడ్ బ్యాలెన్సింగ్ మరియు స్కేలింగ్ని సెటప్ చేసారు. ఇప్పుడు, స్పష్టమైన మనస్సాక్షితో, పడిపోయిన సర్వర్లను పెంచడానికి బదులుగా హబ్రా ఎఫెక్ట్ల సమయంలో మీరు ఊయలలో ఒక మోజిటోను సిప్ చేయండి. కానీ అన్ని చర్యలలో మీరు స్థిరంగా ఉండాలి. చాలా తరచుగా, అప్లికేషన్ మాత్రమే-కోడ్-కంటైనరైజ్ చేయబడుతుంది. కోడ్తో పాటు మన దగ్గర ఇంకా ఏమి ఉన్నాయి?
అది నిజం, డేటా. ఏదైనా ప్రాజెక్ట్ యొక్క గుండె దాని డేటా: ఇది ఒక సాధారణ DBMS కావచ్చు - MySQL, Postgre, MongoDB లేదా శోధన కోసం ఉపయోగించే నిల్వ (ElasticSearch), కాషింగ్ కోసం కీ-విలువ నిల్వ - ఉదాహరణకు, redis, మొదలైనవి ప్రస్తుతం మేము కాదు. పేలవంగా వ్రాసిన ప్రశ్నల కారణంగా డేటాబేస్ క్రాష్ అయినప్పుడు మేము వంకర బ్యాకెండ్ అమలు ఎంపికల గురించి మాట్లాడుతాము మరియు బదులుగా క్లయింట్ లోడ్లో ఈ డేటాబేస్ యొక్క తప్పు సహనాన్ని నిర్ధారించడం గురించి మాట్లాడుతాము. అన్నింటికంటే, మేము మా అప్లికేషన్ను కంటెయినరైజ్ చేసినప్పుడు మరియు ఎన్ని ఇన్కమింగ్ అభ్యర్థనలను ప్రాసెస్ చేయడానికి దాన్ని స్వేచ్ఛగా స్కేల్ చేయడానికి అనుమతించినప్పుడు, ఇది సహజంగా డేటాబేస్పై లోడ్ను పెంచుతుంది.
నిజానికి, డేటాబేస్ని యాక్సెస్ చేసే ఛానెల్ మరియు అది రన్ అయ్యే సర్వర్ మన అందమైన కంటెయినరైజ్డ్ బ్యాకెండ్లో సూది యొక్క కన్ను అవుతుంది. అదే సమయంలో, కంటైనర్ వర్చువలైజేషన్ యొక్క ప్రధాన ఉద్దేశ్యం నిర్మాణం యొక్క చలనశీలత మరియు వశ్యత, ఇది మాకు అందుబాటులో ఉన్న మొత్తం అవస్థాపనలో గరిష్ట లోడ్ల పంపిణీని సాధ్యమైనంత సమర్థవంతంగా నిర్వహించడానికి అనుమతిస్తుంది. అంటే, మేము క్లస్టర్లో ఉన్న సిస్టమ్లోని అన్ని ఎలిమెంట్లను కంటెయినరైజ్ చేసి రోల్ అవుట్ చేయకపోతే, మేము చాలా తీవ్రమైన తప్పు చేస్తున్నాము.
అప్లికేషన్ను మాత్రమే కాకుండా, డేటాను నిల్వ చేయడానికి బాధ్యత వహించే సేవలను కూడా క్లస్టర్ చేయడం చాలా తార్కికం. స్వతంత్రంగా పనిచేసే వెబ్ సర్వర్లను క్లస్టరింగ్ చేయడం మరియు అమలు చేయడం ద్వారా మరియు k8 లలో తమలో తాము లోడ్ పంపిణీ చేయడం ద్వారా, మేము ఇప్పటికే డేటా సమకాలీకరణ సమస్యను పరిష్కరిస్తున్నాము - మేము కొన్ని మీడియా లేదా బ్లాగ్ ప్లాట్ఫారమ్ను ఉదాహరణగా తీసుకుంటే పోస్ట్లపై అదే వ్యాఖ్యలు. ఏదైనా సందర్భంలో, మేము ఒక ఇంట్రా-క్లస్టర్ని కలిగి ఉన్నాము, వర్చువల్ కూడా, డేటాబేస్ యొక్క ప్రాతినిధ్యాన్ని బాహ్య సేవ వలె కలిగి ఉన్నాము. ప్రశ్న ఏమిటంటే, డేటాబేస్ ఇంకా క్లస్టర్ చేయబడలేదు - క్యూబ్లో అమర్చబడిన వెబ్ సర్వర్లు మా స్టాటిక్ కంబాట్ డేటాబేస్ నుండి మార్పుల గురించి సమాచారాన్ని తీసుకుంటాయి, ఇది విడిగా తిరుగుతుంది.
క్యాచ్ను పసిగడుతున్నారా? లోడ్ను పంపిణీ చేయడానికి మరియు ప్రాథమిక సర్వర్ క్రాష్ కాకుండా నిరోధించడానికి మేము k8s లేదా స్వార్మ్ను ఉపయోగిస్తాము. వెబ్ సర్వర్, కానీ మేము డేటాబేస్ కోసం దీన్ని చేయము. కానీ డేటాబేస్ క్రాష్ అయితే, మన మొత్తం క్లస్టర్డ్ ఇన్ఫ్రాస్ట్రక్చర్ పనికిరానిది - ఖాళీ వెబ్ పేజీలు డేటాబేస్ యాక్సెస్ లోపాలను తిరిగి ఇవ్వడం వల్ల ప్రయోజనం ఏమిటి?
అందుకే సాధారణంగా చేసే విధంగా వెబ్ సర్వర్లను మాత్రమే కాకుండా, డేటాబేస్ ఇన్ఫ్రాస్ట్రక్చర్ను కూడా క్లస్టర్ చేయడం అవసరం. ఈ విధంగా మాత్రమే మేము ఒక బృందంలో పూర్తిగా పనిచేసే నిర్మాణాన్ని నిర్ధారించగలము, కానీ అదే సమయంలో ఒకదానికొకటి స్వతంత్రంగా ఉంటుంది. అంతేకాకుండా, మన బ్యాకెండ్లో సగం లోడ్లో "కుప్పకూలినప్పటికీ", మిగిలినవి మనుగడలో ఉంటాయి మరియు క్లస్టర్లో డేటాబేస్లను ఒకదానితో ఒకటి సమకాలీకరించే వ్యవస్థ మరియు కొత్త క్లస్టర్లను అనంతంగా స్కేల్ చేయగల మరియు విస్తరించే సామర్థ్యం అవసరమైన సామర్థ్యాన్ని త్వరగా చేరుకోవడంలో సహాయపడతాయి - డేటా సెంటర్లో రాక్లు మాత్రమే ఉంటే.
అదనంగా, క్లస్టర్లలో పంపిణీ చేయబడిన డేటాబేస్ మోడల్ ఈ డేటాబేస్ను అవసరమైన చోటికి తీసుకెళ్లడానికి మిమ్మల్ని అనుమతిస్తుంది; మేము గ్లోబల్ సర్వీస్ గురించి మాట్లాడుతున్నట్లయితే, శాన్ ఫ్రాన్సిస్కో ప్రాంతంలో ఎక్కడో ఒక వెబ్ క్లస్టర్ను స్పిన్ చేయడం మరియు అదే సమయంలో మాస్కో ప్రాంతంలో మరియు వెనుకకు డేటాబేస్ను యాక్సెస్ చేసేటప్పుడు ప్యాకెట్లను పంపడం చాలా అసంబద్ధం.
అలాగే, డేటాబేస్ యొక్క కంటెయినరైజేషన్ మీరు సిస్టమ్ యొక్క అన్ని అంశాలను ఒకే స్థాయిలో సంగ్రహణలో నిర్మించడానికి అనుమతిస్తుంది. ఇది, ఈ వ్యవస్థను నేరుగా కోడ్ నుండి డెవలపర్ల ద్వారా, నిర్వాహకుల క్రియాశీల ప్రమేయం లేకుండా నిర్వహించడం సాధ్యం చేస్తుంది. డెవలపర్లు కొత్త సబ్ప్రాజెక్ట్ కోసం ప్రత్యేక DBMS అవసరమని భావించారు - సులభం! ఒక yaml ఫైల్ని వ్రాసి, దానిని క్లస్టర్కి అప్లోడ్ చేసారు మరియు మీరు పూర్తి చేసారు.
మరియు వాస్తవానికి, అంతర్గత ఆపరేషన్ చాలా సరళీకృతం చేయబడింది. నాకు చెప్పండి, కొత్త బృంద సభ్యుడు పని కోసం పోరాట డేటాబేస్లో చేతులు పెట్టినప్పుడు మీరు ఎన్నిసార్లు కళ్ళు మూసుకున్నారు? నిజానికి, మీ వద్ద ఉన్నది మరియు ప్రస్తుతం తిరుగుతున్నది ఏది? వాస్తవానికి, మనమందరం ఇక్కడ పెద్దవాళ్లం, మరియు ఎక్కడో మనకు తాజా బ్యాకప్ ఉంది మరియు ఇంకా దూరంగా - అమ్మమ్మ దోసకాయలు మరియు పాత స్కిస్లతో షెల్ఫ్ వెనుక - మరొక బ్యాకప్, బహుశా కోల్డ్ స్టోరేజీలో కూడా ఉంది, ఎందుకంటే మీ కార్యాలయంలో ఇదివరకే ఒకసారి మంటలు చెలరేగాయి. అయితే ఒకే విధంగా, పోరాట మౌలిక సదుపాయాలకు మరియు, వాస్తవానికి, పోరాట డేటాబేస్కు యాక్సెస్తో కొత్త బృంద సభ్యుని ప్రతి పరిచయం చుట్టుపక్కల ప్రతి ఒక్కరికీ వాలిడోల్ బకెట్. బాగా, అతనిని ఎవరికి తెలుసు, కొత్త వ్యక్తి, బహుశా అతను క్రాస్ హ్యాండెడ్? ఇది భయానకంగా ఉంది, మీరు అంగీకరిస్తారు.
కంటెయినరైజేషన్ మరియు వాస్తవానికి, మీ ప్రాజెక్ట్ డేటాబేస్ యొక్క పంపిణీ చేయబడిన ఫిజికల్ టోపోలాజీ అటువంటి ధృవీకరణ క్షణాలను నివారించడంలో సహాయపడుతుంది. కొత్త వ్యక్తిని విశ్వసించలేదా? అలాగే! ఇతర క్లస్టర్లతో పని చేయడానికి మరియు డేటాబేస్ను డిస్కనెక్ట్ చేయడానికి అతనికి అతని స్వంత క్లస్టర్ని ఇద్దాం - మాన్యువల్ పుష్ మరియు రెండు కీల సింక్రోనస్ రొటేషన్ (ఒకటి టీమ్ లీడ్కి, మరొకటి అడ్మిన్కి) ద్వారా సమకాలీకరణ. మరియు అందరూ సంతోషంగా ఉన్నారు.
మరియు ఇప్పుడు డేటాబేస్ క్లస్టరింగ్ యొక్క ప్రత్యర్థులుగా మారడానికి సమయం ఆసన్నమైంది.
చీకటి వైపు
డేటాబేస్ను కంటైనరైజ్ చేయడం మరియు దానిని ఒక సెంట్రల్లో అమలు చేయడం ఎందుకు విలువైనది కాదో పరిశీలిస్తున్నప్పుడు సర్వర్"మా తాతలు హార్డ్వేర్పై డేటాబేస్లను నిర్మించారు, మేము కూడా అలాగే చేస్తాము!" వంటి సనాతన వాక్చాతుర్యాన్ని మరియు ప్రకటనలకు మనం వంగిపోకూడదు, బదులుగా, కంటైనరైజేషన్ వాస్తవానికి స్పష్టమైన డివిడెండ్లను ఇచ్చే పరిస్థితిని ఊహించుకోవడానికి ప్రయత్నిద్దాం.
అంగీకరిస్తున్నారు, ఒక కంటైనర్లో నిజంగా ఆధారం అవసరమయ్యే ప్రాజెక్ట్లను ఉత్తమ మిల్లింగ్ మెషిన్ ఆపరేటర్ ద్వారా ఒక చేతి వేళ్లపై లెక్కించవచ్చు. చాలా వరకు, k8s లేదా డాకర్ స్వార్మ్ను ఉపయోగించడం కూడా అనవసరం - చాలా తరచుగా ఈ సాధనాలు సాంకేతికత యొక్క సాధారణ హైప్ మరియు లింగాల వ్యక్తిలోని “సర్వశక్తిమంతుడి” వైఖరుల కారణంగా ప్రతిదాన్ని నెట్టడానికి ఆశ్రయించబడతాయి. మేఘాలు మరియు కంటైనర్లు. బాగా, ఎందుకంటే ఇప్పుడు ఇది ఫ్యాషన్ మరియు ప్రతి ఒక్కరూ దీన్ని చేస్తారు.
కనీసం సగం కేసుల్లో, ప్రాజెక్ట్లో కుబెర్నెటిస్ లేదా డాకర్ని ఉపయోగించడం అనవసరం. సమస్య ఏమిటంటే క్లయింట్ యొక్క మౌలిక సదుపాయాలను నిర్వహించడానికి నియమించబడిన అన్ని బృందాలు లేదా అవుట్సోర్సింగ్ కంపెనీలకు దీని గురించి తెలియదు. కంటైనర్లు విధించినప్పుడు ఇది అధ్వాన్నంగా ఉంటుంది, ఎందుకంటే ఇది క్లయింట్కు కొంత మొత్తంలో నాణేలను ఖర్చు చేస్తుంది.
సాధారణంగా, ఈ ఇన్ఫ్రాస్ట్రక్చర్ సమస్యలను అవుట్సోర్స్ చేసే క్లయింట్లను డాకర్/క్యూబ్ మాఫియా తెలివితక్కువగా అణిచివేస్తోందనే అభిప్రాయం ఉంది. అన్నింటికంటే, క్లస్టర్లతో పనిచేయడానికి, మాకు దీని సామర్థ్యం ఉన్న ఇంజనీర్లు అవసరం మరియు సాధారణంగా అమలు చేయబడిన పరిష్కారం యొక్క నిర్మాణాన్ని అర్థం చేసుకుంటారు. మేము ఇప్పటికే రిపబ్లిక్ ప్రచురణతో మా కేసును వివరించాము - అక్కడ మేము కుబెర్నెటిస్ యొక్క వాస్తవికతలలో పని చేయడానికి క్లయింట్ బృందానికి శిక్షణ ఇచ్చాము మరియు అందరూ సంతృప్తి చెందారు. మరియు అది సరసమైనది. తరచుగా, k8s “అమలు చేసేవారు” క్లయింట్ యొక్క మౌలిక సదుపాయాలను బందీగా తీసుకుంటారు - ఎందుకంటే అక్కడ ప్రతిదీ ఎలా పనిచేస్తుందో ఇప్పుడు మాత్రమే వారు అర్థం చేసుకుంటారు; క్లయింట్ వైపు నిపుణులు లేరు.
ఇప్పుడు ఈ విధంగా మేము వెబ్ సర్వర్ భాగాన్ని మాత్రమే కాకుండా, డేటాబేస్ నిర్వహణను కూడా అవుట్సోర్స్ చేస్తాము. BD గుండె అని, మరియు గుండె కోల్పోవడం ఏ జీవికైనా ప్రాణాంతకం అని మేము చెప్పాము. సంక్షిప్తంగా, అవకాశాలు ఉత్తమమైనవి కావు. కాబట్టి, హైప్ కుబెర్నెటిస్కు బదులుగా, అనేక ప్రాజెక్ట్లు AWS కోసం సాధారణ టారిఫ్తో బాధపడకూడదు, ఇది వారి సైట్/ప్రాజెక్ట్పై లోడ్తో అన్ని సమస్యలను పరిష్కరిస్తుంది. కానీ AWS ఇకపై ఫ్యాషన్ కాదు మరియు షో-ఆఫ్లు డబ్బు కంటే ఎక్కువ విలువైనవి - దురదృష్టవశాత్తు, IT వాతావరణంలో కూడా.
అలాగే. బహుశా ప్రాజెక్ట్కు నిజంగా క్లస్టరింగ్ అవసరం కావచ్చు, కానీ స్థితిలేని అప్లికేషన్లతో ప్రతిదీ స్పష్టంగా ఉంటే, క్లస్టర్డ్ డేటాబేస్ కోసం మనం మంచి నెట్వర్క్ కనెక్టివిటీని ఎలా నిర్వహించగలం?
మేము అతుకులు లేని ఇంజనీరింగ్ సొల్యూషన్ గురించి మాట్లాడుతున్నట్లయితే, అంటే k8sకి పరివర్తన అంటే, క్లస్టర్డ్ డేటాబేస్లో డేటా రెప్లికేషన్ అనేది మన ప్రధాన తలనొప్పి. కొన్ని DBMSలు మొదట్లో తమ వ్యక్తిగత ఉదాహరణల మధ్య డేటా పంపిణీకి చాలా విశ్వాసపాత్రంగా ఉంటాయి. చాలా మందికి అంత ఆదరణ లేదు. మరియు చాలా తరచుగా మా ప్రాజెక్ట్ కోసం DBMS ఎంచుకోవడంలో ప్రధాన వాదన కనీస వనరు మరియు ఇంజనీరింగ్ ఖర్చులతో ప్రతిరూపం చేసే సామర్థ్యం కాదు. ప్రత్యేకించి ప్రాజెక్ట్ ప్రారంభంలో మైక్రోసర్వీస్గా ప్లాన్ చేయకపోతే, కానీ ఈ దిశలో అభివృద్ధి చెందింది.
నెట్వర్క్ డ్రైవ్ల వేగం గురించి మాట్లాడవలసిన అవసరం లేదని మేము భావిస్తున్నాము - అవి నెమ్మదిగా ఉంటాయి. ఆ. ఏదైనా జరిగితే, ప్రాసెసర్ పవర్ లేదా ఉచిత ర్యామ్ ఎక్కువగా ఉన్న చోట DBMS ఉదాహరణను పునఃప్రారంభించడానికి మాకు ఇప్పటికీ నిజమైన అవకాశం లేదు. మేము చాలా త్వరగా వర్చువలైజ్డ్ డిస్క్ సబ్సిస్టమ్ పనితీరులోకి ప్రవేశిస్తాము. తదనుగుణంగా, DBMS తప్పనిసరిగా దగ్గరలో ఉన్న దాని స్వంత వ్యక్తిగత యంత్రాల సెట్కు వ్రేలాడదీయాలి. లేదా అనుకున్న నిల్వల కోసం తగినంత వేగవంతమైన డేటా సమకాలీకరణను విడిగా చల్లబరచడం అవసరం.
వర్చువల్ ఫైల్ సిస్టమ్ల అంశాన్ని కొనసాగిస్తోంది: డాకర్ వాల్యూమ్లు, దురదృష్టవశాత్తూ, సమస్య-రహితంగా లేవు. సాధారణంగా, దీర్ఘకాలిక విశ్వసనీయ డేటా నిల్వ వంటి విషయంలో, నేను చాలా సాంకేతికంగా సరళమైన పథకాలతో చేయాలనుకుంటున్నాను. మరియు కంటైనర్ యొక్క FS నుండి పేరెంట్ హోస్ట్ యొక్క FSకి కొత్త సంగ్రహణ లేయర్ని జోడించడం అనేది ప్రమాదం. కానీ కంటైనర్ సపోర్ట్ సిస్టమ్ యొక్క ఆపరేషన్ కూడా ఈ పొరల మధ్య డేటాను ప్రసారం చేయడంలో ఇబ్బందులను ఎదుర్కొన్నప్పుడు, అది నిజంగా విపత్తు. ప్రస్తుతానికి, ప్రగతిశీల మానవాళికి తెలిసిన చాలా సమస్యలు నిర్మూలించబడినట్లు కనిపిస్తున్నాయి. కానీ మీరు అర్థం చేసుకున్నారు, మరింత సంక్లిష్టమైన యంత్రాంగం, సులభంగా విచ్ఛిన్నమవుతుంది.
ఈ అన్ని "సాహసాల" దృష్ట్యా, డేటాబేస్ను ఒకే చోట ఉంచడం చాలా లాభదాయకం మరియు సులభం, మరియు మీరు అప్లికేషన్ను కంటెయినరైజ్ చేయవలసి వచ్చినప్పటికీ, అది దాని స్వంతంగా అమలు చేయనివ్వండి మరియు డిస్ట్రిబ్యూషన్ గేట్వే ద్వారా ఏకకాలంలో కమ్యూనికేషన్ను పొందండి డేటాబేస్, ఇది ఒక్కసారి మాత్రమే చదవబడుతుంది మరియు వ్రాయబడుతుంది మరియు ఒకే స్థలంలో ఉంటుంది. ఈ విధానం లోపాలు మరియు డీసింక్రొనైజేషన్ యొక్క సంభావ్యతను కనిష్టంగా తగ్గిస్తుంది.
మనం దేనికి దారి తీస్తున్నాము? అంతేకాకుండా, డేటాబేస్ కంటెయినరైజేషన్ నిజమైన అవసరం ఉన్న చోట తగినది. మీరు పూర్తి-యాప్ డేటాబేస్ను నింపలేరు మరియు మీకు రెండు డజన్ల మైక్రోసర్వీస్లు ఉన్నట్లుగా స్పిన్ చేయలేరు - ఇది ఆ విధంగా పని చేయదు. మరియు ఇది స్పష్టంగా అర్థం చేసుకోవాలి.
అవుట్పుట్ బదులుగా
మీరు “డేటాబేస్ను వర్చువలైజ్ చేయాలా వద్దా” అనే స్పష్టమైన ముగింపు కోసం ఎదురు చూస్తున్నట్లయితే, మేము మిమ్మల్ని నిరాశపరుస్తాము: అది ఇక్కడ ఉండదు. ఎందుకంటే ఏదైనా ఇన్ఫ్రాస్ట్రక్చర్ సొల్యూషన్ను రూపొందించేటప్పుడు, ఫ్యాషన్ మరియు పురోగతి ద్వారా కాకుండా, మొదటగా, ఇంగితజ్ఞానం ద్వారా మార్గనిర్దేశం చేయాలి.
కుబెర్నెటిస్తో వచ్చే సూత్రాలు మరియు సాధనాలు సరిగ్గా సరిపోయే ప్రాజెక్ట్లు ఉన్నాయి మరియు అలాంటి ప్రాజెక్ట్లలో కనీసం బ్యాకెండ్ ప్రాంతంలో శాంతి ఉంటుంది. మరియు కంటెయినరైజేషన్ అవసరం లేని ప్రాజెక్ట్లు ఉన్నాయి, కానీ సాధారణ సర్వర్ ఇన్ఫ్రాస్ట్రక్చర్, ఎందుకంటే అవి ప్రాథమికంగా మైక్రోసర్వీస్ క్లస్టర్ మోడల్కి రీస్కేల్ చేయలేవు, ఎందుకంటే అవి వస్తాయి.
మూలం: www.habr.com
