La distribuzione di grandi volumi di dati si ottiene in due modi principali:
Partizionamento (partitioning): Divisione logica di una tabella all'interno di un unico database in segmenti (partition) basata su una certa chiave, solitamente una data o un intervallo di valori. Questo consente di eseguire rapidamente operazioni su singoli segmenti, velocizza le ricerche e facilita la manutenzione.
Sharding (sharding): Divisione fisica dei dati in più database/server secondo un determinato algoritmo — la tabella è effettivamente duplicata su diversi cluster, ognuno dei quali contiene il proprio segmento di dati.
Vantaggi del partitioning: non è necessario mantenere una logica di routing delle query separata, tutto avviene "in modo trasparente" per l'applicazione; svantaggi: limitato dalle capacità di un singolo DBMS.
Lo sharding offre scalabilità orizzontale (il limite dipende solo dal numero di server), ma richiede una complessa sincronizzazione, routing e gestione delle query "inter-shard".
-- Tabella di base partizionata CREATE TABLE orders ( id SERIAL PRIMARY KEY, customer_id INT, order_date DATE ) PARTITION BY RANGE (order_date); CREATE TABLE orders_2023 PARTITION OF orders FOR VALUES FROM ('2023-01-01') TO ('2024-01-01');
Domanda: È possibile spostare "al volo" righe tra partizioni senza bloccare la tabella principale?
Risposta: Nella maggior parte dei DBMS, spostare una riga tra partizioni è equivalente a un'eliminazione e reinserimento — tali operazioni possono bloccare righe e persino l'intera tabella, specialmente se sono coinvolti trigger o chiavi esterne. È necessario tenere conto di ciò durante le massicce "migrazioni" di dati tra segmenti.
-- ALTER TABLE ... MOVE PARTITION, di solito richiede particolare attenzione ai blocchi. Meglio farlo in orari a bassa affluenza.
Storia 1: In un progetto sono stati costruiti report analitici su tutte le partizioni contemporaneamente, senza considerare che una tabella partizionata con migliaia di segmenti creava piani di esecuzione delle query giganti. Di conseguenza — un improvviso aumento dei tempi di esecuzione e del carico sul server. Soluzione: aumentare il numero di partizioni corrispondenti ai veri assi di business della query e ottimizzare i piani di scansione.
Storia 2: Aggiungendo lo sharding non si è tenuta in considerazione la non unicità dell'identificatore tra gli shard. Si sono spesso verificati conflitti di chiavi durante l'aggregazione inter-shard.
Storia 3: L'archiviazione automatica delle partizioni "obsolete" le eliminava senza un successivo controllo delle relazioni esterne, portando alla perdita di collegamenti con altre tabelle e alla perdita di parte dei dati "attivi". Dopo ciò, l'intera logica di eliminazione delle partizioni è stata riscritta con test multipli di connettività.