"இலவச" PostgreSQL ஐ கடுமையான நிறுவன சூழலில் எவ்வாறு பொருத்துவது

பலர் PostgreSQL DBMS ஐ நன்கு அறிந்திருக்கிறார்கள், மேலும் இது சிறிய நிறுவல்களில் தன்னை நிரூபித்துள்ளது. எவ்வாறாயினும், பெரிய நிறுவனங்கள் மற்றும் நிறுவனத் தேவைகளுக்கு வரும்போது கூட, திறந்த மூலத்தை நோக்கிய போக்கு பெருகிய முறையில் தெளிவாகிவிட்டது. இந்தக் கட்டுரையில், கார்ப்பரேட் சூழலில் Postgres ஐ எவ்வாறு ஒருங்கிணைப்பது மற்றும் Commvault காப்புப் பிரதி அமைப்பைப் பயன்படுத்தி இந்தத் தரவுத்தளத்திற்கான காப்புப் பிரதி அமைப்பை (BSS) உருவாக்கும் அனுபவத்தைப் பகிர்ந்து கொள்வது எப்படி என்பதை நாங்கள் உங்களுக்குக் கூறுவோம்.

PostgreSQL ஏற்கனவே அதன் மதிப்பை நிரூபித்துள்ளது - DBMS சிறப்பாக செயல்படுகிறது, இது Alibaba மற்றும் TripAdvisor போன்ற நாகரீக டிஜிட்டல் வணிகங்களால் பயன்படுத்தப்படுகிறது, மேலும் உரிமக் கட்டணங்கள் இல்லாததால் MS SQL அல்லது Oracle DB போன்ற அரக்கர்களுக்கு இது ஒரு கவர்ச்சியான மாற்றாக அமைகிறது. ஆனால் எண்டர்பிரைஸ் நிலப்பரப்பில் PostgreSQL பற்றி சிந்திக்கத் தொடங்கியவுடன், நாம் உடனடியாக கடுமையான தேவைகளுக்குள் செல்கிறோம்: “உள்ளமைவு தவறு சகிப்புத்தன்மை பற்றி என்ன? பேரிடர் எதிர்ப்பு? விரிவான கண்காணிப்பு எங்கே? தானியங்கு காப்புப்பிரதிகள் பற்றி என்ன? டேப் லைப்ரரிகளை நேரடியாகவும் இரண்டாம் நிலை சேமிப்பகத்திலும் பயன்படுத்துவது பற்றி என்ன?"


ஒருபுறம், PostgreSQL ஆனது Oracle DB அல்லது SAP தரவுத்தள காப்புப்பிரதியில் உள்ள RMAN போன்ற "வயது வந்தோருக்கான" DBMSகள் போன்ற உள்ளமைக்கப்பட்ட காப்புப் பிரதி கருவிகளைக் கொண்டிருக்கவில்லை. மறுபுறம், கார்ப்பரேட் காப்பு அமைப்புகளின் சப்ளையர்கள் (Veeam, Veritas, Commvault) அவர்கள் PostgreSQL ஐ ஆதரித்தாலும், உண்மையில் அவர்கள் ஒரு குறிப்பிட்ட (பொதுவாக தனித்த) உள்ளமைவு மற்றும் பல்வேறு கட்டுப்பாடுகளுடன் மட்டுமே வேலை செய்கிறார்கள்.

PostgreSQL க்காக பிரத்யேகமாக வடிவமைக்கப்பட்ட காப்பு அமைப்புகள், Barman, Wal-g, pg_probackup போன்றவை PostgreSQL DBMS இன் சிறிய நிறுவல்களில் அல்லது IT நிலப்பரப்பின் பிற கூறுகளின் அதிக காப்புப்பிரதிகள் தேவையில்லாத இடங்களில் மிகவும் பிரபலமாக உள்ளன. எடுத்துக்காட்டாக, PostgreSQL ஐத் தவிர, உள்கட்டமைப்பில் இயற்பியல் மற்றும் மெய்நிகர் சேவையகங்கள், OpenShift, Oracle, MariaDB, Cassandra போன்றவை இருக்கலாம். இவை அனைத்தையும் ஒரு பொதுவான கருவி மூலம் காப்புப் பிரதி எடுப்பது நல்லது. PostgreSQL க்கு பிரத்தியேகமாக ஒரு தனி தீர்வை நிறுவுவது தவறான யோசனை: தரவு எங்காவது வட்டுக்கு நகலெடுக்கப்படும், பின்னர் அதை டேப்பில் அகற்ற வேண்டும். இந்த இரட்டை காப்புப்பிரதி காப்புப்பிரதி நேரத்தை அதிகரிக்கிறது, மேலும் மிகவும் முக்கியமானதாக, மீட்பு நேரத்தை அதிகரிக்கிறது.

