800 மில்லியன் ChatGPT பயனர்களை இயக்க PostgreSQL-ஐ விரிவாக்குதல்

பல ஆண்டுகளாக, PostgreSQL என்பது ChatGPT மற்றும் OpenAI API போன்ற முக்கிய தயாரிப்புகளை இயக்கும் மிக முக்கியமான, பின்னணி தரவுத்தொகுப்புகளில் ஒன்றாக இருந்து வருகிறது. எங்கள் பயனர் அடிப்படை வேகமாக வளருவதால், எங்கள் தரவுத்தளங்களின் மீதான தேவைகளும் அதே அளவுக்கு அதிகரித்துள்ளன. கடந்த ஓராண்டில், எங்களின் PostgreSQL சுமை 10 மடங்குக்கு மேல் அதிகரித்துள்ளது, மேலும் அது தொடர்ந்து வேகமாக உயர்ந்து கொண்டிருக்கிறது.

இந்த வளர்ச்சியைத் தக்கவைக்க எங்கள் உற்பத்தி உள்கட்டமைப்பை மேம்படுத்துவதற்கான எங்கள் முயற்சிகள் ஒரு புதிய நுண்ணறிவை வெளிப்படுத்தின: முன்னர் நினைத்ததை விட மிகப் பெரிய படிக்க-கனமான பணிச்சுமைகளை நம்பத்தகுந்த வகையில் ஆதரிக்க PostgreSQL ஐ அளவிட முடியும். இந்த அமைப்பு (ஆரம்பத்தில் கலிபோர்னியா பல்கலைக்கழகம், Berkeleyயில் உள்ள விஞ்ஞானிகள் குழுவால் உருவாக்கப்பட்டது) ஒரு ஒற்றை முதன்மை Azure PostgreSQL flexible server instance⁠(புதிய சாளரத்தில் திறக்கும்) மற்றும் உலகளாவிய பல பகுதிகளில் பரவியுள்ள கிட்டத்தட்ட 50 வாசிப்பு பிரதிகளுடன் மிகப்பெரிய உலகளாவிய போக்குவரத்தை ஆதரிக்க எங்களுக்கு உதவியுள்ளது. இது OpenAI-யில் PostgreSQL-ஐ எவ்வாறு நூறு மில்லியன் பயனர்களுக்காக ஒரு வினாடிக்கு மில்லியன் கேள்விகளுக்கு ஆதரவளிக்கும் அளவிற்கு விருத்தி செய்தோம் என்பதற்கான கதை; நாங்கள் செய்த கடுமையான சீர்திருத்தங்கள் மற்றும் வலுவான பொறியியல் பணிகள், மேலும் பயனுள்ள கற்றல்களைப் பகிர்கிறோம்.

ChatGPT வெளியிடப்பட்ட பிறகு, பயனர் போக்குவரத்து மிக வேகமாக உயர்ந்தது. இதற்கு ஆதரவு வழங்க, நாங்கள் செயலியில் மற்றும் PostgreSQL தரவுத்தளத் தளங்களிலும் விரைவாக விரிவான சீர்திருத்தங்களை செயல்படுத்தினோம், இன்ஸ்டன்ஸ் அளவை அதிகரித்து அளவுருவை பெரிதாக்கினோம், மேலும் படிக்கும் நகல்கள் (read replicas) சேர்த்து வெளிப்புற அளவுருவையும் விரிவாக்கினோம். இந்த கட்டமைப்பு நீண்ட காலமாக எங்களுக்கு நன்றாக சேவை செய்துள்ளது. தொடர்ந்து மேம்படுத்தப்பட்டு வருவதால், இது எதிர்கால வளர்ச்சிக்கான போதுமான வாய்ப்புகளை தொடர்ந்து வழங்குகிறது.

