Pourquoi les modèles de données évolutives définissent la croissance de l'ingénierie

Les entreprises d'ingénierie qui partagent avec succès un trait commun : leur infrastructure de données augmente avec elles plutôt que contre elles. Un modèle de données qui fonctionne pour une équipe de cinquante ingénieurs et quelques téraoctets de données se fissurera sous la pression de centaines d'ingénieurs, de millions d'appareils et de charges de travail à l'échelle des pétaoctets. La différence entre un modèle qui s'équilibre et un modèle qui échoue revient souvent aux décisions architecturales prises bien avant que la croissance ne se produise.

Les modèles de données évolutives ne sont pas seulement à propos de gérer plus de lignes dans une base de données. Ils sont à propos de maintenir des temps de réponse rapides de requête, de préserver l'intégrité des données sous des écritures simultanées, et de permettre aux équipes d'ajouter de nouvelles fonctionnalités sans réécrire la couche de stockage entière.

Pour construire un modèle qui s'évalue, il faut comprendre les compromis entre cohérence, disponibilité et performance, savoir quand normaliser et dénormaliser, quand durcir et quand reproduire, et choisir la bonne technologie de base de données pour chaque charge de travail, et ce, en fonction des principes, stratégies et pratiques réelles qui permettent aux équipes d'ingénierie de concevoir des modèles de données qui évoluent avec leur entreprise.

Le noyau du modèle de données Scalabilité

La scalabilité des modèles de données est la capacité de gérer le volume de données, la charge d'utilisateurs et la complexité des requêtes sans dégradation des performances ou nécessitant une refonte complète. Il ne s'agit pas d'une propriété unique mais d'une combinaison de choix architecturaux qui permettent à un système d'étendre gracieusement.