ஒரு நிறுவன தீர்வில், நிறுவலின் காப்புப்பிரதி ஒரு பிரத்யேக கிளஸ்டரில் குறிப்பிட்ட எண்ணிக்கையிலான முனைகளுடன் நிகழ்கிறது. அதே நேரத்தில், எடுத்துக்காட்டாக, Commvault இரண்டு முனை கிளஸ்டருடன் மட்டுமே வேலை செய்ய முடியும், இதில் முதன்மை மற்றும் இரண்டாம் நிலை கண்டிப்பாக குறிப்பிட்ட முனைகளுக்கு ஒதுக்கப்படும். முதன்மையிலிருந்து காப்புப் பிரதி எடுப்பது மட்டுமே அர்த்தமுள்ளதாக இருக்கிறது, ஏனெனில் இரண்டாம் நிலையிலிருந்து காப்புப்பிரதிக்கு அதன் வரம்புகள் உள்ளன. DBMS இன் தனித்தன்மையின் காரணமாக, இரண்டாம்நிலையில் ஒரு டம்ப் உருவாக்கப்படவில்லை, எனவே கோப்பு காப்புப்பிரதிக்கான சாத்தியம் மட்டுமே உள்ளது.

வேலையில்லா நேரத்தின் அபாயத்தைக் குறைக்க, ஒரு தவறு-சகிப்புத்தன்மை அமைப்பை உருவாக்கும் போது, ​​ஒரு "நேரடி" கிளஸ்டர் உள்ளமைவு உருவாக்கப்படுகிறது, மேலும் முதன்மையானது படிப்படியாக வெவ்வேறு சேவையகங்களுக்கு இடையில் இடம்பெயர முடியும். எடுத்துக்காட்டாக, Patroni மென்பொருளே தற்செயலாக தேர்ந்தெடுக்கப்பட்ட கிளஸ்டர் முனையில் முதன்மையை துவக்குகிறது. பெட்டிக்கு வெளியே இதைக் கண்காணிக்க IBS க்கு வழி இல்லை, மேலும் உள்ளமைவு மாறினால், செயல்முறைகள் உடைந்துவிடும். அதாவது, வெளிப்புறக் கட்டுப்பாட்டின் அறிமுகம் ISR திறம்பட செயல்படுவதைத் தடுக்கிறது, ஏனெனில் கட்டுப்பாட்டு சேவையகம் வெறுமனே எங்கிருந்து, எந்தத் தரவை நகலெடுக்க வேண்டும் என்பதைப் புரிந்து கொள்ளவில்லை.

மற்றொரு சிக்கல் Postgres இல் காப்புப்பிரதியை செயல்படுத்துவதாகும். இது டம்ப் மூலம் சாத்தியமாகும், மேலும் இது சிறிய தரவுத்தளங்களில் வேலை செய்கிறது. ஆனால் பெரிய தரவுத்தளங்களில், டம்ப் நீண்ட நேரம் எடுக்கும், நிறைய ஆதாரங்கள் தேவைப்படுகிறது மற்றும் தரவுத்தள நிகழ்வின் தோல்விக்கு வழிவகுக்கும்.

கோப்பு காப்புப்பிரதி நிலைமையை சரிசெய்கிறது, ஆனால் பெரிய தரவுத்தளங்களில் இது மெதுவாக உள்ளது, ஏனெனில் இது ஒற்றை-திரிக்கப்பட்ட பயன்முறையில் செயல்படுகிறது. கூடுதலாக, விற்பனையாளர்களுக்கு பல கூடுதல் கட்டுப்பாடுகள் உள்ளன. நீங்கள் ஒரே நேரத்தில் கோப்பு மற்றும் டம்ப் காப்புப்பிரதிகளைப் பயன்படுத்த முடியாது அல்லது விலக்கு ஆதரிக்கப்படாது. பல சிக்கல்கள் உள்ளன, மேலும் பெரும்பாலும் போஸ்ட்கிரெஸுக்குப் பதிலாக விலையுயர்ந்த ஆனால் நிரூபிக்கப்பட்ட DBMS ஐத் தேர்ந்தெடுப்பது எளிது.