ஒரே முதன்மை கட்டமைப்பு OpenAI அளவின் தேவைகளை பூர்த்தி செய்ய முடியும் என்பது ஆச்சரியமாக இருக்கலாம்; ஆனால், இதை நடைமுறையில் செயல்படுத்துவது எளிதானது அல்ல. Postgres அதிகபரப்பு காரணமாக பல SEV-களை நாங்கள் சந்தித்துள்ளோம், அவை பெரும்பாலும் ஒரே மாதிரியான படிப்பினையை பின்பற்றுகின்றன: மேலமைப்பு பிரச்சனை (upstream issue) தரவுத்தளத்தில் திடீர் சுமையை உருவாக்குகிறது, உதாரணமாக கேச்சிங் லேயர் தோல்வியால் பரவலான கேச் தவறுகள், விலகிய பல-வழி இணைப்புகள் (multi-way joins) காரணமாக CPU பரிமாற்றம் அடைதல், அல்லது புதிய அம்ச வெளியீட்டால் எழுதும் புயல் (write storm) போன்றவை. வளப் பயன்பாடு அதிகரிக்கும்போது, வினவல் தாமதம் அதிகரிக்கிறது மற்றும் கோரிக்கைகள் நேரம் முடிவடையத் தொடங்குகின்றன. மீண்டும் முயற்சிகள் சுமையை மேலும் அதிகரித்து, முழு ChatGPT மற்றும் API சேவைகளை பாதிக்கக்கூடிய தீய சுழற்சியைத் தூண்டுகின்றன.

எங்கள் வாசிப்பு-அதிகமான பணிச்சுமைகளுக்கு PostgreSQL நன்றாக அளவுபடுத்தப்பட்டாலும், அதிக எழுதுதல் போக்குவரத்து உள்ள காலங்களில் நாங்கள் இன்னும் சவால்களை எதிர்கொள்கிறோம். இது பெரும்பாலும் PostgreSQL-ன் multiversion concurrency control (MVCC) செயலாக்கத்தினால் ஏற்படுகிறது, இது எழுதல் அதிகமான பணிச்சுமைகளுக்கு அதை குறைவான திறன் கொண்டதாக ஆக்குகிறது. உதாரணமாக, ஒரு வினவல் ஒரு டூப்பிள் அல்லது ஒரு புலத்தைப் புதுப்பிக்கும்போது, புதிய பதிப்பை உருவாக்க முழு வரிசையும் நகலெடுக்கப்படுகிறது. கனமான எழுதுதல் சுமைகளின் கீழ், இது குறிப்பிடத்தக்க எழுதுதல் பெருக்கத்தை ஏற்படுத்துகிறது. இதனால் படிக்கும் அளவு கூடுகிறது, ஏனெனில் கேள்விகள் சமீபத்திய தரவை பெற பல tuple பதிப்புகள் (மரணமான tuples) மூலம் ஸ்கேன் செய்ய வேண்டி வருகிறது. MVCC, அட்டவணை மற்றும் குறியீட்டு வீக்கம், அதிகரித்த குறியீட்டு பராமரிப்பு மேல்நிலை மற்றும் சிக்கலான ஆட்டோவேகம் டியூனிங் போன்ற கூடுதல் சவால்களை அறிமுகப்படுத்துகிறது. (இந்த பிரச்சினைகள் குறித்து நான் Carnegie Mellon University-யில் உள்ள Prof. Andy Pavlo உடன் சேர்ந்து எழுதிய The Part of PostgreSQL We Hate the Most⁠(புதிய சாளரத்தில் திறக்கும்) என்ற வலைப்பதிவில் விரிவாகக் காணலாம், அது PostgreSQL Wikipedia பக்கத்தில் மேற்கோள் காட்டப்பட்டுள்ளது⁠(புதிய சாளரத்தில் திறக்கும்).)

