La répartition de grands volumes de données est réalisée de deux manières principales :
Partitionnement (partitioning) : Division logique d'une table au sein d'une base de données en segments (partition) selon une clé, généralement une date ou une plage de valeurs. Cela permet d'effectuer rapidement des opérations sur des parties individuelles, accélérant la recherche et facilitant l'entretien.
Sharding (sharding) : Division physique des données sur plusieurs bases de données/serveurs selon un certain algorithme — la table est en fait dupliquée sur différents clusters, chacun contenant son propre segment de données.
Les avantages du partitionnement — pas besoin de maintenir une logique métier séparée pour le routage des requêtes, tout se passe de manière "transparente" pour l'application ; les inconvénients — limité par les capacités d'un seul SGBD.
Le sharding permet un scaling horizontal (la limite dépend uniquement du nombre de serveurs), mais nécessite une synchronisation complexe, un routage et un traitement des requêtes "inter-shards".
-- Table partitionnée de base 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');
Question : Peut-on déplacer des lignes entre des partitions "à la volée" sans bloquer la table principale ?
Réponse : Dans la plupart des SGBD, le déplacement d'une ligne entre des partitions équivaut à une suppression et une insertion — de telles opérations peuvent bloquer les lignes et même la table elle-même, surtout si des triggers ou des clés étrangères sont impliqués. Cela doit être pris en compte lors de "transferts" massifs de données entre les partitions.
-- ALTER TABLE ... MOVE PARTITION nécessite généralement une attention particulière aux blocages. Il est préférable de le faire à des moments peu chargés.
Histoire 1 : Dans un projet, des rapports d'analyse ont été construits sur toutes les partitions à la fois, sans tenir compte du fait qu'une table partitionnée avec des milliers de sections créait d'énormes plans d'exécution des requêtes. En conséquence — une augmentation soudaine du temps d'exécution et de la charge sur le serveur. Solution : augmenter le nombre de partitions correspondant aux véritables axes métier de la requête et optimiser les plans de scan.
Histoire 2 : Lors de l'ajout du sharding, l'unicité de l'identifiant entre les shards n'a pas été prise en compte. Des conflits de clés surviennent souvent lors de l'agrégation inter-sharding.
Histoire 3 : L'archivage automatique des partitions "périmées" les supprimait sans vérifier à nouveau les relations externes, ce qui a conduit à la perte de lien avec d'autres tables et à la perte de certaines données "vivantes". Après cela, toute la logique de suppression des partitions a été réécrite avec des multi-tests de cohérence.