PostgreSQL á scálú chun freastal ar 800 milliún úsáideoir ChatGPT

Le blianta anuas, tá PostgreSQL ar cheann de na córais sonraí is criticiúla, taobh thiar de na radhairc, a chumhachtaíonn croítháirgí amhail ChatGPT agus API OpenAI. De réir mar a fhásann ár mbonn úsáideoirí go tapa, tá na héilimh ar ár mbunachair sonraí ag méadú go heaspónantúil freisin. Le bliain anuas, d’fhás ár n-ualach PostgreSQL níos mó ná 10 n-oiread, agus tá sé ag méadú go mear fós.

Nocht ár n-iarrachtaí ár mbonneagar táirgthe a chur chun cinn chun an fás seo a sheasamh léargas nua: is féidir PostgreSQL a scálú chun tacú go hiontaofa le hualaí oibre i bhfad níos mó atá trom ar léamh ná mar a cheap go leor roimhe seo. Chuir an córas (a chruthaigh foireann eolaithe in Ollscoil California, Berkeley ar dtús) ar ár gcumas ollthrácht dhomhanda a láimhseáil le haon ásc príomhúil amháin de fhreastalaí solúbtha Azure PostgreSQL⁠(osclaíonn i bhfuinneog nua) agus beagnach 50 macasamhail léite scaipthe ar fud ilréigiún ar fud an domhain. Seo scéal an chaoi ar scálaíomar PostgreSQL ag OpenAI chun tacú le milliúin ceist sa soicind do 800 milliún úsáideoir trí bharrfheabhsuithe diana agus innealtóireacht láidir; clúdóimid freisin na príomhrudaí a d’fhoghlaimíomar ar an mbealach.

Tar éis sheoladh ChatGPT, d’fhás an trácht ag ráta gan fasach. Chun tacú leis sin, chuireamar barrfheabhsuithe fairsinge i bhfeidhm go tapa ag an leibhéal feidhmchláir agus ag ciseal bhunachar sonraí PostgreSQL, rinneamar scálú suas trí mhéid an ásc a mhéadú, agus scálú amach trí níos mó macasamhlacha léite a chur leis. D’fhreastail an ailtireacht seo go maith orainn le fada an lá. Le feabhsuithe leanúnacha, leanann sí de dhóthain spáis fáis a sholáthar don todhchaí.

B’fhéidir gur iontas é go bhféadann ailtireacht aon-phríomhúil freastal ar éilimh scála OpenAI; áfach, níl sé simplí é seo a chur ag obair i gcleachtas. Chonaiceamar roinnt SEVanna de bharr ró-ualaigh Postgres, agus is minic a leanann siad an patrún céanna: bíonn borradh tobann san ualach bunachair sonraí mar thoradh ar fhadhb thuas an tsrutha, amhail teipeanna taisce forleathana de dheasca cliseadh sa chiseal taisce, borradh i gceangail ilbhealaigh chostasacha a sháithíonn LAP, nó stoirm scríbhneoireachta ó sheoladh gné nua. De réir mar a ardaíonn úsáid acmhainní, ardaíonn moill ceisteanna agus tosaíonn iarratais ag dul thar am. Ansin méadaíonn atriailí an t-ualach níos mó fós, rud a spreagann timthriall fí a bhféadfadh díghrádú a dhéanamh ar sheirbhísí iomlána ChatGPT agus API.

Cé go scálaíonn PostgreSQL go maith dár n-ualaí oibre atá trom ar léamh, tagann dúshláin romhainn fós le linn tréimhsí tráchta scríbhneoireachta ard. Tá sé seo den chuid is mó mar gheall ar chur i bhfeidhm rialú comhuaineachais illeagain (MVCC) PostgreSQL, rud a fhágann nach bhfuil sé chomh héifeachtúil d’ualaí oibre atá trom ar scríobh. Mar shampla, nuair a nuashonraíonn ceist tuple nó fiú réimse aonair, cóipeáiltear an ró iomlán chun leagan nua a chruthú. Faoi ualaí troma scríbhneoireachta, cruthaíonn sé sin aimpliú suntasach scríbhneoireachta. Méadaíonn sé aimpliú léite freisin, ós rud é go gcaithfidh ceisteanna il-leaganacha tuple (tupleanna marbha) a scanadh chun an ceann is déanaí a aisghabháil. Tugann MVCC dúshláin bhreise isteach cosúil le borradh táblaí agus innéacsanna, ualach cothabhála innéacsanna níos airde, agus mionchoigeartú casta autovacuum. (Is féidir tumadh domhain ar na saincheisteanna seo a fháil i mblag a scríobh mé le Prof. Andy Pavlo in Ollscoil Carnegie Mellon darb ainm An Chuid de PostgreSQL is Mó is Fuath Linn⁠(osclaíonn i bhfuinneog nua), a luaitear⁠(osclaíonn i bhfuinneog nua) ar leathanach Wikipedia PostgreSQL.)

