Sebbene i database vettoriali abbiano ancora molti casi d’uso validi, organizzazioni tra cui OpenAI si appoggiano a PostgreSQL per portare a termine le proprie attività.
Nell’a post sul blog giovedìOpenAI ha rivelato come utilizza il database PostgreSQL open supply.
OpenAI esegue ChatGPT e la sua piattaforma API per 800 milioni di utenti su un’unica istanza PostgreSQL primaria, non su un database distribuito, né su un cluster frammentato. Un server flessibile PostgreSQL di Azure gestisce tutte le scritture. Quasi 50 repliche di lettura distribuite in più regioni gestiscono le letture. Il sistema elabora milioni di question al secondo mantenendo una bassa latenza p99 di pochi millisecondi a due cifre e una disponibilità a cinque nove.
La configurazione sfida la saggezza convenzionale della scalabilità e offre agli architetti aziendali informazioni dettagliate su ciò che funziona effettivamente su larga scala.
TLa lezione qui non è copiare lo stack di OpenAI. Il punto è che le decisioni architetturali dovrebbero essere guidate dai modelli di carico di lavoro e dai vincoli operativi, non dal panico di scala o dalle scelte infrastrutturali alla moda. La configurazione PostgreSQL di OpenAI mostra fino a che punto i sistemi collaudati possono spingersi oltre quando i group ottimizzano deliberatamente invece di riprogettare prematuramente.
“Per anni, PostgreSQL è stato uno dei sistemi di dati più critici e nascosti che alimentano prodotti principali come ChatGPT e l’API di OpenAI”, ha scritto l’ingegnere di OpenAI Bohan Zhang in una divulgazione tecnica. “Nell’ultimo anno, il nostro carico PostgreSQL è cresciuto di oltre 10 volte e continua a crescere rapidamente.”
L’azienda ha raggiunto questo livello attraverso ottimizzazioni mirate, tra cui il pooling delle connessioni che ha ridotto i tempi di connessione da 50 millisecondi a 5 millisecondi e il blocco della cache per evitare problemi di “thundering herd” in cui i mancati risultati della cache innescano il sovraccarico del database.
Perché PostgreSQL è importante per le aziende
PostgreSQL gestisce i dati operativi per ChatGPT e la piattaforma API di OpenAI. Il carico di lavoro è fortemente orientato alla lettura, il che rende PostgreSQL una buona soluzione. Tuttavia, il controllo della concorrenza multiversione (MVCC) di PostgreSQL crea sfide in caso di carichi di scrittura pesanti.
Durante l’aggiornamento dei dati, PostgreSQL copia intere righe per creare nuove versioni, provocando l’amplificazione della scrittura e costringendo le question a scansionare più versioni per trovare i dati correnti.
Invece di combattere questa limitazione, OpenAI ha costruito la sua strategia attorno advert essa. Su scala di OpenAI, questi compromessi non sono teorici: determinano quali carichi di lavoro rimangono su PostgreSQL e quali devono essere spostati altrove.
Come OpenAI sta ottimizzando PostgreSQL
Su larga scala, la saggezza dei database convenzionali indica uno dei due percorsi: frammentare PostgreSQL su più istanze primarie in modo che le scritture possano essere distribuite, oppure migrare in un database SQL distribuito come CockroachDB o YugabyteDB progettato per gestire una scala su larga scala fin dall’inizio. La maggior parte delle organizzazioni avrebbe intrapreso uno di questi percorsi anni fa, ben prima di raggiungere 800 milioni di utenti.
Lo partizionamento o lo spostamento in un database SQL distribuito elimina il collo di bottiglia del singolo scrittore. Un database SQL distribuito gestisce questo coordinamento automaticamente, ma entrambi gli approcci introducono una notevole complessità: il codice dell’applicazione deve instradare le question allo shard corretto, le transazioni distribuite diventano più difficili da gestire e il sovraccarico operativo aumenta sostanzialmente.
Invece di partizionare PostgreSQL, OpenAI ha stabilito una strategia ibrida: nessuna nuova tabella in PostgreSQL. I nuovi carichi di lavoro vengono utilizzati per impostazione predefinita su sistemi partizionati come Azure Cosmos DB. I carichi di lavoro esistenti con uso intensivo di scrittura che possono essere partizionati orizzontalmente vengono migrati. Tutto il resto rimane in PostgreSQL con un’ottimizzazione aggressiva.
Questo approccio offre alle imprese un’alternativa pratica alla riarchitettura su vasta scala. Invece di dedicare anni a riscrivere centinaia di endpoint, i group possono identificare colli di bottiglia specifici e spostare solo quei carichi di lavoro su sistemi appositamente realizzati.
Perché questo è importante
L’esperienza di OpenAI nel dimensionamento di PostgreSQL rivela numerous pratiche che le aziende possono adottare indipendentemente dalla loro dimensione.
Costruisci difese operative su più livelli. L’approccio di OpenAI combina il blocco della cache per prevenire problemi di “thundering herd”, il pooling delle connessioni (che ha ridotto il tempo di connessione da 50 ms a 5 ms) e la limitazione della velocità a livello di applicazione, proxy e question. L’isolamento del carico di lavoro instrada il traffico a bassa e alta priorità verso istanze separate, garantendo che una nuova funzionalità scarsamente ottimizzata non possa degradare i servizi principali.
Esaminare e monitorare l’SQL generato da ORM in produzione. I framework ORM (Object-Relational Mapping) come Django, SQLAlchemy e Hibernate generano automaticamente question di database dal codice dell’applicazione, il che è utile per gli sviluppatori. Tuttavia, OpenAI ha rilevato una question generata da ORM che univa 12 tabelle che causava più incidenti di elevata gravità quando il traffico aumentava. La comodità di lasciare che i framework generino SQL crea rischi di ridimensionamento nascosti che emergono solo sotto il carico di produzione. Rendi la revisione di queste question una pratica customary.
Applicare una rigorosa disciplina operativa. OpenAI consente solo modifiche leggere dello schema: qualsiasi cosa che attivi una riscrittura completa della tabella è proibita. Le modifiche allo schema hanno un timeout di 5 secondi. Le question con esecuzione prolungata vengono terminate automaticamente per evitare di bloccare le operazioni di manutenzione del database. Quando riempiono i dati, applicano limiti di velocità così aggressivi che le operazioni possono richiedere più di una settimana.
I carichi di lavoro advert alta lettura con scritture burst possono essere eseguiti su PostgreSQL a primario singolo più a lungo di quanto comunemente ipotizzato. La decisione di effettuare lo sharding dovrebbe dipendere dai modelli di carico di lavoro piuttosto che dal conteggio degli utenti.
Questo approccio è particolarmente rilevante per le applicazioni AI, che spesso hanno carichi di lavoro fortemente orientati alla lettura con picchi di traffico imprevedibili. Queste caratteristiche sono in linea con il modello in cui PostgreSQL a primaria singola scala in modo efficace.
La lezione è semplice: identificare i colli di bottiglia effettivi, ottimizzare l’infrastruttura collaudata ove possibile e migrare in modo selettivo quando necessario. La riarchitettura totale non è sempre la risposta alle sfide di scalabilità.
