చాలా మందికి PostgreSQL DBMS గురించి బాగా తెలుసు మరియు ఇది చిన్న ఇన్‌స్టాలేషన్‌లలో నిరూపించబడింది. ఏది ఏమైనప్పటికీ, పెద్ద కంపెనీలు మరియు సంస్థ అవసరాల విషయానికి వస్తే కూడా ఓపెన్ సోర్స్ వైపు ధోరణి మరింత స్పష్టంగా మారింది. ఈ ఆర్టికల్‌లో మేము పోస్ట్‌గ్రెస్‌ను కార్పొరేట్ వాతావరణంలో ఎలా సమగ్రపరచాలో మీకు తెలియజేస్తాము మరియు Commvault బ్యాకప్ సిస్టమ్‌ను ఉదాహరణగా ఉపయోగించి ఈ డేటాబేస్ కోసం బ్యాకప్ సిస్టమ్ (BSS)ని రూపొందించడంలో మా అనుభవాన్ని పంచుకుంటాము.
PostgreSQL ఇప్పటికే దాని విలువను నిరూపించుకుంది - DBMS గొప్పగా పని చేస్తుంది, ఇది అలీబాబా మరియు ట్రిప్అడ్వైజర్ వంటి ఫ్యాషన్ డిజిటల్ వ్యాపారాలచే ఉపయోగించబడుతుంది మరియు లైసెన్సింగ్ ఫీజులు లేకపోవడం వలన MS SQL లేదా Oracle DB వంటి రాక్షసులకు ఇది ఆకర్షణీయమైన ప్రత్యామ్నాయంగా మారింది. కానీ మేము ఎంటర్‌ప్రైజ్ ల్యాండ్‌స్కేప్‌లో PostgreSQL గురించి ఆలోచించడం ప్రారంభించిన వెంటనే, మేము వెంటనే కఠినమైన అవసరాలను పొందుతాము: “కాన్ఫిగరేషన్ తప్పు సహనం గురించి ఏమిటి? విపత్తు నిరోధకత? సమగ్ర పర్యవేక్షణ ఎక్కడ ఉంది? ఆటోమేటెడ్ బ్యాకప్‌ల గురించి ఏమిటి? టేప్ లైబ్రరీలను నేరుగా మరియు సెకండరీ స్టోరేజ్‌లో ఉపయోగించడం గురించి ఏమిటి?"
ఒకవైపు, Oracle DB లేదా SAP డేటాబేస్ బ్యాకప్‌లోని RMAN వంటి “పెద్దల” DBMSల వంటి అంతర్నిర్మిత బ్యాకప్ సాధనాలను PostgreSQL కలిగి లేదు. మరోవైపు, కార్పొరేట్ బ్యాకప్ సిస్టమ్‌ల సరఫరాదారులు (వీమ్, వెరిటాస్, కమ్‌వాల్ట్) వారు PostgreSQLకి మద్దతు ఇస్తున్నప్పటికీ, వాస్తవానికి వారు నిర్దిష్ట (సాధారణంగా స్వతంత్ర) కాన్ఫిగరేషన్‌తో మరియు వివిధ పరిమితుల సమితితో మాత్రమే పని చేస్తారు.
PostgreSQL కోసం ప్రత్యేకంగా రూపొందించబడిన బ్యాకప్ సిస్టమ్‌లు, Barman, Wal-g, pg_probackup వంటివి PostgreSQL DBMS యొక్క చిన్న ఇన్‌స్టాలేషన్‌లలో లేదా IT ల్యాండ్‌స్కేప్‌లోని ఇతర అంశాల భారీ బ్యాకప్‌లు అవసరం లేని చోట బాగా ప్రాచుర్యం పొందాయి. ఉదాహరణకు, PostgreSQLతో పాటు, మౌలిక సదుపాయాలు భౌతిక మరియు వర్చువల్ సర్వర్లు, OpenShift, Oracle, MariaDB, Cassandra మొదలైనవి కలిగి ఉండవచ్చు. వీటన్నింటినీ ఒక సాధారణ సాధనంతో బ్యాకప్ చేయడం మంచిది. PostgreSQL కోసం ప్రత్యేకంగా ప్రత్యేక పరిష్కారాన్ని ఇన్‌స్టాల్ చేయడం చెడ్డ ఆలోచన: డేటా ఎక్కడో డిస్క్‌కి కాపీ చేయబడుతుంది, ఆపై దానిని టేప్‌కి తీసివేయాలి. ఈ డబుల్ బ్యాకప్ బ్యాకప్ సమయాన్ని పెంచుతుంది మరియు మరింత విమర్శనాత్మకంగా, రికవరీ సమయాన్ని పెంచుతుంది.
ఎంటర్‌ప్రైజ్ సొల్యూషన్‌లో, ప్రత్యేక క్లస్టర్‌లో నిర్దిష్ట సంఖ్యలో నోడ్‌లతో ఇన్‌స్టాలేషన్ బ్యాకప్ జరుగుతుంది. అదే సమయంలో, ఉదాహరణకు, Commvault రెండు-నోడ్ క్లస్టర్‌తో మాత్రమే పని చేయగలదు, దీనిలో ప్రాథమిక మరియు ద్వితీయ నిర్దిష్ట నోడ్‌లకు ఖచ్చితంగా కేటాయించబడతాయి. మరియు ఇది ప్రాథమిక నుండి బ్యాకప్ చేయడానికి మాత్రమే అర్ధమే, ఎందుకంటే సెకండరీ నుండి బ్యాకప్ దాని పరిమితులను కలిగి ఉంటుంది. DBMS యొక్క ప్రత్యేకతల కారణంగా, సెకండరీలో డంప్ సృష్టించబడదు మరియు అందువల్ల ఫైల్ బ్యాకప్ యొక్క అవకాశం మాత్రమే మిగిలి ఉంది.
పనికిరాని సమయ ప్రమాదాన్ని తగ్గించడానికి, ఒక తప్పు-తట్టుకునే సిస్టమ్‌ను సృష్టించేటప్పుడు, "లైవ్" క్లస్టర్ కాన్ఫిగరేషన్ సృష్టించబడుతుంది మరియు ప్రైమరీ క్రమంగా వివిధ సర్వర్‌ల మధ్య మారవచ్చు. ఉదాహరణకు, Patroni సాఫ్ట్‌వేర్ యాదృచ్ఛికంగా ఎంచుకున్న క్లస్టర్ నోడ్‌లో ప్రాథమికాన్ని ప్రారంభించింది. దీన్ని బాక్స్ వెలుపల ట్రాక్ చేయడానికి IBSకి మార్గం లేదు మరియు కాన్ఫిగరేషన్ మారితే, ప్రక్రియలు విచ్ఛిన్నమవుతాయి. అంటే, బాహ్య నియంత్రణ పరిచయం ISR ప్రభావవంతంగా పనిచేయకుండా నిరోధిస్తుంది, ఎందుకంటే నియంత్రణ సర్వర్ కేవలం ఎక్కడ మరియు ఏ డేటా నుండి కాపీ చేయబడాలో అర్థం చేసుకోదు.
పోస్ట్‌గ్రెస్‌లో బ్యాకప్ అమలు చేయడం మరొక సమస్య. ఇది డంప్ ద్వారా సాధ్యమవుతుంది మరియు ఇది చిన్న డేటాబేస్లలో పని చేస్తుంది. కానీ పెద్ద డేటాబేస్లలో, డంప్‌కు చాలా సమయం పడుతుంది, చాలా వనరులు అవసరం మరియు డేటాబేస్ ఉదాహరణ వైఫల్యానికి దారితీయవచ్చు.
ఫైల్ బ్యాకప్ పరిస్థితిని సరిచేస్తుంది, కానీ పెద్ద డేటాబేస్లలో ఇది నెమ్మదిగా ఉంటుంది ఎందుకంటే ఇది సింగిల్-థ్రెడ్ మోడ్‌లో పనిచేస్తుంది. అదనంగా, విక్రేతలకు అనేక అదనపు పరిమితులు ఉన్నాయి. మీరు ఒకే సమయంలో ఫైల్ మరియు డంప్ బ్యాకప్‌లను ఉపయోగించలేరు లేదా తగ్గింపుకు మద్దతు లేదు. అనేక సమస్యలు ఉన్నాయి మరియు చాలా తరచుగా పోస్ట్‌గ్రెస్‌కు బదులుగా ఖరీదైన కానీ నిరూపితమైన DBMSని ఎంచుకోవడం సులభం.
వెనక్కి తగ్గడానికి ఎక్కడా లేదు! మాస్కో డెవలపర్లు వెనుకబడి ఉన్నారు!
అయితే, ఇటీవల మా బృందం ఒక క్లిష్టమైన సవాలును ఎదుర్కొంది: AIS OSAGO 2.0ని సృష్టించే ప్రాజెక్ట్‌లో, మేము IT అవస్థాపనను సృష్టించాము, డెవలపర్లు కొత్త సిస్టమ్ కోసం PostgreSQLని ఎంచుకున్నారు.
పెద్ద సాఫ్ట్‌వేర్ డెవలపర్లు "అత్యాధునిక" ఓపెన్ సోర్స్ సొల్యూషన్‌లను ఉపయోగించడం చాలా సులభం. ఈ DBMS యొక్క ఆపరేషన్‌కు మద్దతు ఇవ్వడానికి Facebookకి తగినంత మంది నిపుణులు ఉన్నారు. మరియు RSA విషయంలో, "రెండవ రోజు" యొక్క అన్ని పనులు మా భుజాలపై పడ్డాయి. మేము తప్పు సహనాన్ని నిర్ధారించడం, క్లస్టర్‌ను సమీకరించడం మరియు బ్యాకప్‌ని సెటప్ చేయడం అవసరం. చర్య యొక్క తర్కం క్రింది విధంగా ఉంది:
- క్లస్టర్ యొక్క ప్రైమరీ నోడ్ నుండి బ్యాకప్ చేయడానికి SRKకి నేర్పండి. దీన్ని చేయడానికి, SRK దానిని కనుగొనాలి - అంటే ఒకటి లేదా మరొక PostgreSQL క్లస్టర్ నిర్వహణ పరిష్కారంతో ఏకీకరణ అవసరం. ఆర్‌ఎస్‌ఏ విషయానికొస్తే, దీనికి పాత్రోని సాఫ్ట్‌వేర్‌ను ఉపయోగించారు.
- డేటా పరిమాణం మరియు రికవరీ అవసరాల ఆధారంగా బ్యాకప్ రకాన్ని నిర్ణయించండి. ఉదాహరణకు, మీరు పేజీలను గ్రాన్యులర్‌గా పునరుద్ధరించాల్సిన అవసరం వచ్చినప్పుడు, డంప్‌ని ఉపయోగించండి మరియు డేటాబేస్‌లు పెద్దగా ఉంటే మరియు గ్రాన్యులర్ పునరుద్ధరణ అవసరం లేనట్లయితే, ఫైల్ స్థాయిలో పని చేయండి.
- మల్టీ-థ్రెడ్ మోడ్‌లో బ్యాకప్ కాపీని సృష్టించడానికి పరిష్కారానికి బ్లాక్ బ్యాకప్ అవకాశాన్ని అటాచ్ చేయండి.
అదే సమయంలో, మేము ప్రారంభంలో అదనపు భాగాల యొక్క భయంకరమైన జీను లేకుండా సమర్థవంతమైన మరియు సరళమైన వ్యవస్థను రూపొందించడానికి బయలుదేరాము. తక్కువ క్రచెస్, సిబ్బందిపై తక్కువ పనిభారం మరియు IBS వైఫల్యం ప్రమాదం తక్కువగా ఉంటుంది. మేము వెంటనే Veeam మరియు RMAN ఉపయోగించిన విధానాలను మినహాయించాము, ఎందుకంటే రెండు పరిష్కారాల సమితి ఇప్పటికే సిస్టమ్ యొక్క విశ్వసనీయతను సూచిస్తుంది.
సంస్థ కోసం ఒక చిన్న మేజిక్
కాబట్టి, మేము 10 నోడ్‌ల 3 క్లస్టర్‌ల కోసం నమ్మకమైన బ్యాకప్‌కు హామీ ఇవ్వాల్సిన అవసరం ఉంది, బ్యాకప్ డేటా సెంటర్‌లో అదే ఇన్‌ఫ్రాస్ట్రక్చర్ ప్రతిబింబిస్తుంది. PostgreSQL పరంగా డేటా కేంద్రాలు యాక్టివ్-పాసివ్ సూత్రంపై పనిచేస్తాయి. మొత్తం డేటాబేస్ పరిమాణం 50 TB. ఏదైనా కార్పొరేట్ స్థాయి నియంత్రణ వ్యవస్థ దీన్ని సులభంగా ఎదుర్కోగలదు. కానీ మినహాయింపు ఏమిటంటే, మొదట పోస్ట్‌గ్రెస్‌కు బ్యాకప్ సిస్టమ్‌లతో పూర్తి మరియు లోతైన అనుకూలత కోసం క్లూ లేదు. అందువల్ల, మేము మొదట PostgreSQLతో కలిపి గరిష్ట కార్యాచరణను కలిగి ఉన్న పరిష్కారం కోసం వెతకాలి మరియు సిస్టమ్‌ను మెరుగుపరచాలి.
మేము 3 అంతర్గత “హ్యాకథాన్‌లను” నిర్వహించాము - మేము యాభైకి పైగా పరిణామాలను చూశాము, వాటిని పరీక్షించాము, మా పరికల్పనలకు సంబంధించి మార్పులు చేసాము మరియు వాటిని మళ్లీ పరీక్షించాము. అందుబాటులో ఉన్న ఎంపికలను సమీక్షించిన తర్వాత, మేము Commvaultని ఎంచుకున్నాము. బాక్స్ వెలుపల, ఈ ఉత్పత్తి సరళమైన PostgreSQL క్లస్టర్ ఇన్‌స్టాలేషన్‌తో పని చేయగలదు మరియు దాని ఓపెన్ ఆర్కిటెక్చర్ విజయవంతమైన అభివృద్ధి మరియు ఏకీకరణ కోసం ఆశలను పెంచింది (ఇవి సమర్థించబడ్డాయి). Commvault PostgreSQL లాగ్‌లను కూడా బ్యాకప్ చేయగలదు. ఉదాహరణకు, PostgreSQL పరంగా వెరిటాస్ నెట్‌బ్యాకప్ పూర్తి బ్యాకప్‌లను మాత్రమే చేయగలదు.
ఆర్కిటెక్చర్ గురించి మరింత. CommServ HA కాన్ఫిగరేషన్‌లో ప్రతి రెండు డేటా సెంటర్‌లలో Commvault మేనేజ్‌మెంట్ సర్వర్లు ఇన్‌స్టాల్ చేయబడ్డాయి. సిస్టమ్ ప్రతిబింబిస్తుంది, ఒక కన్సోల్ ద్వారా నిర్వహించబడుతుంది మరియు HA దృష్టికోణం నుండి, అన్ని ఎంటర్‌ప్రైజ్ అవసరాలను తీరుస్తుంది.
మేము ప్రతి డేటా సెంటర్‌లో రెండు ఫిజికల్ మీడియా సర్వర్‌లను కూడా ప్రారంభించాము, వాటికి మేము ప్రత్యేకంగా SAN ద్వారా ఫైబర్ ఛానెల్ ద్వారా బ్యాకప్‌ల కోసం అంకితమైన డిస్క్ శ్రేణులు మరియు టేప్ లైబ్రరీలను కనెక్ట్ చేసాము. ఎక్స్‌టెండెడ్ డీప్లికేషన్ డేటాబేస్‌లు మీడియా సర్వర్‌ల తప్పు సహనాన్ని నిర్ధారిస్తాయి మరియు ప్రతి సర్వర్‌ను ప్రతి CSVకి కనెక్ట్ చేయడం వలన ఏదైనా భాగం విఫలమైతే నిరంతర ఆపరేషన్‌ను ప్రారంభించింది. సిస్టమ్ ఆర్కిటెక్చర్ డేటా సెంటర్‌లలో ఒకటి పడిపోయినప్పటికీ బ్యాకప్‌ను కొనసాగించడానికి అనుమతిస్తుంది.
Patroni ప్రతి క్లస్టర్‌కు ఒక ప్రాథమిక నోడ్‌ను నిర్వచిస్తుంది. ఇది డేటా సెంటర్‌లో ఏదైనా ఉచిత నోడ్ కావచ్చు - కానీ ఎక్కువగా మాత్రమే. బ్యాకప్‌లో, అన్ని నోడ్‌లు ద్వితీయమైనవి.
Commvault ఏ క్లస్టర్ నోడ్ ప్రైమరీ అని అర్థం చేసుకోవడానికి, మేము సిస్టమ్‌ను (పరిష్కారం యొక్క ఓపెన్ ఆర్కిటెక్చర్‌కు ధన్యవాదాలు) పోస్ట్‌గ్రెస్‌తో అనుసంధానించాము. ఈ ప్రయోజనం కోసం, ప్రాథమిక నోడ్ యొక్క ప్రస్తుత స్థానాన్ని Commvault నిర్వహణ సర్వర్‌కు నివేదించే స్క్రిప్ట్ సృష్టించబడింది.
సాధారణంగా, ప్రక్రియ ఇలా కనిపిస్తుంది:
Patroni ప్రైమరీని ఎంచుకుంటుంది → Keepalived IP క్లస్టర్‌ని ఎంచుకుంటుంది మరియు స్క్రిప్ట్‌ను రన్ చేస్తుంది → ఎంచుకున్న క్లస్టర్ నోడ్‌లోని Commvault ఏజెంట్ ఇది ప్రైమరీ అని నోటిఫికేషన్‌ను అందుకుంటుంది → Commvault స్వయంచాలకంగా నకిలీ క్లయింట్‌లో బ్యాకప్‌ను రీకాన్ఫిగర్ చేస్తుంది.
ఈ విధానం యొక్క ప్రయోజనం ఏమిటంటే, పరిష్కారం స్థిరత్వం, లాగ్‌ల యొక్క ఖచ్చితత్వం లేదా పోస్ట్‌గ్రెస్ ఉదాహరణ యొక్క పునరుద్ధరణను ప్రభావితం చేయదు. ఇది సులువుగా కొలవదగినది, ఎందుకంటే ఇకపై Commvault ప్రైమరీ మరియు సెకండరీ నోడ్‌లను పరిష్కరించాల్సిన అవసరం లేదు. ప్రాథమికం ఎక్కడ ఉందో సిస్టమ్ అర్థం చేసుకుంటే సరిపోతుంది మరియు నోడ్‌ల సంఖ్యను దాదాపు ఏదైనా విలువకు పెంచవచ్చు.
పరిష్కారం ఆదర్శంగా నటించదు మరియు దాని స్వంత సూక్ష్మ నైపుణ్యాలను కలిగి ఉంటుంది. Commvault మొత్తం ఉదాహరణను మాత్రమే బ్యాకప్ చేయగలదు మరియు వ్యక్తిగత డేటాబేస్‌లను కాదు. అందువల్ల, ప్రతి డేటాబేస్ కోసం ఒక ప్రత్యేక ఉదాహరణ సృష్టించబడింది. రియల్ క్లయింట్‌లు వర్చువల్ సూడో-క్లయింట్‌లుగా మిళితం చేయబడతారు. ప్రతి Commvault సూడో-క్లయింట్ ఒక UNIX క్లస్టర్. పోస్ట్‌గ్రెస్ కోసం Commvault ఏజెంట్ ఇన్‌స్టాల్ చేయబడిన క్లస్టర్ నోడ్‌లు దానికి జోడించబడతాయి. ఫలితంగా, నకిలీ క్లయింట్ యొక్క అన్ని వర్చువల్ నోడ్‌లు ఒక ఉదాహరణగా బ్యాకప్ చేయబడతాయి.
ప్రతి సూడో-క్లయింట్‌లో, క్లస్టర్ యొక్క క్రియాశీల నోడ్ సూచించబడుతుంది. Commvault కోసం మా ఇంటిగ్రేషన్ సొల్యూషన్ నిర్వచించేది ఇదే. దాని ఆపరేషన్ సూత్రం చాలా సులభం: నోడ్‌పై క్లస్టర్ IP పెంచబడితే, స్క్రిప్ట్ Commvault ఏజెంట్ బైనరీలో “యాక్టివ్ నోడ్” పరామితిని సెట్ చేస్తుంది - వాస్తవానికి, స్క్రిప్ట్ మెమరీలో అవసరమైన భాగంలో “1” సెట్ చేస్తుంది. . ఏజెంట్ ఈ డేటాను CommServeకి బదిలీ చేస్తుంది మరియు Commvault కావలసిన నోడ్ నుండి బ్యాకప్ చేస్తుంది. అదనంగా, కాన్ఫిగరేషన్ యొక్క ఖచ్చితత్వం స్క్రిప్ట్ స్థాయిలో తనిఖీ చేయబడుతుంది, బ్యాకప్‌ను ప్రారంభించేటప్పుడు లోపాలను నివారించడంలో సహాయపడుతుంది.
అదే సమయంలో, పెద్ద డేటాబేస్‌లు బహుళ థ్రెడ్‌లలో బ్లాక్‌లలో బ్యాకప్ చేయబడతాయి, RPO మరియు బ్యాకప్ విండో అవసరాలకు అనుగుణంగా ఉంటాయి. సిస్టమ్‌పై లోడ్ చాలా తక్కువగా ఉంటుంది: పూర్తి కాపీలు చాలా తరచుగా జరగవు, ఇతర రోజులలో మాత్రమే లాగ్‌లు సేకరించబడతాయి మరియు తక్కువ లోడ్ ఉన్న కాలంలో.
మార్గం ద్వారా, మేము PostgreSQL ఆర్కైవ్ లాగ్‌లను బ్యాకప్ చేయడానికి ప్రత్యేక విధానాలను వర్తింపజేసాము - అవి వేర్వేరు నియమాల ప్రకారం నిల్వ చేయబడతాయి, వేరొక షెడ్యూల్ ప్రకారం కాపీ చేయబడతాయి మరియు ఈ లాగ్‌లు ప్రత్యేకమైన డేటాను కలిగి ఉన్నందున వాటికి తగ్గింపు ప్రారంభించబడదు.
మొత్తం IT ఇన్‌ఫ్రాస్ట్రక్చర్‌లో స్థిరత్వాన్ని నిర్ధారించడానికి, ప్రతి క్లస్టర్ నోడ్‌లలో ప్రత్యేక Commvault ఫైల్ క్లయింట్‌లు ఇన్‌స్టాల్ చేయబడతాయి. అవి బ్యాకప్‌ల నుండి పోస్ట్‌గ్రెస్ ఫైల్‌లను మినహాయించాయి మరియు OS మరియు అప్లికేషన్ బ్యాకప్‌ల కోసం మాత్రమే ఉద్దేశించబడ్డాయి. డేటాలోని ఈ భాగం దాని స్వంత విధానం మరియు నిల్వ వ్యవధిని కూడా కలిగి ఉంది.
ప్రస్తుతం, IBS ఉత్పాదకత సేవలను ప్రభావితం చేయదు, అయితే పరిస్థితి మారితే, Commvault లోడ్ పరిమితిని ప్రారంభించగలదు.
అది మంచిదేనా? మంచిది!
కాబట్టి, మేము కేవలం పని చేయదగినవి మాత్రమే కాకుండా, PostgreSQL క్లస్టర్ ఇన్‌స్టాలేషన్ కోసం పూర్తిగా ఆటోమేటెడ్ బ్యాకప్‌ను కూడా అందుకున్నాము మరియు ఇది ఎంటర్‌ప్రైజ్ కాల్‌ల కోసం అన్ని అవసరాలను తీరుస్తుంది.
1 గంట మరియు 2 గంటల RPO మరియు RTO పారామితులు మార్జిన్‌తో కప్పబడి ఉంటాయి, అంటే నిల్వ చేయబడిన డేటా పరిమాణంలో గణనీయమైన పెరుగుదలతో కూడా సిస్టమ్ వాటికి అనుగుణంగా ఉంటుంది. అనేక సందేహాలకు విరుద్ధంగా, PostgreSQL మరియు ఎంటర్‌ప్రైజ్ వాతావరణం చాలా అనుకూలంగా ఉన్నాయి. అటువంటి DBMSల కోసం బ్యాకప్ అనేక రకాల కాన్ఫిగరేషన్‌లలో సాధ్యమవుతుందని ఇప్పుడు మా స్వంత అనుభవం నుండి మాకు తెలుసు.
వాస్తవానికి, ఈ మార్గంలో మేము ఏడు జతల ఇనుప బూట్లు ధరించాలి, అనేక ఇబ్బందులను అధిగమించాలి, అనేక రేక్‌లపై అడుగు పెట్టాలి మరియు అనేక తప్పులను సరిదిద్దాలి. కానీ ఇప్పుడు విధానం ఇప్పటికే పరీక్షించబడింది మరియు కఠినమైన సంస్థ పరిస్థితులలో యాజమాన్య DBMSకి బదులుగా ఓపెన్ సోర్స్‌ని అమలు చేయడానికి ఉపయోగించవచ్చు.
మీరు కార్పొరేట్ వాతావరణంలో PostgreSQLతో పనిచేయడానికి ప్రయత్నించారా?
రచయితలు:
ఒలేగ్ లావ్రెనోవ్, డేటా స్టోరేజ్ సిస్టమ్స్, జెట్ ఇన్ఫోసిస్టమ్స్ డిజైన్ ఇంజనీర్
డిమిత్రి ఎరికిన్, జెట్ ఇన్ఫోసిస్టమ్స్‌లో కంప్యూటర్ సిస్టమ్స్ డిజైన్ ఇంజనీర్
మూలం: www.habr.com