Chun na teorainneacha seo a mhaolú agus brú scríbhneoireachta a laghdú, táimid tar éis, agus táimid fós ag, aistriú ualaí oibre inroinnte (is é sin, ualaí oibre is féidir a dheighilt go cothrománach), atá trom ar scríobh, chuig córais roinnte amhail Azure Cosmos DB, agus loighic feidhmchláir á barrfheabhsú againn chun scríbhinní gan ghá a íoslaghdú. Ní cheadaímid freisin táblaí nua a chur leis an imscaradh PostgreSQL reatha. De réir réamhshocraithe, téann ualaí oibre nua chuig na córais roinnte.

Fiú agus ár mbonneagar ag forbairt, d’fhan PostgreSQL gan roinnt, agus ásc príomhúil aonair ag freastal ar gach scríobh. Is é an phríomhchúis ná go mbeadh sé thar a bheith casta agus am-íditheach ualaí oibre feidhmchláir atá ann cheana a roinnt, rud a d’éileodh athruithe ar na céadta deireadhphointe feidhmchláir agus a d’fhéadfadh míonna nó fiú blianta a ghlacadh. Ós rud é go bhfuil ár n-ualaí oibre trom ar léamh den chuid is mó, agus gur chuir muid barrfheabhsuithe fairsinge i bhfeidhm, soláthraíonn an ailtireacht reatha neart acmhainne fós chun tacú le fás leanúnach tráchta. Cé nach bhfuilimid ag cur roinnt PostgreSQL as an áireamh amach anseo, ní tosaíocht ghearrthéarmach í mar gheall ar an dóthain spáis fáis atá againn don fhás reatha agus don fhás amach anseo.

Sna hailt seo a leanas, rachaimid go mion sna dúshláin a bhí romhainn agus sna barrfheabhsuithe fairsinge a chuireamar i bhfeidhm chun dul i ngleic leo agus bristí amach anseo a chosc, ag brú PostgreSQL chun a theorainneacha agus á scálú go milliúin ceist sa soicind (QPS).

Dúshlán: Gan ach scríbhneoir amháin ann, ní féidir le socrú aon-phríomhúil scríbhinní a scálú. Is féidir le borrthaí móra scríbhneoireachta an príomhásc a ró-ualú go tapa agus tionchar a imirt ar sheirbhísí cosúil le ChatGPT agus ár n-API.

Réiteach: Íoslaghdaímid an t-ualach ar an bpríomhásc oiread agus is féidir—idir léamha agus scríbhinní—chun a chinntiú go bhfuil dóthain acmhainne aige borrthaí scríbhneoireachta a láimhseáil. Déantar trácht léite a aistriú chuig macasamhlacha wherever possible. Mar sin féin, caithfidh roinnt ceisteanna léite fanacht ar an bpríomhásc toisc go bhfuil siad mar chuid d’idirbhearta scríbhneoireachta. Dóibh sin, dírímid ar a chinntiú go bhfuil siad éifeachtúil agus go seachnaítear ceisteanna mall. Maidir le trácht scríbhneoireachta, táimid tar éis ualaí oibre inroinnte, trom ar scríobh, a aistriú chuig córais roinnte amhail Azure CosmosDB. Tógann sé níos faide ualaí oibre atá níos deacra a roinnt ach a ghineann líon ard scríbhinní a aistriú, agus tá an próiseas sin fós ar siúl. Rinneamar ár bhfeidhmchláir a bharrfheabhsú go dian freisin chun an t-ualach scríbhneoireachta a laghdú; mar shampla, cheartaíomar fabhtanna feidhmchláir a d’fhág scríbhinní iomarcacha, agus thugamar isteach scríbhinní leisciúla, nuair ba chuí, chun borrthaí tráchta a smúdáil. Ina theannta sin, agus réimsí tábla á líonadh siar, cuirimid srianta ráta dochta i bhfeidhm chun brú scríbhneoireachta iomarcach a chosc.

Dúshlán: D’aithníomar roinnt ceisteanna costasacha i PostgreSQL. San am a chuaigh thart, d’ith borrthaí tobanna i líon na gceisteanna seo méideanna móra LAP, rud a chuir moill ar iarratais ChatGPT agus API araon.