இந்த வரம்புகளைத் தணிக்கவும் எழுதும் அழுத்தத்தைக் குறைக்கவும், நாங்கள் இடம்பெயர்ந்துள்ளோம், தொடர்ந்து இடம்பெயர்கிறோம், துண்டிக்கக்கூடியவை (அதாவது கிடைமட்டமாகப் பிரிக்கக்கூடிய பணிச்சுமைகள்), Azure Cosmos DB போன்ற ஷார்டு செய்யப்பட்ட அமைப்புகளுக்கான எழுதுதல்-அதிகமான பணிச்சுமைகள், தேவையற்ற எழுதுதல்களை குறைக்க பயன்பாட்டு தர்க்கத்தை மேம்படுத்துதல். நாங்கள் இனி தற்போதைய PostgreSQL செயல்பாட்டில் புதிய அட்டவணைகளைச் சேர்ப்பதை அனுமதிக்கவில்லை. புதிய பணிச்சுமைகள் இயல்பாக துண்டிக்கப்பட்ட அமைப்புகளுக்கு செல்கின்றன.

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

பின்வரும் பிரிவுகளில், நாங்கள் எதிர்கொண்ட சவால்கள் மற்றும் அவற்றை நிவர்த்தி செய்வதற்கும் எதிர்கால செயலிழப்புகளைத் தடுப்பதற்கும் நாங்கள் செயல்படுத்திய விரிவான மேம்படுத்தல்கள், PostgreSQL ஐ அதன் வரம்புகளுக்குத் தள்ளி, வினாடிக்கு மில்லியன் வினவல்களுக்கு (QPS) அளவிடுதல் ஆகியவற்றைப் பற்றி ஆராய்வோம்.

சவால்: ஒரே எழுத்தாளர் மட்டுமே இருந்தால், ஒற்றை-முதன்மை அமைப்பு எழுதுதலை விரிவாக்க முடியாது. எழுதும் அதிகமான ஸ்பைக்குகள் முதன்மை அமைப்பை விரைவாக அதிக சுமையாக்கி, ChatGPT மற்றும் எங்கள் API போன்ற சேவைகளை பாதிக்கலாம்.

தீர்வு: எழுதும் உச்சநிலைகளை கையாள போதுமான திறன் primary க்கு இருப்பதை உறுதிசெய்ய, அதில் உள்ள சுமையை—படிக்கவும் எழுதவும் இரண்டையும்—முடிந்தவரை குறைக்கிறோம். சாத்தியமான இடங்களில் எல்லாம், வாசிப்புப் போக்குவரத்து பிரதிகளுக்கு ஏற்றப்படுகிறது. எனினும், சில வாசிப்பு வினவல்கள் எழுதும் பரிவர்த்தனைகளின் ஒரு பகுதியாக இருப்பதால், அவை முதன்மை தரவுத்தொகுப்பிலேயே இருக்க வேண்டும். அவற்றிற்காக, அவை திறமையாக இருப்பதை உறுதி செய்வதிலும் மெதுவான கேள்விகளைத் தவிர்ப்பதிலும் நாங்கள் கவனம் செலுத்துகிறோம். எழுதும் போக்குவரத்திற்காக, பகுக்கக்கூடிய, அதிக எழுதும் பணிச்சுமைகளை Azure CosmosDB போன்ற பகுக்கப்பட்ட அமைப்புகளுக்கு நாங்கள் மாற்றியுள்ளோம். பிரிக்க கடினமான, ஆனால் அதிக எழுதும் அளவை உருவாக்கும் பணிச்சுமைகள் இடமாற்றம் செய்ய அதிக நேரம் எடுக்கின்றன, மேலும் அந்த செயல்முறை இன்னும் நடைபெற்று கொண்டிருக்கிறது. “நாங்கள் எழுதும் சுமையை குறைக்க எங்கள் செயலிகளை தீவிரமாக சீர்திருத்தினோம்; உதாரணமாக, மீண்டும் எழுதுதலை (redundant writes) உருவாக்கிய செயலி பிழைகளை சரிசெய்தோம் மற்றும் போக்குவரத்து உச்சநிலைகளைக் கையாள, தேவையான இடங்களில் lazy writes -ஐ அறிமுகம் செய்தோம். மேலும், அட்டவணை புலங்களை மீண்டும் நிரப்பும்போது, அதிகமான எழுதும் சுமையைத் தவிர்க்கக் கடுமையான வேகக் கட்டுப்பாடுகளை பின்பற்றுகிறோம்.