பின்வாங்க எங்கும் இல்லை! மாஸ்கோ டெவலப்பர்கள் பின்னால் உள்ளனர்!

இருப்பினும், சமீபத்தில் எங்கள் குழு ஒரு கடினமான சவாலை எதிர்கொண்டது: AIS OSAGO 2.0 ஐ உருவாக்கும் திட்டத்தில், நாங்கள் IT உள்கட்டமைப்பை உருவாக்கினோம், டெவலப்பர்கள் புதிய அமைப்பிற்கு PostgreSQL ஐத் தேர்ந்தெடுத்தனர்.

பெரிய மென்பொருள் உருவாக்குநர்கள் "நவநாகரீக" திறந்த மூல தீர்வுகளைப் பயன்படுத்துவது மிகவும் எளிதானது. இந்த DBMS-ன் செயல்பாட்டை ஆதரிக்க, Facebook இல் போதுமான நிபுணர்கள் உள்ளனர். மற்றும் RSA விஷயத்தில், "இரண்டாம் நாள்" அனைத்து பணிகளும் எங்கள் தோள்களில் விழுந்தன. தவறு சகிப்புத்தன்மையை உறுதிப்படுத்தவும், ஒரு கிளஸ்டரை அசெம்பிள் செய்யவும், நிச்சயமாக, காப்புப்பிரதியை அமைக்கவும் நாங்கள் தேவைப்பட்டோம். செயலின் தர்க்கம் பின்வருமாறு:

• கிளஸ்டரின் முதன்மை முனையிலிருந்து காப்புப்பிரதிகளை உருவாக்க SRKக்குக் கற்றுக் கொடுங்கள். இதைச் செய்ய, SRK அதைக் கண்டுபிடிக்க வேண்டும் - அதாவது ஒன்று அல்லது மற்றொரு PostgreSQL கிளஸ்டர் மேலாண்மை தீர்வுடன் ஒருங்கிணைப்பு தேவை. RSA விஷயத்தில், Patroni மென்பொருள் இதற்குப் பயன்படுத்தப்பட்டது.
• தரவு அளவு மற்றும் மீட்பு தேவைகளின் அடிப்படையில் காப்புப்பிரதியின் வகையைத் தீர்மானிக்கவும். எடுத்துக்காட்டாக, நீங்கள் பக்கங்களை சிறுமணியாக மீட்டெடுக்க வேண்டியிருக்கும் போது, ​​ஒரு டம்ப்பைப் பயன்படுத்தவும், மேலும் தரவுத்தளங்கள் பெரியதாக இருந்தால் மற்றும் சிறுமணி மறுசீரமைப்பு தேவையில்லை என்றால், கோப்பு மட்டத்தில் வேலை செய்யுங்கள்.
• மல்டி-த்ரெட் பயன்முறையில் காப்புப் பிரதியை உருவாக்க, பிளாக் பேக்கப் சாத்தியத்தை தீர்வுடன் இணைக்கவும்.

அதே நேரத்தில், கூடுதல் கூறுகளின் பயங்கரமான சேணம் இல்லாமல் ஒரு பயனுள்ள மற்றும் எளிமையான அமைப்பை உருவாக்க நாங்கள் ஆரம்பத்தில் புறப்பட்டோம். குறைவான ஊன்றுகோல், ஊழியர்களுக்கு குறைவான பணிச்சுமை மற்றும் IBS தோல்வியின் அபாயம் குறைவு. Veeam மற்றும் RMAN ஐப் பயன்படுத்தும் அணுகுமுறைகளை நாங்கள் உடனடியாக விலக்கினோம், ஏனெனில் இரண்டு தீர்வுகளின் தொகுப்பு ஏற்கனவே கணினியின் நம்பகத்தன்மையின்மையைக் குறிக்கிறது.

நிறுவனத்திற்கு ஒரு சிறிய மந்திரம்

