ChatGPT bedient 800 Millionen Nutzer über eine einzige Postgres-Primärdatenbank
OpenAI skaliert PostgreSQL für den Betrieb von ChatGPT ohne Sharding, alle Schreibvorgänge laufen auf einem Primary auf. Ein Blick hinter die Kulissen der Infrastruktur.
Veröffentlicht am 27. Oktober • Zuerst erschienen auf mahmad.hashnode.dev
800 Millionen Menschen nutzen ChatGPT, und jeder Schreibvorgang landet weiterhin auf einem einzigen PostgreSQL-Primary. Ohne Sharding.
Als ich den Beitrag von OpenAI mit dem Titel Scaling PostgreSQL to power 800 million ChatGPT users von Bohan Zhang gelesen habe, konnte ich nicht aufhören, darüber nachzudenken. Deshalb habe ich daraus ein interaktives Diagramm gemacht: Roboter transportieren Abfragen zwischen den Maschinen, und man kann bewusst Dinge kaputtmachen, um zu sehen, was dann passiert.
Wie OpenAI PostgreSQL für 800 Millionen ChatGPT-Nutzer skaliert hat, animiert dargestellt: der erste Entwurf und der heutige Stand, jeweils im normalen Betrieb, bei einem Cache-Miss-Anstieg und beim Ausfall eines Primary.
Hier die Kurzfassung, wie das Ganze funktioniert.
Die Datenbanklast von ChatGPT ist innerhalb eines Jahres um mehr als das Zehnfache gewachsen. Ein einziger Primary verarbeitete jeden Schreibvorgang und viele Lesezugriffe, und Vorfälle folgten immer demselben Muster: Irgendetwas vorgelagertes trieb die Last in die Höhe (ein Cache-Ausfall, eine Welle teurer Joins, eine Schreibflut). Abfragen wurden langsamer, Anfragen liefen in Timeouts, und die Wiederholungsversuche erhöhten die Last zusätzlich.
Lesezugriffe gehen an fast 50 Read Replicas weltweit, während der Primary die Schreibvorgänge behält. Anfragen werden zudem in Replica-Gruppen mit hoher und niedriger Priorität aufgeteilt, sodass eine schwere Aufgabe mit niedriger Priorität die wichtigen Vorgänge nicht ausbremsen kann.
Schreiblastige Arbeitslasten, die sich sharden lassen, wurden zu Azure Cosmos DB verlagert. Und auf Postgres sind neue Tabellen nicht mehr erlaubt: Neue Workloads starten direkt auf den geshardeten Systemen.
Azure Postgres erlaubt 5.000 Verbindungen, und der Aufbau einer einzelnen Verbindung war langsam. PgBouncer hält Verbindungen offen und nutzt sie wiederverwendet, sodass sich die Verbindungszeit im Durchschnitt von 50 ms auf 5 ms reduzierte.
Läuft ein populärer Cache-Schlüssel ab, verfehlen Tausende Anfragen den Cache gleichzeitig und treffen alle auf die Datenbank. Mit Cache Locking befüllt eine einzige Anfrage den Schlüssel neu, während die anderen darauf warten.
Die Erkenntnis, die ich mitnehme: Sharding braucht man nicht immer. Ein einzelner Primary reicht sehr weit, wenn man alles, was irgendwie möglich ist, von ihm fernhält.
👉 mahmad.me/blocks/interactive/chatgpt-postgres
Alle Fakten stammen aus dem Beitrag von OpenAI. Die Live-Zahlen in der Simulation sind beispielhaft.
Automatisch übersetzt. Das Original auf Englisch ist unten aufklappbar.
Original (Englisch) anzeigen
Posted on Oct 27 • Originally published at mahmad.hashnode.dev
800 million people use ChatGPT, and every write still lands on one PostgreSQL primary. No sharding.
When I read OpenAI's post Scaling PostgreSQL to power 800 million ChatGPT users by Bohan Zhang, I couldn't stop thinking about it. So I turned it into an interactive diagram: robots carry queries between the machines, and you can break things to see what happens.
How OpenAI scaled PostgreSQL for 800 million ChatGPT users, animated: the first design and today’s, in normal traffic, a cache-miss spike and a primary failure.
Here's the short version of how it works.
ChatGPT's database load grew more than 10x in a year. One primary handled every write and many reads, and incidents kept following the same pattern: something upstream spiked the load (a cache failure, a burst of expensive joins, a write storm). Queries slowed down, requests timed out, and the retries added even more load.
Reads go to nearly 50 read replicas around the world, and the primary keeps the writes. Requests are also split into high- and low-priority replicas, so a heavy low-priority job can't slow down the important ones.
Write-heavy work that can be sharded moved to Azure Cosmos DB. And new tables aren't allowed on Postgres anymore: new workloads start on the sharded systems.
Azure Postgres allows 5,000 connections, and opening one was slow. PgBouncer keeps connections open and reuses them, so connecting dropped from 50 ms to 5 ms on average.
When a popular cache key expires, thousands of requests miss at once and all hit the database. With cache locking, one request refills the key and the others wait for it.
The lesson I took away: you don't always need to shard. A single primary goes very far if you keep everything you can off it.
👉 mahmad.me/blocks/interactive/chatgpt-postgres
All the facts come from OpenAI's post. The live numbers in the simulation are illustrative.