Traiter la donnée : performance, coût & scalabilité

Format, compression, partitionnement, coût de stockage, traitements efficaces et montée en charge : les réflexes pour des données rapides, pas chères et qui passent à l'échelle.

Pourquoi le format colonne change tout

Une requête analytique ne lit souvent que 2 ou 3 colonnes. En stockage ligne, le moteur doit tout parcourir ; en colonne, il ne lit que ce dont il a besoin — moins d'E/S, moins de coût.

Lire « SUM(montant) » : stockage ligne vs stockage colonne
STOCKAGE LIGNE STOCKAGE COLONNE id nom montant id nom montant id nom montant Le moteur lit TOUT (id + nom + montant) → beaucoup d'E/S, données inutiles lues id 1 2 3 nom montant 120 340 90 Le moteur ne lit QUE la colonne montant → 3× moins de données lues, requête moins chère + Partitionner par date = ne lire qu'un dossier /ventes/annee=2024/mois=06/… → WHERE mois=6 ignore tout le reste (partition pruning) Colonne + partition + SELECT ciblé : sur du serverless, la facture peut être divisée par 100.

Le format colonne (Parquet/ORC) ne lit que les colonnes utiles et compresse mieux ; le partitionnement laisse le moteur ignorer les données hors filtre. Ensemble, ils réduisent d'un facteur énorme le volume lu — donc le temps ET le coût.

🎯 Testez-vous

Six questions pour vérifier que les réflexes perf / coût / scalabilité sont bien acquis.

Retour aux outils développeurs