Quante partizioni sono troppe?

Un numero eccessivo di partizioni piccole, ad esempio partizionare per ora invece che per giorno su una tabella con poco traffico, genera overhead di metadati e tante letture piccole invece di poche grandi, rallentando le query invece di velocizzarle. La regola pratica è scegliere la granularità più fine che produce comunque partizioni di almeno qualche centinaio di MB.

Posso cambiare lo schema di partitioning di una tabella già esistente?

Sì, ma di norma richiede di riscrivere l'intera tabella nel nuovo schema, non è un'operazione istantanea su una tabella con miliardi di righe. Va pianificata come una migrazione vera e propria, idealmente decisa in fase di progettazione iniziale piuttosto che corretta dopo.

Cosa sono partitioning e clustering?

Due tecniche per ridurre i dati letti da una query, e quindi il tempo e il costo, in un data warehouse cloud.

Il partitioning divide fisicamente una tabella in blocchi separati in base al valore di una colonna, tipicamente una data: ogni partizione contiene solo le righe di un giorno o di un mese, e una query che filtra su quella colonna legge solo le partizioni rilevanti invece di scansionare l'intera tabella (il cosiddetto partition pruning). Il clustering agisce un livello più in profondità: riordina fisicamente i dati in base a colonne aggiuntive, così anche i filtri su quelle colonne evitano di leggere blocchi non pertinenti. I due meccanismi non si presentano allo stesso modo su tutti i motori: BigQuery li espone come due scelte combinabili, Snowflake partiziona in automatico e lascia solo la clustering key, Databricks li ha unificati con il liquid clustering. Dove convivono sono complementari e non alternative: il partitioning si sceglie su una colonna filtrata di frequente e a cardinalità contenuta, di solito la data, il clustering sulle colonne secondarie che restringono la ricerca, come l'identificativo del cliente o la categoria di prodotto.

Leggi anche: Star schema · Modello dimensionale con una tabella dei fatti centrale collegata a tabelle di dimensione: lo schema sotto la maggior parte delle dashboard BI.

Perché contano per il costo, non solo per la velocità

Nei data warehouse cloud-native la quantità di dati letti si traduce in fattura, per vie diverse: BigQuery a consumo fattura direttamente i byte processati da ogni query, mentre Snowflake e Databricks fatturano il tempo di calcolo, che si accorcia quando il motore legge meno dati. Su una tabella con un layout fisico sbagliato il motore finisce per leggere molto più del necessario anche per una domanda semplice come "le vendite di ieri". Con uno schema di partitioning corretto la stessa query legge solo la partizione di ieri, una frazione minima del totale, e il clustering aggiunge un secondo filtro dentro quella frazione.

Un esempio enterprise

Prendi una tabella di transazioni con miliardi di righe, partizionata per data e clusterizzata per cliente. Una query che chiede "le vendite di un cliente nell'ultimo mese" legge solo i blocchi delle partizioni dell'ultimo mese, e dentro quei blocchi salta direttamente ai dati già ordinati per quel cliente, invece di scansionare miliardi di righe per poi scartarne quasi tutte. La stessa query, sulla stessa tabella priva di questo schema, avrebbe un costo di calcolo ordini di grandezza superiore a parità di risultato. Questo è il tipo di leva che si applica sopra qualunque modello logico, che la tabella segua uno star schema o viva in un data lakehouse: partitioning e clustering sono una questione di come i dati sono disposti fisicamente, non di come sono modellati o dove sono archiviati.

Perché conta per chi decide

Uno schema di partitioning sbagliato, o l'assenza totale di partitioning su una tabella grande e interrogata di frequente, può moltiplicare per 10 o 100 volte il costo delle query ricorrenti che alimentano dashboard e report quotidiani. È una decisione tecnica con un impatto economico diretto e continuativo, non un dettaglio da lasciare all'ultimo ingegnere che tocca la tabella. Va presa quando si progetta la tabella, non corretta dopo mesi di fatture cloud fuori controllo, ed è uno dei primi controlli che una revisione FinOps di una piattaforma dati dovrebbe fare.