எனவே, 10 முனைகள் கொண்ட 3 கிளஸ்டர்களுக்கு நம்பகமான காப்புப்பிரதிக்கு நாங்கள் உத்தரவாதம் அளிக்க வேண்டும், அதே உள்கட்டமைப்பு காப்பு தரவு மையத்தில் பிரதிபலிக்கிறது. PostgreSQL இன் அடிப்படையில் தரவு மையங்கள் செயலில்-செயலற்ற கொள்கையில் செயல்படுகின்றன. மொத்த தரவுத்தள அளவு 50 TB. எந்தவொரு கார்ப்பரேட்-நிலை கட்டுப்பாட்டு அமைப்பும் இதை எளிதாக சமாளிக்க முடியும். ஆனால் எச்சரிக்கை என்னவெனில், முதலில் Postgres க்கு காப்புப்பிரதி அமைப்புகளுடன் முழுமையான மற்றும் ஆழமான இணக்கத்தன்மைக்கான துப்பு இல்லை. எனவே, முதலில் PostgreSQL உடன் இணைந்து அதிகபட்ச செயல்பாட்டைக் கொண்ட ஒரு தீர்வைத் தேட வேண்டியிருந்தது, மேலும் கணினியைச் செம்மைப்படுத்த வேண்டும்.

நாங்கள் 3 உள் “ஹேக்கத்தான்களை” நடத்தினோம் - நாங்கள் ஐம்பதுக்கும் மேற்பட்ட முன்னேற்றங்களைப் பார்த்தோம், அவற்றைச் சோதித்தோம், எங்கள் கருதுகோள்கள் தொடர்பாக மாற்றங்களைச் செய்தோம், அவற்றை மீண்டும் சோதித்தோம். கிடைக்கக்கூடிய விருப்பங்களை மதிப்பாய்வு செய்த பிறகு, நாங்கள் Commvault ஐ தேர்வு செய்தோம். பெட்டிக்கு வெளியே, இந்த தயாரிப்பு எளிமையான PostgreSQL கிளஸ்டர் நிறுவலுடன் வேலை செய்ய முடியும், மேலும் அதன் திறந்த கட்டமைப்பு வெற்றிகரமான வளர்ச்சி மற்றும் ஒருங்கிணைப்புக்கான நம்பிக்கையை (நியாயப்படுத்தப்பட்டது) உயர்த்தியது. Commvault PostgreSQL பதிவுகளையும் காப்புப் பிரதி எடுக்க முடியும். எடுத்துக்காட்டாக, PostgreSQL இன் அடிப்படையில் Veritas NetBackup முழு காப்புப்பிரதிகளை மட்டுமே செய்ய முடியும்.

கட்டிடக்கலை பற்றி மேலும். CommServ HA உள்ளமைவில் இரண்டு தரவு மையங்களில் ஒவ்வொன்றிலும் Commvault மேலாண்மை சேவையகங்கள் நிறுவப்பட்டுள்ளன. கணினி பிரதிபலித்தது, ஒரு கன்சோல் மூலம் நிர்வகிக்கப்படுகிறது மற்றும் HA பார்வையில் இருந்து, அனைத்து நிறுவன தேவைகளையும் பூர்த்தி செய்கிறது.

ஒவ்வொரு தரவு மையத்திலும் இரண்டு இயற்பியல் மீடியா சேவையகங்களைத் தொடங்கினோம், ஃபைபர் சேனல் வழியாக SAN வழியாக காப்புப்பிரதிகளுக்காக பிரத்யேகமாக அர்ப்பணிக்கப்பட்ட வட்டு வரிசைகள் மற்றும் டேப் லைப்ரரிகளை இணைத்துள்ளோம். விரிவாக்கப்பட்ட டியூப்ளிகேஷன் தரவுத்தளங்கள் மீடியா சேவையகங்களின் தவறு சகிப்புத்தன்மையை உறுதி செய்தன, மேலும் ஒவ்வொரு சேவையகத்தையும் ஒவ்வொரு CSV உடன் இணைப்பது ஏதேனும் கூறு தோல்வியுற்றால் தொடர்ச்சியான செயல்பாட்டை செயல்படுத்துகிறது. கணினி கட்டமைப்பு தரவு மையங்களில் ஒன்று விழுந்தாலும் காப்புப்பிரதியைத் தொடர அனுமதிக்கிறது.

பேட்ரோனி ஒவ்வொரு கிளஸ்டருக்கும் ஒரு முதன்மை முனையை வரையறுக்கிறது. இது தரவு மையத்தில் எந்த இலவச முனையாகவும் இருக்கலாம் - ஆனால் பெரும்பாலும் மட்டுமே. காப்புப்பிரதியில், அனைத்து முனைகளும் இரண்டாம் நிலை.

