PostgreSQL ed Elasticsearch su larga scala

Rendi di nuovo veloce il tuo database, e mantienilo veloce mentre i dati crescono.

In Turn.io ho partizionato tabelle PostgreSQL di produzione da oltre 1 TB e indici Elasticsearch live, mentre i dati dei messaggi crescevano di milioni di righe al giorno. Posso fare lo stesso per le tue query lente, le tue tabelle gonfie e i tuoi cluster di ricerca troppo costosi.

Parliamo del tuo progetto

postgres · messagesultima query –righe –dimensione –

Stessi dati, stessa query. Il partizionamento trasforma “scansiona un terabyte” in “scansiona un mese”, e la retention in un’operazione sui metadati.

elasticsearch · ciclo di vita degli indicitotale –tutto hot ––

primarioreplicada snapshot$/GB-mese indicativi, costi pieni

Il rollover mantiene gli shard di dimensione sana; ILM sposta i dati che invecchiano su hardware più economico, senza interventi manuali.

I dati di messaggistica crescono più di qualsiasi altra cosa

Ogni messaggio, aggiornamento di stato ed evento è una riga. In Turn.io i dati dei messaggi crescevano di milioni di righe al giorno, e le tabelle dietro inbox, analytics e ricerca sono lentamente diventate il collo di bottiglia. Il vacuum durava sempre di più, gli indici non stavano più in memoria e cancellare i dati vecchi bloccava tutto.

Per recuperare le performance ho partizionato tabelle PostgreSQL di produzione da oltre 1 TB, e ho fatto lo stesso con indici Elasticsearch live, con policy di lifecycle che spostano i dati più vecchi su cold storage.

Cosa faccio

Diagnosi. pg_stat_statements, EXPLAIN (ANALYZE, BUFFERS), statistiche su bloat e vacuum, utilizzo degli indici, contesa sui lock. Per Elasticsearch: dimensione degli shard, pressione sull’heap, slow log, mapping.

Sistemare le query che contano. Indici migliori (parziali, covering, multicolonna nell’ordine giusto), query riscritte, paginazione keyset, meno N+1 generati dall’ORM.

Partizionare le tabelle grandi. Scegliere una chiave di partizionamento che rispecchi le query, migrare senza downtime, creare automaticamente le partizioni future e trasformare la retention in un economico DETACH PARTITION ... CONCURRENTLY invece di un enorme DELETE.

Scalare le letture. Repliche di lettura, instradamento del traffico in sola lettura e una comprensione chiara del lag di replica.

Contenere i costi della ricerca. Rollover, tier hot/warm/cold, dimensionamento degli shard, force-merge e policy ILM che mantengono Elasticsearch veloce sui dati recenti ed economico su quelli vecchi.

Come lavoro

Prima misurare. Nessun tuning senza una baseline e un obiettivo.
Partire dai colpevoli principali. Nella maggior parte dei sistemi, una manciata di query causa gran parte dei problemi.
Pianificare le migrazioni come i deploy, a piccoli passi, con modifiche reversibili e una via di rollback per ciascuna.
Lasciare al team gli strumenti (dashboard, runbook, convenzioni) per mantenere il sistema veloce.

Servizi correlati

Sistemi real-time e distribuiti
Orchestrazione di agenti AI ed eval: RAG e ricerca vettoriale su Postgres.

Come possiamo collaborare

Check-up del database

Una settimana di analisi del tuo setup Postgres o Elasticsearch, con una lista di interventi in ordine di priorità e il relativo impatto atteso.

Partizionamento / migrazione

Pianificazione ed esecuzione di un passaggio senza downtime a tabelle partizionate o a una nuova strategia di indicizzazione, inclusi backfill e piani di rollback.

Supporto sulle performance a chiamata

Un pacchetto di ore per aiutarti quando una query o un cluster sta andando a fuoco.

Domande frequenti

Quando conviene partizionare una tabella PostgreSQL?

Quando una tabella è grande e scritta quasi solo in append (eventi, messaggi, log), la maggior parte delle query filtra per intervallo temporale o per tenant, e ti serve cancellare i dati vecchi a basso costo. Il partizionamento non è un’accelerazione generica: la chiave di partizionamento deve rispecchiare il modo in cui interroghi i dati.

Si può partizionare una tabella grande senza downtime?

Di solito sì. Gli approcci più comuni sono agganciare la tabella esistente come prima partizione dietro un vincolo CHECK, oppure scrivere in parallelo su entrambe le tabelle e fare il backfill a lotti. Gli indici si costruiscono in modo concorrente su ogni partizione e poi si agganciano. I dettagli dipendono dai tuoi vincoli e dal tuo traffico.

A cosa serve l’index lifecycle management di Elasticsearch?

ILM automatizza cosa succede agli indici man mano che invecchiano. Fa il rollover dell’indice di scrittura quando raggiunge una certa dimensione o età, sposta gli indici più vecchi su nodi warm e cold più economici, li riduce con shrink o force-merge e infine li cancella. È la leva principale sui costi della ricerca.

Lavori anche con pgvector?

Sì. Uso pgvector per RAG e ricerca semantica quando tenere i vettori accanto ai dati relazionali in Postgres è più semplice che gestire un database vettoriale separato.