சவால்: PostgreSQL இல் பல செலவான வினவல்களை நாங்கள் கண்டறிந்துள்ளோம். கடந்த காலத்தில், இந்த வினவல்களில் திடீர் அளவிலான ஸ்பைக்குகள் அதிக அளவு CPU-வை பயன்படுத்தி, ChatGPT மற்றும் API கோரிக்கைகளை மெதுவாக்கின.

தீர்வு: பல அட்டவணைகளை இணைப்பது போன்ற சில உயர்விலைசார் கேள்விகள் முழு சேவையை முக்கியமாக குறைக்கவோ, பாதிப்பதோ கூட செய்யலாம். நாம் PostgreSQL வினவல்களை தொடர்ந்து மேம்படுத்தி, அவை செயல்திறனுடன் இருப்பதை உறுதி செய்ய வேண்டும் மற்றும் பொதுவான Online Transaction Processing (OLTP) எதிர்முறைகளைத் தவிர்க்க வேண்டும். உதாரணமாக, 12 அட்டவணைகளை இணைத்த ஒரு மிக அதிக உயர்விலைசார் வினவலை நாங்கள் ஒருமுறை அடையாளம் கண்டோம், இந்த வினவலில் ஏற்பட்ட திடீர் உயர்வுகள் கடந்த காலத்தில் உயர்-தீவிரத்தன்மை SEVs க்கு காரணமாக இருந்தன. சாத்தியமான எல்லா சந்தர்ப்பங்களிலும் சிக்கலான பல அட்டவணை இணைப்புகளை தவிர்க்க வேண்டும். நிகழ்வுகள் அவசியமாக இருந்தால், கேள்வியை பிரித்து, சிக்கலான இணைப்பு தர்க்கத்தை பயன்பாட்டு அடுக்கு நோக்கி மாற்றுவதைக் கருத்தில் கொள்ள கற்றுக்கொண்டோம். இந்த சிக்கலான வினவல்களில் பல, Object-Relational Mapping frameworks (ORMs) மூலம் உருவாக்கப்படுகின்றன, எனவே அவை உருவாக்கும் SQL-ஐ கவனமாக பரிசீலித்து, அது எதிர்பார்த்தபடி செயல்படுகிறதா என்பதை உறுதிப்படுத்துவது முக்கியம். PostgreSQL-இல் நீண்ட நேரம் செயலற்ற நிலையில் இருக்கும் வினவல்களை காண்பது பொதுவானது. idle_in_transaction_session_timeout போன்ற நேர முடிவுகளை உள்ளமைப்பது அவற்றால் autovacuum ஐ தடுக்காமல் இருக்க அவசியம்.

சவால்: ஒரு read replica செயலிழந்தால், போக்குவரத்தை இன்னும் பிற replicas க்கு மாற்றலாம். எனினும், ஒரே ஒரு எழுத்தாளரை நம்புவது என்பது ஒரே ஒரு தோல்விப் புள்ளியை வைத்திருப்பதைக் குறிக்கிறது—அது செயலிழந்தால், முழு சேவையும் பாதிக்கப்படும்.

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

முதன்மை தோல்விகளைத் தணிக்க, நாங்கள் முதன்மையை உயர்-கிடைக்கும் தன்மை (HA) பயன்முறையில் தொடர்ந்து ஒத்திசைக்கப்படும் முறையில் இயக்குகிறோம், இது தொடர்ந்து ஒத்திசைக்கப்பட்ட பிரதியாகும், இது எப்போதும் சேவை போக்குவரத்தை எடுத்துக்கொள்ளத் தயாராக இருக்கும். முதன்மை செயலிழந்தாலோ அல்லது பராமரிப்பிற்காக ஆஃப்லைனில் எடுக்க வேண்டியிருந்தாலோ, இடைநிறுத்த நேரத்தை குறைக்க காத்திருப்பை விரைவாக முதன்மையாக உயர்த்த முடியும். மிக அதிக சுமை இருந்தாலும் கூட, இந்த failover கள் பாதுகாப்பாகவும் நம்பகமாகவும் இருக்க Azure PostgreSQL குழு குறிப்பிடத்தக்க பணியை செய்துள்ளது. படிக்கும் நகல் (read replica) தோல்விகளை கையாள, ஒவ்வொரு பிரதேசத்திலும் (region) பல நகல்களை போட்டு, போதுமான திறன் வைத்துள்ளோம், இதனால் ஒரு நகல் தோல்வி பிரதேச முழுவதும் சேவை நிறுத்தத்தை ஏற்படுத்தாது.

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