Réiteach: Is féidir le cúpla ceist chostasach, amhail iad siúd a cheanglaíonn go leor táblaí le chéile, an tseirbhís iomlán a dhíghrádú go mór nó fiú a thabhairt anuas. Ní mór dúinn ceisteanna PostgreSQL a bharrfheabhsú go leanúnach chun a chinntiú go bhfuil siad éifeachtúil agus chun frithphatrúin choitianta Próiseála Idirbheart Ar Líne (OLTP) a sheachaint. Mar shampla, d’aithníomar uair amháin ceist thar a bheith costasach a cheangail 12 thábla, agus bhí borrthaí sa cheist seo freagrach as SEVanna tromchúiseacha roimhe seo. Ba cheart dúinn ceangail chasta iltábla a sheachaint nuair is féidir. Má tá ceangail riachtanach, d’fhoghlaimíomar machnamh a dhéanamh ar an gceist a bhriseadh síos agus loighic chasta ceangail a aistriú go ciseal an fheidhmchláir ina hionad. Gineann creataí Mapála Oibiachta-Caidrimh (ORManna) go leor de na ceisteanna fadhbacha seo, mar sin tá sé tábhachtach athbhreithniú cúramach a dhéanamh ar an SQL a tháirgeann siad agus a chinntiú go n-iompraíonn sé mar a bheifí ag súil leis. Is coitianta freisin ceisteanna díomhaoin fadrithimeacha a aimsiú i PostgreSQL. Tá sé riachtanach tréimhsí ama amhail idle_in_transaction_session_timeout a chumrú chun iad a chosc ó autovacuum a bhlocáil.

Dúshlán: Má théann macasamhail léite síos, is féidir trácht a stiúradh chuig macasamhlacha eile fós. Mar sin féin, má bhraitear ar scríbhneoir aonair, bíonn pointe aonair teipe ann—má théann sé síos, bíonn tionchar ar an tseirbhís iomlán.

Réiteach: Ní bhaineann formhór na n-iarratas criticiúil ach le ceisteanna léite. Chun an pointe aonair teipe sa phríomhásc a mhaolú, d’aistríomar na léamha sin ón scríbhneoir go macasamhlacha, rud a chinntíonn go bhféadfaidh na hiarratais sin leanúint de fhreastal fiú má théann an príomhásc síos. Cé go dteipfeadh ar oibríochtaí scríbhneoireachta fós, laghdaítear an tionchar; ní SEV0 é a thuilleadh toisc go bhfanann léamha ar fáil.

Chun teipeanna an phríomháis a mhaolú, ritheann muid an príomhásc i mód Ard-Infhaighteachta (HA) le fuireachas te, macasamhail atá sioncronaithe go leanúnach agus atá réidh i gcónaí le trácht a ghlacadh ar láimh. Má théann an príomhásc síos nó más gá é a thabhairt as líne le haghaidh cothabhála, is féidir linn an fuireachas a chur chun cinn go tapa chun aga neamhfhónaimh a íoslaghdú. Tá obair shuntasach déanta ag foireann Azure PostgreSQL chun a chinntiú go bhfanann na haistrithe teipe seo sábháilte agus iontaofa fiú faoi ualach an-ard. Chun teipeanna macasamhlacha léite a láimhseáil, imscarann muid roinnt macasamhlacha i ngach réigiún le dóthain spáis acmhainne, rud a chinntíonn nach mbíonn cliseadh macasamhlacha aonair ina chúis le briseadh amach réigiúnach.

Dúshlán: Is minic a thagann cásanna chun cinn ina n-ídíonn iarratais áirithe méid díréireach acmhainní ar áscanna PostgreSQL. Féadfaidh sé seo feidhmíocht ualaí oibre eile atá ag rith ar na háscanna céanna a ísliú. Mar shampla, is féidir le seoladh gné nua ceisteanna neamhéifeachtúla a thabhairt isteach a itheann LAP PostgreSQL go mór, rud a chuireann moill ar iarratais do ghnéithe criticiúla eile.

Solution: To mitigate the “noisy neighbor” problem, we isolate workloads onto dedicated instances to ensure that sudden spikes in resource-intensive requests don’t impact other traffic. Specifically, we split requests into low-priority and high-priority tiers and route them to separate instances. This way, even if a low-priority workload becomes resource-intensive, it won’t degrade the performance of high-priority requests. We apply the same strategy across different products and services as well, so that activity from one product does not affect the performance or reliability of another.

Challenge: Each instance has a maximum connection limit (5,000 in Azure PostgreSQL). It’s easy to run out of connections or accumulate too many idle ones. We’ve previously had incidents caused by connection storms that exhausted all available connections.

Solution: We deployed PgBouncer as a proxy layer to pool database connections. Running it in statement or transaction pooling mode allows us to efficiently reuse connections, greatly reducing the number of active client connections. This also cuts connection setup latency: in our benchmarks, the average connection time dropped from 50 milliseconds (ms) to 5 ms. Inter-region connections and requests can be expensive, so we co-locate the proxy, clients, and replicas in the same region to minimize network overhead and connection use time. Moreover, PgBouncer must be configured carefully. Settings like idle timeouts are critical to prevent connection exhaustion.