எந்த கிளஸ்டர் முனை முதன்மையானது என்பதை Commvault புரிந்துகொள்வதற்காக, கணினியை (தீர்வின் திறந்த கட்டமைப்பிற்கு நன்றி) Postgres உடன் ஒருங்கிணைத்தோம். இந்த நோக்கத்திற்காக, முதன்மை முனையின் தற்போதைய இருப்பிடத்தை Commvault மேலாண்மை சேவையகத்திற்கு தெரிவிக்கும் ஒரு ஸ்கிரிப்ட் உருவாக்கப்பட்டது.

பொதுவாக, செயல்முறை இதுபோல் தெரிகிறது:

Patroni முதன்மை → Keepalived ஐபி கிளஸ்டரைத் தேர்ந்தெடுத்து ஸ்கிரிப்டை இயக்குகிறது → தேர்ந்தெடுக்கப்பட்ட கிளஸ்டர் முனையிலுள்ள Commvault முகவர் இது முதன்மை → Commvault போலி கிளையண்டிற்குள் காப்புப்பிரதியை தானாகவே மறுகட்டமைக்கும் அறிவிப்பைப் பெறுகிறது.

இந்த அணுகுமுறையின் நன்மை என்னவென்றால், தீர்வு நிலைத்தன்மை, பதிவுகளின் சரியான தன்மை அல்லது Postgres நிகழ்வின் மீட்பு ஆகியவற்றை பாதிக்காது. இது எளிதில் அளவிடக்கூடியது, ஏனெனில் Commvault முதன்மை மற்றும் இரண்டாம் நிலை முனைகளை சரிசெய்ய வேண்டிய அவசியமில்லை. முதன்மையானது எங்குள்ளது என்பதை கணினி புரிந்து கொண்டால் போதும், மேலும் முனைகளின் எண்ணிக்கையை எந்த மதிப்பிற்கும் அதிகரிக்கலாம்.

தீர்வு சிறந்ததாக பாசாங்கு செய்யவில்லை மற்றும் அதன் சொந்த நுணுக்கங்களைக் கொண்டுள்ளது. Commvault ஆனது முழு நிகழ்வையும் மட்டுமே காப்புப் பிரதி எடுக்க முடியும், தனிப்பட்ட தரவுத்தளங்கள் அல்ல. எனவே, ஒவ்வொரு தரவுத்தளத்திற்கும் ஒரு தனி நிகழ்வு உருவாக்கப்பட்டது. உண்மையான வாடிக்கையாளர்கள் மெய்நிகர் போலி வாடிக்கையாளர்களாக இணைக்கப்பட்டுள்ளனர். ஒவ்வொரு Commvault போலி கிளையண்டும் UNIX கிளஸ்டர் ஆகும். Postgres க்கான Commvault முகவர் நிறுவப்பட்ட கிளஸ்டர் முனைகள் அதில் சேர்க்கப்படுகின்றன. இதன் விளைவாக, போலி கிளையண்டின் அனைத்து மெய்நிகர் முனைகளும் ஒரு நிகழ்வாக காப்புப் பிரதி எடுக்கப்படுகின்றன.

ஒவ்வொரு போலி கிளையண்டிலும், கிளஸ்டரின் செயலில் உள்ள முனை குறிக்கப்படுகிறது. Commvaultக்கான எங்கள் ஒருங்கிணைப்பு தீர்வு இதைத்தான் வரையறுக்கிறது. அதன் செயல்பாட்டின் கொள்கை மிகவும் எளிமையானது: ஒரு முனையில் ஒரு கிளஸ்டர் ஐபி எழுப்பப்பட்டால், ஸ்கிரிப்ட் Commvault ஏஜென்ட் பைனரியில் "செயலில் முனை" அளவுருவை அமைக்கிறது - உண்மையில், ஸ்கிரிப்ட் நினைவகத்தின் தேவையான பகுதியில் "1" ஐ அமைக்கிறது. . முகவர் இந்தத் தரவை CommServe க்கு அனுப்புகிறார், மேலும் Commvault விரும்பிய முனையிலிருந்து காப்புப் பிரதி எடுக்கிறது. கூடுதலாக, உள்ளமைவின் சரியான தன்மை ஸ்கிரிப்ட் மட்டத்தில் சரிபார்க்கப்படுகிறது, காப்புப்பிரதியைத் தொடங்கும் போது பிழைகளைத் தவிர்க்க உதவுகிறது.

அதே நேரத்தில், பெரிய தரவுத்தளங்கள் RPO மற்றும் காப்புச் சாளர தேவைகளைப் பூர்த்தி செய்து, பல த்ரெட்களில் உள்ள தொகுதிகளில் காப்புப் பிரதி எடுக்கப்படுகின்றன. கணினியில் சுமை முக்கியமற்றது: முழு நகல்களும் அடிக்கடி நிகழாது, மற்ற நாட்களில் பதிவுகள் மட்டுமே சேகரிக்கப்படுகின்றன, மற்றும் குறைந்த சுமை காலங்களில்.