தீர்வு: தாமதத்தை குறைக்க, பல புவியியல் பகுதிகளில் கிட்டத்தட்ட 50 வாசிப்பு பிரதிகளை நாங்கள் இயக்குகிறோம். ஆனால், தற்போதைய கட்டமைப்பில், முதன்மை ஒவ்வொரு பிரதிக்கும் WAL ஐ ஸ்ட்ரீம் செய்ய வேண்டும். தற்போது மிகப்பெரிய இன்ஸ்டன்ஸ் வகைகள் மற்றும் உயர்ந்த நெட்வொர்க் அகலத்துடன் (high-network bandwidth) நல்ல அளவிற்கு விரிவாக்கம் செய்யலாம் எனினும், முதன்மையை (primary) இறுதியாக அதிகசுமைக்கு ஆளாக்காமல், நாங்கள் நகல்களை (replicas) எப்போதும் தொடர முடியாது. இதைச் சமாளிக்க, இடைநிலை பிரதிகள் கீழ்நிலை பிரதிகளுக்கு WAL-ஐ அனுப்பும் காஸ்கேடிங் ரெப்ளிகேஷன்⁠(புதிய சாளரத்தில் திறக்கும்) குறித்து Azure PostgreSQL குழுவுடன் நாங்கள் ஒத்துழைக்கிறோம். இந்த அணுகுமுறை, முதன்மையை அதிக சுமையாக்காமல், சாத்தியமாக நூற்றுக்கும் மேற்பட்ட பிரதிகளை விரிவாக்க அனுமதிக்கிறது. எனினும், இது கூடுதல் செயல்பாட்டு சிக்கலையும் அறிமுகப்படுத்துகிறது, குறிப்பாக பிழைதிருத்த மேலாண்மை தொடர்பாக. இந்த அம்சம் இன்னும் சோதனையில் உள்ளது; இதை உற்பத்திக்கு வெளியிடுவதற்கு முன் இது உறுதியானதாகவும் பாதுகாப்பாக செயலிழக்காமல் மாற்றிக்கொள்ளக்கூடியதாகவும் இருப்பதை உறுதிசெய்வோம்.

சவால்: குறிப்பிட்ட எண்ட்பாயிண்ட்களில் திடீர் போக்குவரத்து அதிகரிப்பு, விலையுயர்ந்த வினவல்களின் அதிகரிப்பு அல்லது மீண்டும் முயற்சிக்கும் புயல் ஆகியவை CPU, I/O மற்றும் இணைப்புகள் போன்ற முக்கியமான வளங்களை விரைவாகக் காலியாக்கி, பரவலான சேவைச் சீரழிவை ஏற்படுத்தும்.

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

சவால்: ஒரு நெடுவரிசை வகையை மாற்றுவது போன்ற சிறிய ஸ்கீமா மாற்றம் கூட முழு அட்டவணை மறுபதிவை⁠(புதிய சாளரத்தில் திறக்கும்) தூண்டக்கூடும். எனவே, நாங்கள் ஸ்கீமா மாற்றங்களை எச்சரிக்கையுடன் செயல்படுத்துகிறோம்—அவற்றை இலகுவான செயல்பாடுகளுக்கு மட்டுமே கட்டுப்படுத்தி, முழு அட்டவணைகளையும் மறுபதிவு செய்யும் எந்த மாற்றங்களையும் தவிர்க்கிறோம்.

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