Challenge: A sudden spike in cache misses can trigger a surge of reads on the PostgreSQL database, saturating CPU and slowing user requests.

Solution: To reduce read pressure on PostgreSQL, we use a caching layer to serve most of the read traffic. However, when cache hit rates drop unexpectedly, the burst of cache misses can push a large volume of requests directly to PostgreSQL. This sudden increase in database reads consumes significant resources, slowing down the service. To prevent overload during cache-miss storms, we implement a cache locking (and leasing) mechanism so that only a single reader that misses on a particular key fetches the data from PostgreSQL. When multiple requests miss on the same cache key, only one request acquires the lock and proceeds to retrieve the data and repopulate the cache. All other requests wait for the cache to be updated rather than all hitting PostgreSQL at once. This significantly reduces redundant database reads and protects the system from cascading load spikes.

Challenge: The primary streams Write Ahead Log (WAL) data to every read replica. As the number of replicas increases, the primary must ship WAL to more instances, increasing pressure on both network bandwidth and CPU. This causes higher and more unstable replica lag, which makes the system harder to scale reliably.

Solution: We operate nearly 50 read replicas across multiple geographic regions to minimize latency. However, with the current architecture, the primary must stream WAL to every replica. Although it currently scales well with very large instance types and high-network bandwidth, we can’t keep adding replicas indefinitely without eventually overloading the primary. To address this, we’re collaborating with the Azure PostgreSQL team on cascading replication⁠(osclaíonn i bhfuinneog nua), where intermediate replicas relay WAL to downstream replicas. This approach allows us to scale to potentially over a hundred replicas without overwhelming the primary. However, it also introduces additional operational complexity, particularly around failover management. The feature is still in testing; we’ll ensure it’s robust and can fail over safely before rolling it out to production.

Challenge: A sudden traffic spike on specific endpoints, a surge of expensive queries, or a retry storm can quickly exhaust critical resources such as CPU, I/O, and connections, which causes widespread service degradation.

Solution: We implemented rate-limiting across multiple layers—application, connection pooler, proxy, and query—to prevent sudden traffic spikes from overwhelming database instances and triggering cascading failures. It’s also crucial to avoid overly short retry intervals, which can trigger retry storms. We also enhanced the ORM layer to support rate limiting and when necessary, fully block specific query digests. This targeted form of load shedding enables rapid recovery from sudden surges of expensive queries.

Challenge: Even a small schema change, such as altering a column type, can trigger a full table rewrite⁠(osclaíonn i bhfuinneog nua). We therefore apply schema changes cautiously—limiting them to lightweight operations and avoiding any that rewrite entire tables.

Solution: Only lightweight schema changes are permitted, such as adding or removing certain columns that do not trigger a full table rewrite. We enforce a strict 5-second timeout on schema changes. Creating and dropping indexes concurrently is allowed. Schema changes are restricted to existing tables. If a new feature requires additional tables, they must be in alternative sharded systems such as Azure CosmosDB rather than PostgreSQL. When backfilling a table field, we apply strict rate limits to prevent write spikes. Although this process can sometimes take over a week, it ensures stability and avoids any production impact.

This effort demonstrates that with the right design and optimizations, Azure PostgreSQL can be scaled to handle the largest production workloads. PostgreSQL handles millions of QPS for read-heavy workloads, powering OpenAI’s most critical products like ChatGPT and the API platform. We added nearly 50 read replicas, while keeping replication lag near zero, maintained low-latency reads across geo-distributed regions, and built sufficient capacity headroom to support future growth.

This scaling works while still minimizing latency and improving reliability. We consistently deliver low double-digit millisecond p99 client-side latency and five-nines availability in production. And over the past 12 months, we’ve had only one SEV-0 PostgreSQL incident (it occurred during the viral launch⁠(osclaíonn i bhfuinneog nua) of ChatGPT ImageGen, when write traffic suddenly surged by more than 10x as over 100 million new users signed up within a week.)

While we’re happy with how far PostgreSQL has taken us, we continue to push its limits to ensure we have sufficient runway for future growth. We’ve already migrated the shardable write-heavy workloads to our sharded systems like CosmosDB. The remaining write-heavy workloads are more challenging to shard—we’re actively migrating those as well to further offload writes from the PostgreSQL primary. We’re also working with Azure to enable cascading replication so we can safely scale to significantly more read replicas.

Looking ahead, we’ll continue to explore additional approaches to further scale, including sharded PostgreSQL or alternative distributed systems, as our infrastructure demands continue to grow.