800 మిలియన్ ChatGPT యూజర్‌లకు శక్తినిచ్చేందుకు PostgreSQL విస్తరణ

ఎన్నో సంవత్సరాలుగా, PostgreSQL అనేది ChatGPT, OpenAI యొక్క API వంటి ప్రధాన ఉత్పత్తులను శక్తివంతం చేసే అత్యంత కీలకమైన, అంతర్గత డేటా సిస్టమ్‌ల్లో ఒకటిగా ఉంది. మా వినియోగదారుల సంఖ్య వేగంగా పెరుగుతున్న కొద్దీ, మా డేటాబేస్‌లపై డిమాండ్లు కూడా గణనీయంగా పెరుగుతున్నాయి. గత ఏడాదిలో, మా PostgreSQL లోడ్ 10 రెట్లు కంటే ఎక్కువగా పెరిగింది, ఇంకా అది వేగంగా పెరుగుతోంది.

ఈ అభివృద్ధిని కొనసాగించడానికి మా ఉత్పత్తి మౌలిక సదుపాయాలను అభివృద్ధి చేయడానికి చేసిన ప్రయత్నాలు ఒక కొత్త అవగాహనను తెచ్చాయి: PostgreSQLను, గతంలో అనుకున్నదానికంటే చాలా పెద్ద రీడ్-హెవీ వర్క్‌లోడ్‌లను నమ్మకంగా మద్దతు ఇవ్వగలిగేలా విస్తరించవచ్చు. ఈ సిస్టమ్ (మొదట యూనివర్శిటీ ఆఫ్ కాలిఫోర్నియా, బర్కిలీలోని శాస్త్రవేత్తల బృందం సృష్టించింది) ఒకే ప్రాథమిక Azure PostgreSQL ఫ్లెక్సిబుల్ సర్వర్ ఇన్‌సర్ట్⁠(కొత్త విండోలో తెరుచుకుంటుంది) మరియు ప్రపంచవ్యాప్తంగా అనేక ప్రాంతాల్లో విస్తరించి ఉన్న దాదాపు 50 రీడ్ రెప్లికాల సహాయంతో భారీ గ్లోబల్ ట్రాఫిక్‌కు మద్దతు ఇవ్వడానికి మాకు వీలు కల్పించింది. OpenAIలో మేం PostgreSQLని ఎలా విస్తరించాం, కఠినమైన ఆప్టిమైజేషన్‌లు మరియు దృఢమైన ఇంజినీరింగ్ ద్వారా, సెకనుకు మిలియన్‌ల క్వెరీలను 800 మిలియన్ వినియోగదారుల కోసం మద్దతు ఇవ్వడానికి, ఇదే కథ. ఈ ప్రయాణంలో మేం నేర్చుకున్న ముఖ్యమైన పాఠాలను కూడా చర్చిస్తాం.

ChatGPT ప్రారంభించిన తర్వాత, ట్రాఫిక్ అనూహ్యంగా పెరిగింది. దీనికి మద్దతు ఇవ్వడానికి, మేము అప్లికేషన్ మరియు PostgreSQL డేటాబేస్ లేయర్‌లు రెండింటిలోనూ విస్తృతమైన ఆప్టిమైజేషన్‌లను వేగంగా అమలు చేశా, ఇన్‌స్టెన్స్ పరిమాణాన్ని పెంచడం ద్వారా విస్తరించాం మరియు మరిన్ని రీడ్ రెప్లికాలను జోడించడం ద్వారా విస్తరించాం. ఈ ఆర్కిటెక్చర్ చాలా కాలంగా మాకు బాగా సేవలందించింది. నిరంతర మెరుగుదలలతో, ఇది భవిష్యత్తు వృద్ధికి విస్తృతమైన అవకాశాలను అందిస్తూనే ఉంది.

ఒకే-ప్రైమరీ ఆర్కిటెక్చర్ OpenAI స్కేల్ అవసరాలను తీర్చగలదని ఆశ్చర్యంగా అనిపించవచ్చు; అయితే, ఈ పనిని ఆచరణలో అమలు చేయడం సులభం కాదు. Postgres ఓవర్‌లోడ్ కారణంగా అనేక SEVs‌ను మేం చూశాం, అవి తరచూ ఒకే విధమైన ప్యాటర్న్‌ను అనుసరిస్తాయి: అప్‌స్ట్రీమ్ సమస్య డేటాబేస్ లోడ్‌లో ఆకస్మిక పెరుగుదలకు దారితీస్తుంది, ఉదాహరణకు కాచింగ్-లేయర్ వైఫల్యం నుండి విస్తృతమైన కాష్ మిస్ లు, ఖరీదైన బహుళ-మార్గం సంతృప్త CPU లో చేరడం లేదా క్రొత్త ఫీచర్ లాంచ్ నుండి రైట్ స్ట్రోమ్. వనరుల వినియోగం పెరిగేకొద్దీ, క్వెరీ లేటెన్సీ పెరుగుతుంది, అభ్యర్థనల సమయం ముగియడం ప్రారంభమవుతుంది. రీట్రైలు ఆపై లోడ్‌ను మరింతగా పెంచి, మొత్తం ChatGPT మరియు API సేవలను దిగజార్చే అవకాశం ఉన్న విషవలయానికి దారితీస్తాయి.