PostgreSQL காப்பகப் பதிவுகளை காப்புப் பிரதி எடுப்பதற்கான தனிக் கொள்கைகளைப் பயன்படுத்தியுள்ளோம் - அவை வெவ்வேறு விதிகளின்படி சேமிக்கப்படுகின்றன, வேறு அட்டவணையின்படி நகலெடுக்கப்படுகின்றன, மேலும் இந்தப் பதிவுகளில் தனிப்பட்ட தரவு இருப்பதால், அவற்றிற்குக் குறைப்பு இயக்கப்படவில்லை.

முழு ஐடி உள்கட்டமைப்பு முழுவதும் நிலைத்தன்மையை உறுதிப்படுத்த, ஒவ்வொரு கிளஸ்டர் முனைகளிலும் தனித்தனி Commvault கோப்பு கிளையண்டுகள் நிறுவப்பட்டுள்ளன. அவை போஸ்ட்கிரெஸ் கோப்புகளை காப்புப்பிரதிகளிலிருந்து விலக்குகின்றன, மேலும் அவை OS மற்றும் பயன்பாட்டு காப்புப்பிரதிகளுக்கு மட்டுமே நோக்கம் கொண்டவை. தரவின் இந்த பகுதிக்கு அதன் சொந்த கொள்கை மற்றும் சேமிப்பக காலம் உள்ளது.

தற்போது, ​​IBS உற்பத்தித்திறன் சேவைகளை பாதிக்காது, ஆனால் நிலைமை மாறினால், Commvault சுமை கட்டுப்படுத்தலை இயக்க முடியும்.

இது நன்றாக இருக்கிறதா? நல்ல!

எனவே, நாங்கள் வேலை செய்யக்கூடியது மட்டுமல்ல, PostgreSQL கிளஸ்டர் நிறுவலுக்கான முழுமையான தானியங்கு காப்புப்பிரதியையும் பெற்றுள்ளோம், மேலும் இது நிறுவன அழைப்புகளுக்கான அனைத்துத் தேவைகளையும் பூர்த்தி செய்கிறது.

1 மணிநேரம் மற்றும் 2 மணிநேரத்தின் RPO மற்றும் RTO அளவுருக்கள் ஒரு விளிம்புடன் மூடப்பட்டுள்ளன, அதாவது சேமிக்கப்பட்ட தரவின் அளவு கணிசமாக அதிகரித்தாலும் கணினி அவற்றுடன் இணங்கும். பல சந்தேகங்களுக்கு மாறாக, PostgreSQL மற்றும் நிறுவன சூழல் மிகவும் இணக்கமாக இருந்தது. அத்தகைய DBMSகளுக்கான காப்புப்பிரதியானது பல்வேறு வகையான உள்ளமைவுகளில் சாத்தியமாகும் என்பதை எங்கள் சொந்த அனுபவத்திலிருந்து இப்போது நாம் அறிவோம்.

நிச்சயமாக, இந்த பாதையில் நாங்கள் ஏழு ஜோடி இரும்பு காலணிகளை அணிய வேண்டும், பல சிரமங்களை சமாளிக்க வேண்டும், பல ரேக்குகளை மிதிக்க வேண்டும் மற்றும் பல தவறுகளை சரிசெய்ய வேண்டும். ஆனால் இப்போது அணுகுமுறை ஏற்கனவே சோதிக்கப்பட்டது மற்றும் கடுமையான நிறுவன நிலைமைகளில் தனியுரிம DBMS க்கு பதிலாக திறந்த மூலத்தை செயல்படுத்த பயன்படுத்தலாம்.

கார்ப்பரேட் சூழலில் PostgreSQL உடன் பணிபுரிய முயற்சித்தீர்களா?

ஆசிரியர்கள்:

Oleg Lavrenov, தரவு சேமிப்பு அமைப்புகளின் வடிவமைப்பு பொறியாளர், ஜெட் இன்ஃபோசிஸ்டம்ஸ்

டிமிட்ரி எரிகின், ஜெட் இன்ஃபோசிஸ்டம்ஸ் கணினி அமைப்புகளின் வடிவமைப்பு பொறியாளர்

ஆதாரம்: www.habr.com