# Performance di PostgreSQL ed Elasticsearch su larga scala (partizionamento, tuning, ILM)

> Consulente PostgreSQL ed Elasticsearch freelance: partizionamento PostgreSQL oltre 1 TB, tuning delle query, repliche, pgvector e index lifecycle management.

URL: https://fedme.dev/it/services/postgres-elasticsearch
Fornito da: Federico Meini (federico.meini@gmail.com)

## 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.

## Cosa ottieni

- Una diagnosi chiara del perché le cose sono lente, basata su piani EXPLAIN, pg_stat_statements e numeri reali.
- Strategie di partizionamento e retention per tabelle grandi e scritte quasi solo in append, introdotte senza downtime.
- Tuning di query e indici che risolve le query che fanno davvero male, non tutte.
- Cluster Elasticsearch con shard di dimensioni sensate, tier hot/warm/cold e policy di lifecycle degli indici che tengono sotto controllo i costi.

## 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

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

## Servizi correlati

- [Sistemi real-time e distribuiti](https://fedme.dev/it/services/realtime-systems)
- [Orchestrazione di agenti AI ed eval](https://fedme.dev/it/services/ai-agents-evals): 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.

## Stack

PostgreSQL, Declarative partitioning, pg_stat_statements, Read replicas, pgvector, Elasticsearch, Index lifecycle management, BigQuery, Ecto

## FAQ

### 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.

## Contatti

Email federico.meini@gmail.com · https://fedme.dev/it/contact