PostgreSQL మా రీడ్-హెవీ వర్క్‌లోడ్‌లకు బాగా విస్తరించినప్పటికీ, అధిక రైట్ ట్రాఫిక్ సమయంలో మేం ఇంకా సవాళ్లను ఎదుర్కొంటున్నాం. ఇది ప్రధానంగా PostgreSQL మల్టీవర్షన్ కన్కరెన్సీ కంట్రోల్ (MVCC) అమలు వల్ల, ఇది ఎక్కువ రైటింగ్ అవసరమయ్యే వర్క్‌లోడ్‌లకు తక్కువ సమర్థవంతంగా ఉంటుంది. ఉదాహరణకు, ఒక క్వెరీ ఒక ట్యుపుల్‌ను లేదా ఒక్క ఫీల్డ్‌ను కూడా అప్‌డేట్ చేసినప్పుడు, కొత్త వెర్షన్‌ను సృష్టించడానికి మొత్తం వరసను కాపీ చేస్తారు. భారీ రైట్ లోడ్స్‌లో, ఇది గణనీయమైన రైట్ యాంప్లిఫికేషన్‌కు దారితీస్తుంది. ఇది రీడ్ యాంప్లిఫికేషన్‌ను కూడా పెంచుతుంది, ఎందుకంటే తాజా ట్యుపుల్‌ను పొందడానికి క్వెరీలు అనేక ట్యుపుల్ వెర్షన్‌ల (మృత ట్యుపుల్స్) ద్వారా స్కాన్ చేయాల్సి ఉంటుంది. MVCC టేబుల్ మరియు సూచిక బ్లోట్, పెరిగిన సూచిక నిర్వహణ ఓవర్‌హెడ్, మరియు క్లిష్టమైన ఆటోవ్యాక్యూమ్ ట్యూనింగ్ వంటి అదనపు సవాళ్లను పరిచయం చేస్తుంది. (ఈ అంశాలపై లోతైన విశ్లేషణను కార్నెగీ మెల్లన్ విశ్వవిద్యాలయంలో ప్రొఫెసర్ ఆండీ పావ్లోతో కలిసి నేను రాసిన 'ది పార్ట్ ఆఫ్ పోస్ట్‌గ్రెస్‌స్క్యూల్ వి హేట్ ది మోస్ట్'⁠(కొత్త విండోలో తెరుచుకుంటుంది) అనే బ్లాగులో చూడవచ్చు, దీనిని పోస్ట్‌గ్రెస్‌స్క్యూల్ వికీపీడియా పేజీలో ఉదహరించారు⁠(కొత్త విండోలో తెరుచుకుంటుంది) .)