சரியான வடிவமைப்பு மற்றும் மேம்படுத்தல்களுடன், மிகப்பெரிய உற்பத்தி பணிச்சுமைகளைக் கையாள Azure PostgreSQL ஐ அளவிட முடியும் என்பதை இந்த முயற்சி நிரூபிக்கிறது. PostgreSQL வாசிப்பு-மிகுதியான பணிச்சுமைகளுக்காக மில்லியன் கணக்கான QPS-ஐ கையாள்கிறது, ChatGPT மற்றும் API பிளாட்ஃபார்ம் போன்ற OpenAI-யின் மிக முக்கியமான தயாரிப்புகளுக்கு ஆற்றல் வழங்குகிறது. பிரதிபலிப்பு தாமதத்தை கிட்டத்தட்ட பூஜ்யமாக வைத்துக்கொண்டே, நாங்கள் கிட்டத்தட்ட 50 ரீட் ரெப்ளிகாக்களைச் சேர்த்தோம், புவியியல் ரீதியாகப் பகிரப்பட்ட பகுதிகளெங்கும் குறைந்த தாமத வாசிப்புகளைப் பராமரித்தோம், மேலும் எதிர்கால வளர்ச்சியை ஆதரிக்க போதுமான திறன் இடைவெளியையும் உருவாக்கினோம்.

இந்த அளவாக்கம் தாமத நேரத்தை குறைந்தபட்சமாக வைத்துக்கொண்டே செயல்பட்டு, நம்பகத்தன்மையை மேம்படுத்துகிறது. நாங்கள் உற்பத்தியில் தொடர்ந்து குறைந்த இரட்டை இலக்க மில்லிவினாடி p99 கிளையன்ட்-பக்க தாமதத்தையும் ஐந்து-ஒன்பது கிடைப்புத்தன்மையையும் வழங்குகிறோம். கடந்த 12 மாதங்களில், ஒரே ஒரு SEV-0 PostgreSQL சம்பவத்தை மட்டுமே நாங்கள் சந்தித்துள்ளோம் (இது ChatGPT ImageGen இன் வைரல் வெளியீட்டின்⁠(புதிய சாளரத்தில் திறக்கும்) போது நிகழ்ந்தது, ஒரு வாரத்திற்குள் 100 மில்லியனுக்கும் அதிகமான புதிய பயனர்கள் பதிவு செய்ததால் எழுதும் போக்குவரத்து திடீரென 10 மடங்குக்கு மேல் அதிகரித்தது.)

PostgreSQL எங்களை எவ்வளவு தூரம் கொண்டு வந்துள்ளது என்பதில் நாங்கள் மகிழ்ச்சியடைந்திருந்தாலும், எதிர்கால வளர்ச்சிக்காக போதுமான முன்னேற்றம் இருப்பதை உறுதிசெய்ய அதன் வரம்புகளை நாங்கள் தொடர்ந்து தள்ளிச் செலுத்துகிறோம். நாங்கள் ஏற்கனவே shard செய்யக்கூடிய அதிக எழுதும் பணிச்சுமைகளை CosmosDB போன்ற எங்கள் sharded அமைப்புகளுக்கு இடம்பெயர்த்துள்ளோம். மீதமுள்ள அதிக எழுதுதல் பணிச்சுமைகள் பகிர்வதற்கு சவாலாக உள்ளன—PostgreSQL primary இலிருந்து எழுதுதலை மேலும் குறைக்க, அவற்றையும் நாங்கள் செயற்பாட்டுடன் இடமாற்றம் செய்து வருகிறோம். குறிப்பிடத்தக்க அளவு அதிகமான read replicas க்கு நாங்கள் பாதுகாப்பாக அளவுபடுத்த முடியும் வகையில் cascading replication ஐ செயல்படுத்த Azure-உடனும் நாங்கள் பணியாற்றி வருகிறோம்.

எதிர்காலத்தை நோக்கி, எங்கள் உள்கட்டமைப்பு தேவைகள் தொடர்ந்து வளர்ந்து கொண்டிருப்பதால், sharded PostgreSQL அல்லது மாற்று distributed systems போன்றவற்றை உள்ளடக்கிய, மேலும் விரிவுபடுத்த கூடுதல் அணுகுமுறைகளை நாங்கள் தொடர்ந்து ஆராய்வோம்.