Sebbene i database vettoriali abbiano ancora molti casi d’uso validi, organizzazioni come OpenAI si affidano a PostgreSQL per portare a termine il proprio lavoro.
Uno post sul blog giovedìOpenAI ha spiegato come utilizza il database PostgreSQL open source.
OpenAI esegue ChatGPT e la sua piattaforma API su un’unica istanza PostgreSQL primaria per 800 milioni di utenti; non un database distribuito o un cluster frammentato. Un singolo server elastico PostgreSQL di Azure gestisce tutte le scritture. Circa 50 repliche di lettura distribuite su più regioni gestiscono le letture. Il sistema elabora milioni di query al secondo mantenendo una bassa latenza p99 di pochi millisecondi a due cifre e una disponibilità a cinque nove.
La configurazione sfida le nozioni tradizionali di scalabilità e offre agli architetti aziendali informazioni dettagliate su ciò che funziona realmente su larga scala.
TLa lezione qui non è copiare lo stack di OpenAI. Ciò significa che le decisioni architetturali dovrebbero essere guidate da modelli di carico di lavoro e vincoli operativi, non da panico di scala o preferenze infrastrutturali di tendenza. L’implementazione di PostgreSQL di OpenAI mostra quanto i sistemi collaudati possano espandersi quando i team ottimizzano deliberatamente anziché riprogettare prematuramente.
"Per anni PostgreSQL è stato uno dei sistemi di dati più critici e riservati, supportando prodotti principali come ChatGPT e l’API di OpenAI." L’ingegnere di OpenAI Bohan Zhang ha scritto in una dichiarazione tecnica. "Il nostro carico PostgreSQL è aumentato di oltre 10 volte nell’ultimo anno e continua a crescere rapidamente."
L’azienda ha raggiunto questo obiettivo attraverso ottimizzazioni mirate, tra cui il pooling delle connessioni, che riduce il tempo di connessione da 50 millisecondi a 5 millisecondi, e il blocco della cache per prevenire problemi di “sciame di rumore”, in cui la cache innesca il sovraccarico del database.
Perché PostgreSQL è importante per le aziende?
PostgreSQL gestisce i dati operativi per ChatGPT e la piattaforma API di OpenAI. Il fatto che il carico di lavoro sia prevalentemente orientato alla lettura rende PostgreSQL molto adatto. 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, il che provoca l’espansione della scrittura e fa sì che le query eseguano la scansione di più versioni per trovare i dati esistenti.
Invece di combattere questa limitazione, OpenAI ha costruito la sua strategia attorno ad essa. Sulla scala di OpenAI, questi compromessi non sono teorici; Determina quali carichi di lavoro rimarranno in PostgreSQL e quali dovranno essere spostati altrove.
In che modo OpenAI ottimizza PostgreSQL?
Su larga scala, la saggezza dei database convenzionali indica uno dei due percorsi: partizionare PostgreSQL su più istanze primarie in modo che le scritture possano essere distribuite, o passare a un database SQL distribuito progettato fin dall’inizio per gestire su larga scala, come CockroachDB o YugabyteDB. Molte organizzazioni hanno scelto uno di questi percorsi anni fa, molto prima di raggiungere gli 800 milioni di utenti.
Lo partizionamento o la migrazione a 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 indirizzare le query allo shard corretto, le transazioni distribuite diventano difficili da gestire e il sovraccarico operativo aumenta in modo significativo.
Invece di fare a pezzi PostgreSQL, OpenAI ha creato una strategia ibrida: nessuna nuova tabella in PostgreSQL. I nuovi carichi di lavoro vengono usati per impostazione predefinita nei 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 aziende un’alternativa pratica alla riarchitettura all’ingrosso. Invece di dedicare anni a riscrivere centinaia di endpoint, i team possono identificare colli di bottiglia specifici e spostare solo quei carichi di lavoro su sistemi appositamente realizzati.
Perché è importante?
L’esperienza di OpenAI nel dimensionamento di PostgreSQL rivela una varietà di pratiche che le aziende possono adottare indipendentemente dalle loro dimensioni.
Costruisci difese operative su più livelli. L’approccio di OpenAI combina il blocco della cache "gregge tuonante" problemi, pooling delle connessioni (tempo di connessione ridotto da 50 ms a 5 ms) e limitazione della velocità a livello di applicazione, proxy e query. L’isolamento del carico di lavoro indirizza il traffico a bassa e alta priorità verso istanze separate, garantendo che una nuova funzionalità scarsamente ottimizzata non abbia un impatto negativo sui servizi principali.
Ispeziona e monitora l’SQL generato da ORM in produzione. I framework ORM (Object Relational Mapping) come Django, SQLAlchemy e Hibernate creano automaticamente query di database dal codice dell’applicazione, il che è utile per gli sviluppatori. Tuttavia, OpenAI ha rilevato una query generata da ORM che univa 12 tabelle causando più eventi ad alta gravità quando il traffico aumentava. La comodità di lasciare che i framework generino SQL crea rischi di ridimensionamento nascosti che appaiono solo sotto il carico di produzione. Rendi la revisione di queste query una pratica standard.
Applicare una rigorosa disciplina operativa. OpenAI consente solo lievi modifiche allo schema; Tutto ciò che attiva una riscrittura completa della tabella è proibito. Le modifiche allo schema hanno un timeout di 5 secondi. Le query con esecuzione prolungata vengono terminate automaticamente per evitare di interferire con le operazioni di manutenzione del database. Applicano i limiti di velocità in modo così rigoroso durante la compilazione dei dati che le operazioni possono richiedere più di una settimana.
I carichi di lavoro ad alta intensità di lettura con scritture burst possono essere eseguiti più a lungo su un PostgreSQL a primario singolo di quanto generalmente si presuppone. La decisione sullo sharding dovrebbe basarsi sui modelli di carico di lavoro piuttosto che sul numero di utenti.
Questo approccio è particolarmente vero per le applicazioni IA che hanno carichi di lavoro prevalentemente incentrati sulla lettura con picchi di traffico imprevedibili. Queste funzionalità sono coerenti con il modello in cui PostgreSQL a primaria singola scala in modo efficace.
La lezione è semplice: identificare i colli di bottiglia reali, ottimizzare l’infrastruttura collaudata ove possibile e migrare in modo selettivo quando necessario. La riprogettazione totale non è sempre la risposta alle sfide di scalabilità.