ఈ పరిమితులను తగ్గించడానికి మరియు రైట్ ప్రెషర్‌ను తగ్గించడానికి, మేం షార్డబుల్ భాగాలను మైగ్రేట్ చేశాం మరియు కొనసాగిస్తూ మైగ్రేట్ చేస్తున్నాము (అంటే. హారిజాంటల్‌గా విభజించదగిన వర్క్‌లోడ్‌లను, అంటే అధిక రైట్ ఆపరేషన్లు ఉండే పనులను, Azure Cosmos DBవంటి షార్డెడ్ సిస్టమ్స్‌కు తరలిస్తున్నాము. అలాగే, అనవసరమైన రైట్ ఆపరేషన్‌లను తగ్గించడానికి అప్లికేషన్ లాజిక్‌ను ఆప్టిమైజ్ చేస్తున్నాం. మేం ప్రస్తుత PostgreSQL డిప్లాయ్‌మెంట్‌కు కొత్త టేబుల్‌లను జోడించడాన్ని ఇకపై అనుమతించం. కొత్త వర్క్‌లోడ్‌లు డిఫాల్ట్‌గా షార్డ్ సిస్టమ్‌లకు వెళ్తాయి.

మా మౌలిక సదుపాయాలు అభివృద్ధి చెందినప్పటికీ, PostgreSQL షార్డింగ్ చేయలేదు, అన్ని రైట్స్‌కు ఒకే ప్రాథమిక ఇన్‌స్టాన్స్ సేవలందిస్తోంది. ప్రస్తుతం ఉన్న అప్లికేషన్ వర్క్‌లోడ్‌లను షార్డింగ్ చేయడం అనేది అత్యంత క్లిష్టమైనది మరియు సమయంతో కూడుకున్న పని. దీని కోసం వందలాది అప్లికేషన్ ఎండ్‌పాయింట్‌లలో మార్పులు చేయాల్సి ఉంటుంది, దీనికి కొన్ని నెలలు లేదా సంవత్సరాల సమయం పట్టే అవకాశం ఉంది, ఇదే దీని వెనుక ఉన్న ప్రధాన కారణం. మా వర్క్‌లోడ్‌లు ప్రధానంగా చదవడానికి ఎక్కువగా ఉంటాయి, మేం విస్తృతమైన ఆప్టిమైజేషన్‌లను అమలు చేయడం వల్ల, ప్రస్తుత ఆర్కిటెక్చర్ ఇంకా కొనసాగుతున్న ట్రాఫిక్ అభివృద్ధి చెందడానికి తగినంత స్థలం అందిస్తోంది. భవిష్యత్తులో PostgreSQLని షార్డింగ్ చేసే అవకాశాన్ని మేము పూర్తిగా తోసిపుచ్చనప్పటికీ, ప్రస్తుత మరియు భవిష్యత్తు వృద్ధికి సరిపడా సామర్థ్యం ఉన్నందున, ఇది ప్రస్తుతానికి ప్రాధాన్యత కలిగిన అంశం కాదు.

కింది విభాగాలలో, మేం ఎదుర్కొన్న సవాళ్లను మరియు వాటిని పరిష్కరించడానికి మరియు భవిష్యత్తులో అంతరాయాలను నివారించడానికి మేం అమలు చేసిన విస్తృతమైన ఆప్టిమైజేషన్‌లను పరిశీలిస్తాం, PostgreSQLను దాని పరిమితులకు నెట్టివేస్తాము మరియు సెకనుకు మిలియన్‌ల ప్రశ్నలకు (QPS) విస్తరిస్తాం.

సవాలు: ఒకే రైటర్‌తో, సింగిల్-ప్రైమరీ సెటప్ రైట్స్‌ను విస్తరించలేం. భారీ రైట్ స్పైక్‌లు ప్రైమరీని త్వరగా ఓవర్‌లోడ్ చేసి ChatGPT మరియు మా API వంటి సర్వీస్‌లపై ప్రభావం చూపించవచ్చు.

పరిష్కారం: రైట్ స్పైక్‌లను నిర్వహించడానికి దానికి తగిన సామర్థ్యం ఉండేలా, మేం ప్రైమరీపై లోడ్‌ను సాధ్యమైనంత వరకు—రీడ్ మరియు రైట్‌లు రెండింటినీ—తగ్గిస్తాం. రీడ్ ట్రాఫిక్ సాధ్యమైన చోట ప్రతిరూపాలకు ఆఫ్‌లోడ్ చేయబడుతుంది. ఏదేమైనా, కొన్ని రీడ్ క్వైరీలు ప్రాథమికంగా ఉండాలి ఎందుకంటే అవి రైట్ లావాదేవీల్లో భాగం. వాటి కోసం, మేము అవి సమర్థవంతంగా పనిచేసేలా చూడటం మరియు నెమ్మదిగా ఉండే క్వెరీలను నివారించడంపై దృష్టి పెడతాం. రైట్ ట్రాఫిక్ కొరకు, Azure CosmosDB వంటి షార్డెడ్ సిస్టమ్‌లకు షార్డబుల్, రైట్ హెవీ వర్క్‌లోడ్‌లను మేం మైగ్రేట్ చేశాం. షార్డ్ చేయడం కష్టమైనప్పటికీ ఇంకా అధిక రైట్ వాల్యూమ్‌ను ఉత్పత్తి చేసే వర్క్‌లోడ్లు మైగ్రేట్ చేయడానికి ఎక్కువ సమయం పడుతుంది, మరియు ఆ ప్రక్రియ ఇంకా కొనసాగుతోంది. రైట్ లోడ్‌ను తగ్గించడానికి మేం మా అప్లికేషన్లను కూడా దూకుడుగా ఆప్టిమైజ్ చేశాం; ఉదాహరణకు, పునరావృత రైట్స్‌కు కారణమైన అప్లికేషన్ బగ్‌లను మేం సరిచేశాం మరియు ట్రాఫిక్ స్పైక్స్‌ను సాఫీగా చేయడానికి, అవసరమైన చోట, లేజీ రైట్స్‌ను ప్రవేశపెట్టాము. అదనంగా, టేబుల్ ఫీల్డ్‌లను బ్యాక్‌ఫిల్ చేస్తున్నప్పుడు, అధిక రైటింగ్ ఒత్తిడిని నివారించడానికి మేం కఠినమైన రేట్ పరిమితులను అమలు చేస్తాము.

సవాలు: మేం PostgreSQLలో అనేక ఖరీదైన క్వెరీస్‌ను గుర్తించాం. గతంలో, ఈ ప్రశ్నల్లో ఆకస్మిక వాల్యూం పెరుగుదలలు పెద్ద మొత్తంలో CPUని వినియోగించేవి, దాంతో ChatGPT మరియు API అభ్యర్థనలు రెండింటినీ నెమ్మదింపజేసేవి.

పరిష్కారం: అనేక టేబుల్స్‌ను కలిపే కొన్ని ఖరీదైన క్వెరీలు, మొత్తం సర్వీస్‌ను గణనీయంగా తగ్గించవచ్చు లేదా పూర్తిగా నిలిపివేయవచ్చు. PostgreSQL క్వెరీలను సమర్థవంతంగా ఉండేలా నిరంతరం ఆప్టిమైజ్ చేయాలి, తద్వారా అవి సాధారణ ఆన్‌లైన్ ట్రాన్సాక్షన్ ప్రాసెసింగ్(OLTP) యాంటీ-ప్యాటర్న్‌లను నివారించగలవు. ఉదాహరణకు, మేం ఒకసారి 12 టేబుల్స్‌ను కలిపిన అత్యంత ఖరీదైన క్వెరీని గుర్తించాం, ఇందులో ఈ క్వెరీలో వచ్చే స్పైక్స్ గతంలో అధిక తీవ్రత కలిగిన SEVs‌కు కారణమయ్యాయి. సాధ్యమైనప్పుడల్లా క్లిష్టమైన బహుళ టేబుల్స్‌ను కలపడాన్ని నివారించాలి. కలపడం అవసరమైతే, క్వెరీని విభజించి, క్లిష్టమైన జాయిన్ లాజిక్‌ను అప్లికేషన్ లేయర్‌కు తరలించమని మేం నేర్చుకున్నాం. ఈ సమస్యాత్మక క్వెరీల్లో చాలావరకు ఆబ్జెక్ట్ రిలేషనల్ మ్యాపింగ్ ఫ్రేమ్‌వర్క్‌లు (ORMs) ద్వారా ఉత్పత్తి చేయబడతాయి, కాబట్టి అవి ఉత్పత్తి చేసే SQLను జాగ్రత్తగా సమీక్షించి, అది ఆశించినట్లుగా ప్రవర్తిస్తోందని నిర్ధారించుకోవడం ముఖ్యం. PostgreSQLలో దీర్ఘకాలం నడిచే నిర్జీవ క్వెరీలు కనిపించడం కూడా సాధారణం. idle_in_transaction_session_timeout వంటి టైమ్ ఔట్‌లను కాన్ఫిగర్ చేయడం autovacuum‌ను బ్లాక్ చేయకుండా నిరోధించడానికి అవసరం.

సవాలు: ఒక రీడ్ రెప్లికా డౌన్ అయితే, ట్రాఫిక్‌ను ఇంకా ఇతర replicas కు మళ్లించవచ్చు. అయితే, ఒకే రచయితపై ఆధారపడటం అంటే ఒకే వైఫల్య బిందువు ఉండటం—అది పనిచేయకపోతే, మొత్తం సర్వీస్ ప్రభావితం అవుతుంది.

పరిష్కారం: చాలా క్లిష్టమైన అభ్యర్థనలు చదివిన ప్రశ్నలను మాత్రమే ఉంటాయి. ప్రైమరీలో తలెత్తే ఒకే ఒక వైఫల్య బిందువును నివారించడానికి, మేం ఆ రీడ్ ఆపరేషన్‌లను రైటర్ నుండి రెప్లికాలకు బదిలీ చేశాం. దీనివల్ల ప్రైమరీ సర్వర్ నిలిచిపోయినప్పటికీ, రీడ్ అభ్యర్థనలు నిరంతరాయంగా కొనసాగుతాయని మేం నిర్ధారించాం. రైట్ ఆపరేషన్‌లు ఇంకా విఫలమవుతూనే ఉన్నప్పటికీ, ప్రభావం తగ్గింది; చదవడం అందుబాటులో ఉండటంతో ఇది ఇకపై SEV0 కాదు.

ప్రైమరీ సర్వర్ వైఫల్యాలను నివారించడానికి, మేం దానిని హాట్ స్టాండ్‌బైతో కూడిన హై-అవైలబిలిటీ మోడ్‌లో నిర్వహిస్తాం. ఇది నిరంతరం సింక్రనైజ్ చేయబడే ఒక నకలు, ఇది ట్రాఫిక్‌ను స్వీకరించడానికి మరియు బాధ్యతలను స్వీకరించడానికి ఎల్లప్పుడూ సిద్ధంగా ఉంటుంది. ప్రైమరీ డౌన్ అయితే లేదా మెయింటెన్స్ కోసం ఆఫ్‌లైన్‌లోకి తీసుకెళ్లాల్సి వస్తే, డౌన్‌టైమ్‌ను తగ్గించడానికి మేం స్టాండ్‌బైను త్వరగా ప్రమోట్ చేయగలం. అత్యధిక లోడ్ ఉన్న సమయంలో కూడా ఈ ఫెయిల్‌ఓవర్ ప్రక్రియలు సురక్షితంగా మరియు నమ్మదగినవిగా ఉండేలా చూడటంలో Azure PostgreSQL బృందం గణనీయమైన కృషి చేసింది. రీడ్ రెప్లికా వైఫల్యాలను ఎదుర్కొనేందుకు, మేం ప్రతి ప్రాంతంలో తగినంత సామర్థ్యాన్ని కలిగి ఉన్న అనేక రెప్లికాలను అమలు చేస్తాం, తద్వారా ఒకే రెప్లికా వైఫల్యం ప్రాంతీయ అంతరాయానికి దారితీయదు.

సవాలు: మేం తరచుగా PostgreSQL ఇన్‌స్టాన్స్‌లపై కొన్ని అభ్యర్థనలు అసమానంగా ఎక్కువ వనరులను వినియోగించే పరిస్థితులను ఎదుర్కొంటాం. ఇది అదే ఇన్‌స్టాన్స్‌లపై నడుస్తున్న ఇతర వర్క్‌లోడ్స్ పనితీరును తగ్గించవచ్చు. ఉదాహరణకు, కొత్త ఫీచర్ ప్రారంభం PostgreSQL CPUని అధికంగా వినియోగించే అసమర్థ క్వెరీలను పరిచయం చేయవచ్చు, తద్వారా ఇతర ముఖ్యమైన ఫీచర్‌ల కోసం అభ్యర్థనలు నెమ్మదిస్తాయి.

పరిష్కారం: “ధ్వనించే పొరుగు” సమస్యను తగ్గించడానికి, వనరు-ఇంటెన్సివ్ అభ్యర్థనలలో ఆకస్మిక స్పైక్‌లు ఇతర ట్రాఫిక్‌ను ప్రభావితం చేయకుండా చూసుకోవడానికి మేం పనిభారాలను అంకితమైన సందర్భాల్లో వేరు చేస్తాం. ప్రత్యేకంగా, మేం అభ్యర్థనలను తక్కువ ప్రాధాన్యత మరియు అధిక ప్రాధాన్యత స్థాయిలుగా విభజించి, వాటిని వేర్వేరు ఇన్‌స్టన్‌లకు పంపిస్తాం. ఈ విధంగా, తక్కువ ప్రాధాన్యత గల వర్క్‌లోడ్ వనరులను అధికంగా వినియోగించినా, అది అధిక ప్రాధాన్యత గల అభ్యర్థనల పనితీరును తగ్గించదు. ఒక ఉత్పత్తి నుండి వచ్చే కార్యకలాపం మరొకదాని పనితీరు లేదా విశ్వసనీయతను ప్రభావితం చేయకుండా ఉండేలా, మేం వేర్వేరు ఉత్పత్తులు మరియు సేవల అంతటా కూడా అదే వ్యూహాన్ని వర్తింపజేస్తాం.

సవాలు: ప్రతి ఇన్‌స్టాన్స్‌కు గరిష్ట కనెక్షన్ పరిమితి ఉంటుంది (Azure PostgreSQLలో 5,000). కనెక్షన్లు అయిపోవడం లేదా చాలా ఎక్కువగా నిరుపయోగమైన కనెక్షన్‌లు పేరుకుపోవడం సులభం. మునుపటి కాలంలో, కనెక్షన్ స్టార్మ్‌ల కారణంగా అందుబాటులో ఉన్న అన్ని కనెక్షన్‌లు పూర్తిగా వినియోగించబడిన ఘటనలు చోటు చేసుకున్నాయి.

పరిష్కారం: డేటాబేస్ కనెక్షన్‌లను పూల్ చేయడానికి మేం ప్రాక్సీ లేయర్‌గా PgBouncer‌ను అమలు చేశాం. స్టేట్‌మెంట్ లేదా ట్రాన్సాక్షన్ పూలింగ్ మోడ్‌లో దాన్ని నడపడం వల్ల మేం కనెక్షన్‌లను సమర్థవంతంగా పునర్వినియోగం చేయగలుగుతాము, తద్వారా యాక్టివ్ క్లయింట్ కనెక్షన్‌ల సంఖ్య గణనీయంగా తగ్గుతుంది. ఇది కనెక్షన్ సెటప్ లేటెన్సీని కూడా తగ్గిస్తుంది: మా బెంచ్‌మార్క్‌లలో, సగటు కనెక్షన్ సమయం 50 మిల్లీసెకన్ల (ms) నుండి 5 మిల్లీసెకన్లకు తగ్గింది. ఇంటర్-రీజియన్ కనెక్షన్‌లు మరియు రిక్వెస్ట్‌లు ఖరీదైనవిగా ఉండవచ్చు, కాబట్టి నెట్‌వర్క్ ఓవర్‌హెడ్‌ను మరియు కనెక్షన్ వినియోగ సమయాన్ని తగ్గించడానికి మేం ప్రాక్సీ, క్లయింట్లు, మరియు రిప్లికాలను అదే రీజియన్‌లో సహ-స్థాపిస్తాము. అదనంగా, PgBouncer‌ను జాగ్రత్తగా కాన్ఫిగర్ చేయాలి. కనెక్షన్ టైమ్ అవుట్‌ను నివారించడానికి ఐడిల్ టైమ్ అవుట్‌లు వంటి సెట్టింగ్‌లు కీలకం.

సవాలు: క్యాష్ మిస్‌లు ఆకస్మికంగా పెరగడం వల్ల PostgreSQL డేటాబేస్‌పై రీడ్‌లలో ఉధృతి ఏర్పడి, CPU సంతృప్తి చెందడం వల్ల వినియోగదారుల అభ్యర్థనలు నెమ్మదిస్తాయి.

పరిష్కారం: PostgreSQL పై చదవు ఒత్తిడిని తగ్గించడానికి, మేం ఎక్కువ భాగం రీడ్ ట్రాఫిక్‌ను అందించడానికి క్యాషింగ్ లేయర్‌ను ఉపయోగిస్తాం. అయితే, క్యాష్ హిట్ రేట్లు అనుకోకుండా పడిపోయినప్పుడు, క్యాష్ మిస్‌ల ఉధృతి పెద్ద మొత్తంలో అభ్యర్థనలను నేరుగా PostgreSQLకు పంపవచ్చు. డేటాబేస్ రీడ్‌ల్లో ఈ ఆకస్మిక పెరుగుదల గణనీయమైన వనరులను వినియోగించి, సర్వీస్‌ను నెమ్మదింపజేస్తుంది. క్యాష్-మిస్ తుఫానుల సమయంలో ఓవర్‌లోడ్‌ను నివారించడానికి, మేం క్యాష్ లాకింగ్ (మరియు లీజింగ్) విధానాన్ని అమలు చేస్తాము, తద్వారా ఒక నిర్దిష్ట కీపై మిస్ అయినప్పుడు ఒక్క రీడర్ మాత్రమే PostgreSQL నుండి డేటాను తీసుకువస్తుంది. ఒకే క్యాష్ కీపై అనేక అభ్యర్థనలు విఫలమైనప్పుడు, ఒకే అభ్యర్థన లాక్‌ను పొందుతుంది, డేటాను పొందడానికి మరియు క్యాష్‌ను తిరిగి నింపడానికి ముందుకు సాగుతుంది. మిగతా అన్ని అభ్యర్థనలు ఒకేసారి అన్నీ PostgreSQL‌ను హిట్ చేయకుండా, క్యాష్ అప్‌డేట్ అయ్యే వరకు వేచి ఉంటాయి. ఇది పునరావృత డేటాబేస్ రీడ్‌లను గణనీయంగా తగ్గిస్తుంది, క్యాస్‌కేడింగ్‌గా వచ్చే లోడ్ స్పైక్‌ల నుండి సిస్టమ్‌ను రక్షిస్తుంది.

సవాలు: ప్రైమరీ సర్వర్ ప్రతి రీడ్ రెప్లికాకు రైట్ అహెడ్ లాగ్ (WAL) డేటాను నిరంతరం ప్రసారం చేస్తుంది. రెప్లికాల సంఖ్య పెరిగేకొద్దీ, ప్రైమరీ సర్వర్ మరిన్ని ఇన్‌స్టాన్స్‌లకు WAL డేటాను పంపాల్సి ఉంటుంది. దీనివల్ల నెట్‌వర్క్ బ్యాండ్‌విడ్త్ మరియు CPU రెండింటిపై ఒత్తిడి పెరుగుతుంది. దీని వల్ల ఎక్కువ మరియు మరింత అస్థిరమైన రిప్లికా ల్యాగ్ ఏర్పడుతుంది, ఇది సిస్టమ్‌ను విశ్వసనీయంగా స్కేల్ చేయడం కష్టతరం చేస్తుంది.

పరిష్కారం: మేం జాప్యాన్ని తగ్గించడానికి అనేక భౌగోళిక ప్రాంతాల్లో దాదాపు 50 రీడ్ రెప్లికాలను నిర్వహిస్తున్నాం. అయితే, ప్రస్తుత ఆర్కిటెక్చర్‌తో, ప్రైమరీ ప్రతి రెప్లికాకు WALను స్ట్రీమ్ చేయాలి. ఇది ప్రస్తుతం చాలా పెద్ద ఇన్‌స్టాన్స్ రకాల మరియు అధిక నెట్‌వర్క్ బ్యాండ్‌విడ్త్‌తో బాగా స్కేల్ అవుతున్నప్పటికీ, మేం నిరవధికంగా రిప్లికాలను జోడించలేము, ఎందుకంటే చివరికి ప్రైమరీ ఓవర్‌లోడ్ అవుతుంది. దీనిని పరిష్కరించడానికి, మధ్యవర్తి రిప్లికాలు డౌన్‌స్ట్రీమ్ రిప్లికాలకు WAL‌ను రీలే చేసే కాస్కేడింగ్ రిప్లికేషన్⁠(కొత్త విండోలో తెరుచుకుంటుంది)పై మేం Azure PostgreSQL టీమ్‌తో సహకరిస్తున్నాము. ఈ విధానం ప్రైమరీపై అధిక భారం లేకుండా వందకు పైగా ప్రతులను స్కేల్ చేయడానికి మాకు అవకాశం ఇస్తుంది. అయితే, ఇది అదనపు ఆపరేషనల్ సంక్లిష్టతను కూడా తీసుకువస్తుంది, ముఖ్యంగా ఫెయిలోవర్ నిర్వహణలో. ఈ ఫీచర్ ఇంకా పరీక్ష దశలో ఉంది; ప్రొడక్షన్‌లోకి విడుదల చేయడానికి ముందు ఇది బలంగా ఉండి, సురక్షితంగా ఫెయిల్ ఓవర్ అవగలదని మేం నిర్ధారిస్తాము.

సవాలు: నిర్దిష్ట ఎండ్‌పాయింట్‌లలో అకస్మాత్తుగా ట్రాఫిక్ పెరగడం, ఖరీదైన క్వెరీల వెల్లువ లేదా రీట్రై స్టార్మ్ వంటివి CPU, I/Oమరియు కనెక్షన్ల వంటి కీలక వనరులను త్వరగా హరించివేస్తాయి. దీనివల్ల సేవా సామర్థ్యం విస్తృతంగా క్షీణిస్తుంది.

పరిష్కారం: డేటాబేస్ ఇన్‌స్టాన్స్‌లను ఆకస్మిక ట్రాఫిక్ పెరుగుదలలు ముంచెత్తకుండా, అలాగే వరుసగా విఫలమయ్యే పరిస్థితులను ప్రేరేపించకుండా ఉండేందుకు, మేం అప్లికేషన్, కనెక్షన్ పూలర్, ప్రాక్సీ, మరియు క్వెరీ—అనే అనేక లేయర్‌ల్లో రేట్-లిమిటింగ్‌ను అమలు చేశాం. రీట్రై స్టార్మ్‌లను ప్రేరేపించగల అతిగా చిన్న రీట్రై అంతరాలను నివారించడం కూడా చాలా ముఖ్యం. మేం ORM లేయర్‌ను రేటు పరిమితులను సపోర్ట్ చేయడానికి మెరుగుపరిచాము మరియు అవసరమైనప్పుడు, నిర్దిష్ట క్వెరీ డైజెస్ట్లను పూర్తిగా బ్లాక్ చేస్తాము. ఖరీదైన ప్రశ్నల అకస్మాత్తుగా పెరుగుదలల నుండి వేగంగా కోలుకోవడానికి ఈ లక్ష్యిత లోడ్ షెడింగ్ విధానం అనుమతిస్తుంది.

సవాలు: కాలమ్ టైప్‌ను మార్చడం వంటి చిన్న స్కీమా మార్పు కూడా పూర్తి టేబుల్‌ను తిరిగి రాయడానికి⁠(కొత్త విండోలో తెరుచుకుంటుంది) కారణమవుతుంది. అందువల్ల మేం స్కీమా మార్పులను జాగ్రత్తగా చేస్తాము—వాటిని తేలికపాటి ఆపరేషన్‌లకే పరిమితం చేస్తూ, మొత్తం టేబుళ్లను తిరిగి రాసే వాటిని నివారిస్తాం.

పరిష్కారం: పూర్తి టేబుల్ రీరైట్‌ను ప్రేరేపించని కొన్ని కాలమ్‌లను జోడించడం లేదా తొలగించడం వంటి తేలికపాటి స్కీమా మార్పులు మాత్రమే అనుమతించబడతాయి. స్కీమా మార్పులపై మేం కఠినమైన ఐదు-సెకన్ల టైమ్‌అవుట్‌ను అమలు చేస్తాము. ఇండెక్స్‌లను ఏకకాలంలో సృష్టించడం మరియు తొలగించడం అనుమతించబడుతుంది. స్కీమా మార్పులు ఇప్పటికే ఉన్న పట్టికలకే పరిమితం. కొత్త ఫీచర్‌కు అదనపు టేబుళ్లు అవసరమైతే, అవి PostgreSQL కంటే Azure CosmosDB వంటి ప్రత్యామ్నాయ షార్డెడ్ సిస్టమ్‌లలో ఉండాలి. పట్టిక ఫీల్డ్‌ను బ్యాక్‌ఫిల్ చేస్తున్నప్పుడు, రైట్ స్పైక్‌లను నివారించడానికి మేం కఠినమైన రేటు పరిమితులను అమలు చేస్తాము. ఈ ప్రక్రియకు కొన్నిసార్లు ఒక వారం సమయం పట్టినప్పటికీ, ఇది స్థిరత్వాన్ని నిర్ధారిస్తుంది మరియు ఉత్పత్తి ప్రభావాన్ని పరిహరిస్తుంది.

సరైన డిజైన్ మరియు ఆప్టిమైజేషన్‌లతో, Azure PostgreSQL అతిపెద్ద ప్రొడక్షన్ వర్క్‌లోడ్స్‌ను నిర్వహించగలిగేలా విస్తరించవచ్చు అని ఈ ప్రయత్నం నిరూపిస్తుంది. PostgreSQL రీడ్-హెవీ వర్క్‌లోడ్‌ల కోసం మిలియన్‌ల QPSలను నిర్వహిస్తుంది, ChatGPT మరియు API ప్లాట్‌ఫారం వంటి OpenAI అత్యంత ముఖ్యమైన ఉత్పత్తులకు శక్తినిస్తుంది. మేం దాదాపు 50 రీడ్ రిప్లికాలను జోడించాం, రెప్లికేషన్ ల్యాగ్‌ను దాదాపు సున్నా వద్ద ఉంచి, భౌగోళికంగా పంపిణీ చేసిన ప్రాంతాల్లో తక్కువ-లేటెన్సీ రీడ్‌లను నిర్వహించాం, భవిష్యత్ వృద్ధికి మద్దతు ఇవ్వడానికి తగిన సామర్థ్యాన్ని నిర్మించాం..

ఈ స్కేలింగ్ లేటెన్సీని తగ్గిస్తూ విశ్వసనీయతను మెరుగుపరుస్తూ పనిచేస్తుంది. మేం ప్రొడక్షన్‌లో స్థిరంగా తక్కువ డబుల్-డిజిట్ మిల్లీసెకండ్ల p99 క్లయింట్-సైడ్ లేటెన్సీ మరియు 99.999% అందుబాటును అందిస్తాం. గత 12 నెలలలో, మాకు కేవలం ఒక SEV-0 PostgreSQL ఇన్సిడెంట్ మాత్రమే జరిగింది (అది ChatGPT ImageGen యొక్క వైరల్ లాంచ్⁠(కొత్త విండోలో తెరుచుకుంటుంది) సమయంలో జరిగింది, రైట్ ట్రాఫిక్ అకస్మాత్తుగా 10 రెట్లు పెరిగింది, ఎందుకంటే ఒక వారం లోపల 100 మిలియన్‌లకు పైగా కొత్త యూజర్లు సైన్ అప్ చేసుకున్నారు.)

PostgreSQL మమ్మల్ని తీసుకువచ్చిన స్థాయి పట్ల మేం సంతృప్తిగా ఉన్నప్పటికీ, భవిష్యత్తు వృద్ధికి సరిపడా సామర్థ్యం ఉండేలా చూసుకోవడానికి మేం దాని పరిమితులను నిరంతరం విస్తరిస్తూనే ఉన్నాం. మేము ఇప్పటికే షార్డింగ్ చేయదగిన మరియు అధిక రైట్-లోడ్ కలిగిన వర్క్‌లోడ్‌లను CosmosDB. వంటి మా షార్డెడ్ సిస్టమ్స్‌కు విజయవంతంగా బదిలీ చేసాం. మిగిలి ఉన్న అధిక రైట్-లోడ్ వర్క్‌లోడ్‌లను షార్డింగ్ చేయడం మరింత సవాలుతో కూడుకున్న పని—PostgreSQL ప్రైమరీ సర్వర్‌పై రైట్ ఒత్తిడిని మరింత తగ్గించడానికి మేం వాటిని కూడా చురుకుగా బదిలీ చేస్తున్నాం. మేం Azureతో కూడా క్యాస్కేడింగ్ రిప్లికేషన్‌ను ప్రారంభించడానికి పని చేస్తున్నాం, తద్వారా మేం మరిన్ని రీడ్ రెప్లికాలను సురక్షితంగా గణనీయంగా పెంచగలుగుతాం.

భవిష్యత్తులో, మా మౌలిక అవసరాలు పెరుగుతున్నందున, ష్రెడ్డెడ్ PostgreSQL లేదా ప్రత్యామ్నాయ డిస్ట్రిబ్యూటెడ్ సిస్టమ్‌లను ఉపయోగించి మరింత విస్తరించడానికి అదనపు మార్గాలను అన్వేషించడానికి మేం కొనసాగుతాం.