Il y a deux dimensions principales de l'évolutivité:

  • Écaillage horizontal (écaillage):[ Ajout de serveurs ou de nœuds pour distribuer la charge. Les bases de données NoSQL comme Cassandra et MongoDB sont conçues pour cela, mais les bases de données relationnelles peuvent également être mises à l'échelle horizontale avec des techniques comme le sharding.
  • Écaillage vertical (scalage) :[ Augmenter la capacité d'un serveur unique en ajoutant plus de processeur, de RAM ou de stockage plus rapide. Ceci est plus simple mais a des limites difficiles et peut devenir prohibitif des coûts à l'échelle.

La plupart des entreprises d'ingénierie ont besoin des deux. La clé est de concevoir le modèle de données afin qu'il puisse profiter de l'échelle horizontale au besoin, tout en étant efficace sur un seul noeud pour le développement et les essais.

Un modèle de données évolutives tient également compte des schémas d'accès. Un modèle optimisé pour les charges de travail transactionnelles (OLTP) sera très différent d'un modèle optimisé pour les requêtes analytiques (OLAP).

Reconnaître quand votre modèle doit être à l'échelle

Les signes d'avertissement sont invariables une fois que vous savez ce qu'il faut chercher. Interrogez les temps qui dérivent vers le haut à mesure que les données grandissent, les impasses qui apparaissent seulement sous la charge de pointe, et l'incapacité d'ajouter de nouvelles fonctionnalités sans toucher le schéma de base sont tous des indicateurs que le modèle actuel atteint ses limites.

Principes fondamentaux de la modélisation évolutive des données

Les principes suivants constituent la base de tout modèle de données évolutive, qui ne sont pas des règles rigides, mais des lignes directrices qui doivent être équilibrées les unes par rapport aux autres en fonction des exigences spécifiques du système.

Normalisation effectuée de manière délibérée

La normalisation réduit la redondance des données et améliore la cohérence de l'écriture en organisant les données dans des tableaux séparés reliés par des clés étrangères. Pour les systèmes transactionnels où l'intégrité des données est primordiale, un modèle normalisé est souvent le bon point de départ.

L'approche pragmatique consiste à normaliser la troisième forme normale au cours de la conception initiale, puis à dénormaliser sélectivement les voies de lecture critiques pour les performances. Par exemple, dans un système de gestion des actifs d'ingénierie, les données de base des actifs pourraient être normalisées, mais une vue dénormalisée des métadonnées des actifs et des lectures récentes pourrait être maintenue pour les tableaux de bord qui nécessitent des temps de réponse de sous-seconde.

Dénormalisation en tant qu'outil de performance

La dénormalisation introduit une redondance pour éliminer les jointures et accélérer les lectures. Il s'agit d'une stratégie valable pour les systèmes de lecture lourde, comme les plateformes de contenu, les tableaux de bord en temps réel et les moteurs de rapport.

Les bases de données modernes offrent des outils pour gérer ce compromis. Les vues matérialisées dans PostgreSQLTM, les pipelines de saisie des données de changement et les stratégies d'invalidation du cache au niveau de l'application aident à maintenir la cohérence des données dénormalisées.

Répartition pour la gestion

Le cloisonnement divise les grandes tables en pièces plus petites et plus gérables basées sur une clé de partition. Cela améliore les performances de la requête en permettant à la base de données de numériser uniquement les partitions pertinentes, et simplifie les opérations de maintenance comme l'archivage des anciennes données.

La partition en fonction du temps est courante pour les données de séries chronologiques, comme les relevés de capteurs ou les journaux. La partition de la liste fonctionne bien pour les données qui peuvent être regroupées par catégorie, comme la région ou la ligne de produits. La partition de la gamme par une clé numérique est utile pour distribuer uniformément les données entre les partitions.

Une stratégie de partitionnement bien conçue réduit le besoin de scanners de table complète et maintient les index petits. Elle permet également l'archivage de fenêtres roulantes : largage des anciennes partitions au lieu d'effectuer des opérations de suppression coûteuses.

Indexation avec l'objectif

Les index sont la façon la plus directe d'accélérer la récupération des données, mais ils viennent avec un coût. Chaque index ajoute des frais généraux pour écrire des opérations et consomme le stockage. L'objectif est d'indexer pour les motifs de requête réels, pas pour chaque colonne qui pourrait être filtrée.

Pour les entreprises d'ingénierie, les index composites sur des colonnes fréquemment filtrées fournissent souvent les plus grands gains de performance. Les index partiels qui ne couvrent qu'un sous-ensemble de lignes sont utiles pour les modèles de requêtes qui ciblent des statuts spécifiques ou des plages de dates.

Des outils de surveillance de base de données comme PostgreSQL'états pg stat ou Le log de requêtes lent[ de MySQL aident à identifier quels index sont utilisés et qui sont de poids mort.

Choisir la bonne technologie de base de données

Aucune base de données ne excelle à tout. Les bases de données relationnelles comme PostgreSQL et MySQL offrent une forte cohérence, des transactions ACID, et de riches capacités de requête.

Les entreprises d'ingénierie devraient évaluer leur charge de travail avant de s'engager dans une base de données. Si les données ont des relations complexes et nécessitent une intégrité transactionnelle, une base de données relationnelle est le choix évident. Si les données sont largement non structurées et doivent être écrites et lues à grande échelle, une base de données NoSQL peut être plus appropriée.

Stratégies de conception pour une croissance durable

Les principes ne suffisent pas à eux seuls. Ils doivent être intégrés dans un processus de conception qui anticipe la croissance et qui tient compte du changement. Les stratégies suivantes aident les équipes d'ingénierie à construire des modèles de données qui demeurent robustes à l'échelle de l'organisation.

Conception du schéma modulaire

Un schéma monolithique où chaque table renvoie toutes les autres tables devient impossible à changer sans casser quelque chose. La conception modulaire organise les données en contextes délimités, chacun avec son propre schéma qui communique avec d'autres contextes à travers des interfaces bien définies.

Cette approche, empruntée à la conception par domaine, permet aux équipes d'évoluer indépendamment de leur part du système. Un service d'inventaire, par exemple, peut modifier son schéma interne sans affecter le service de facturation, tant que le contrat API entre elles reste stable.

API-Premier accès aux données

L'accès direct à la base de données des applications est une recette pour les systèmes serrés de couplage et de fragilité. Les entreprises d'ingénierie devraient exposer les données au moyen d'API qui retirent le modèle sous-jacent.

GraphQL, REST et gRPC fournissent tous des mécanismes pour l'accès contrôlé aux données. La couche API peut implémenter la mise en cache, la limitation des taux et l'optimisation des requêtes qui seraient difficiles à appliquer au niveau de la base de données. Elle permet également la persistance des polyglottes : différentes bases de données derrière l'API peuvent servir différents cas d'utilisation tout en présentant une interface unifiée aux applications.

Archivage des données et gestion du cycle de vie

Toutes les données ne doivent pas être immédiatement accessibles. Les données historiques qui sont rarement posées peuvent être transférées vers un stockage moins coûteux, réduisant la charge sur la base de données primaire et réduisant les coûts. Une politique bien définie du cycle de vie des données spécifie quand les données sont archivées, comment elles sont stockées et comment elles peuvent être récupérées au besoin.

De nombreuses entreprises d'ingénierie utilisent une approche de stockage à niveaux : les données chaudes sur les SSD rapides, les données chaudes sur le stockage lent et les données froides dans le stockage d'objets comme S3. Des outils comme le partitionnement de table de PostgreSQL peuvent archiver les anciennes partitions pour le stockage d'objets automatiquement.

Surveillance continue et optimisation des requêtes

L'évolutivité n'est pas une réalisation ponctuelle, mais une attention constante à la performance des requêtes, à l'utilisation des index et à la santé des bases de données.

Les sessions régulières d'examen des requêtes, où l'équipe examine les requêtes les plus lentes et décide des optimisations, devraient faire partie du cycle de développement. Les optimisations communes comprennent l'ajout d'index manquants, la réécriture de jointures inefficaces, et le transfert de calculs coûteux aux processus de lot.

Version et migrations des schémas

Au fur et à mesure que l'entreprise grandit, le modèle de données devra changer. L'ajout de nouveaux champs, la dépréciation des anciens et les tables de restructuration font tous partie de l'évolution normale.

Des outils comme Flyway, Liquibase et Alambic appliquent des migrations dans un ordre contrôlé, avec des capacités de retour. La clé est de concevoir des migrations qui sont compatibles avec l'arrière : les nouvelles colonnes devraient avoir des valeurs par défaut, les anciennes colonnes devraient être dépréciées progressivement, et les verrous de base de données devraient être minimisés lors des changements de schéma.

Étude de cas : Élargir le système de données sur la fabrication de 10 à 1 000 sites

Une entreprise de fabrication qui produit des équipements d'automatisation industrielle a commencé avec un site d'usine unique et une base de données PostgreSQL pour le suivi des stocks, des calendriers de production et des mesures de qualité. Le modèle de données initial a été entièrement normalisé, avec des tableaux pour les pièces, les assemblages, les ordres de travail et les résultats des tests.

À mesure que la société s'étendait à 50 sites, la base de données s'est accrue pour atteindre des milliards de lignes. Des questions qui, une fois terminées en millisecondes, ont commencé à se terminer.

Sur deux ans, l'équipe d'ingénierie a refacturé le modèle de données en faisant de l'évolutivité le principal objectif :

  • Partitionnement:[ Les plus grandes tables ont été partitionnées par ID et date du site. Les données de chaque site vivaient dans sa propre partition, rendant les requêtes pour un site unique rapide et permettant l'archivage indépendant de partitions entières.
  • Optimisation de l'index: Les index ont été reconstruits en fonction des motifs de requête réels. Les index composites sur (site id, timestamp) ont remplacé les index monocolonnes sur chaque champ. Les index partiels pour les ordres de travail actifs ont éliminé les scans d'index inutiles.
  • Lire les répliques:[ Les requêtes de déclaration ont été acheminées pour lire les répliques, isolant les charges de travail transactionnelles des analyses, ce qui a éliminé le problème de la discorde.
  • Cachage de calque:[ Les données fréquemment consultées, comme les catalogues de pièces et les configurations de machines, ont été mises en cache dans Redis, réduisant ainsi la charge de la base de données de 40%.
  • Archivage des données:[ Les commandes de travail de plus de 90 jours ont été transférées dans une base de données d'archives distincte sur le stockage moins cher, ce qui a permis de garder la base de données principale plus souple.

Au moment où l'entreprise a atteint 1 000 sites, le système a géré plus de 50 millions d'écritures par jour avec des temps de requête de p95 inférieurs à 50 millisecondes. La base de données originale était passée de 500 Go à plus de 50 To, mais le modèle de données refacturé a maintenu les performances prévisibles.

Ce cas illustre la leçon clé : l'évolutivité n'est pas une caractéristique que vous ajoutez plus tard. C'est un ensemble de décisions de conception qui doivent être revisitées au fur et à mesure que le système grandit. L'entreprise manufacturière a réussi parce qu'elle a traité le modèle de données comme un système vivant qui a besoin d'investissements continus.

Pièges courants et comment les éviter

Les entreprises d'ingénierie qui tentent de s'adapter sans modèle de données solide tombent souvent dans des pièges prévisibles.

Surnormalisation dans les systèmes de lecture lourde

La normalisation est un réflexe pour les développeurs formés à la conception relationnelle de bases de données. Mais pour les systèmes où lit beaucoup plus de nombre écrit, la normalisation excessive crée des requêtes de jointure-lourdes qui deviennent plus lentes à mesure que les données grandissent. La correction est de profiler les modèles de lecture réels et dénormaliser sélectivement. Une colonne dénormalisée ou une table de synthèse précompue peut éliminer la nécessité d'une jointure multi-table dans le chemin critique.

Ignorer les modèles d'accès aux données

Un modèle de données conçu sans comprendre comment les données seront accessibles est presque garanti pour avoir besoin de retravailler. Les équipes d'ingénierie doivent cartographier les chemins de requête primaires avant de concevoir le schéma. Quelles requêtes ont besoin de temps de réponse de sous-seconde? Qui sont analytiques et peuvent tolérer la latence? Quelles colonnes sont toujours accessibles ensemble? Les réponses doivent conduire les décisions sur les index, partitionnement et dénormalisation.

Traiter la base de données comme une boîte noire

Les bases de données modernes sont des systèmes complexes avec de nombreux boutons de configuration. En supposant que les paramètres par défaut sont optimaux pour une entreprise d'ingénierie en croissance est une erreur. Tailles de piscine de connexion, tailles de piscine tampon, paramètres de log d'écriture en tête, et le comportement de vide ou de compactage affectent tous les performances à l'échelle.

Planification du cycle de vie des données

Les entreprises d'ingénierie devraient définir des politiques de conservation pour chaque type de données, automatiser le processus d'archivage et tester le chemin de restauration régulièrement. Une purge de données non planifiée sous pression est une recette pour la perte de données.

Conclusion : La scalabilité en tant que pratique continue

La construction d'un modèle de données évolutives n'est pas un exercice de conception unique. C'est une pratique continue de mesure, d'optimisation et d'adaptation à mesure que l'entreprise grandit. Les principes et les stratégies décrits dans cet article fournissent une base : normaliser délibérément, dénormaliser avec le but, partition pour la gérable, index pour les requêtes réelles, et choisir la bonne base de données pour chaque charge de travail.

Les entreprises d'ingénierie qui investissent dans cette pratique gagnent un avantage concurrentiel durable. Leurs systèmes restent rapides et fiables, même lorsque le volume de données multiplie. Leurs équipes peuvent expédier de nouvelles fonctionnalités sans reconstruire la couche de stockage. Et leur infrastructure de données devient un moteur de croissance plutôt qu'une contrainte sur elle.

Le moment de commencer à penser à l'évolutivité est avant que vous en ayez besoin. Que vous conçoyiez le premier schéma pour un nouveau produit ou que vous refactoriez un système déjà sous tension, les principes sont les mêmes. Appliquer de façon cohérente, surveiller les résultats et itérer. Le modèle de données qui s'échelle est celui qui reçoit une attention continue.