Quelle différence y a-t-il entre les bases de données NoSQL et relationnelles ?
Azure Cosmos DB est caractérisé comme étant à la fois non relationnel et scalable horizontalement.
Scalabilité horizontale et verticale
Les bases de données relationnelles évoluent généralement en augmentant la taille de la machine virtuelle ou du calcul qui les héberge. Les bases de données NoSQL comme Azure Cosmos DB sont mises à l’échelle en ajoutant des serveurs et des nœuds supplémentaires. C’est ce qu’on appelle le scale-out. Ces nœuds sont également appelés « partitions physiques » dans Cosmos DB. Les données stockées sur ces partitions physiques doivent être organisées pour être efficacement accessibles par la suite.
Les données sont routées vers différentes partitions physiques en utilisant la valeur d’une propriété obligatoire sur chaque document. Cette propriété est appelée clé de partition d’un conteneur et doit être spécifiée lors de la création du conteneur. Le transfert de la clé de partition quand les données sont écrites ou lues à partir d’un conteneur garantit l’efficacité des opérations en dirigeant simplement la demande vers la partition sur laquelle elle est stockée.
La nécessité d’une clé de partition peut paraître une contrainte, mais elle présente d’immenses avantages. En règle générale, une base de données relationnelle ne croît pas au-delà de 100 To. Une base de données NoSQL peut croître jusqu’à une taille illimitée et peut le faire sans aucun impact sur les temps de réponse quand elle accède aux données à partir d’une partition unique quelconque.
En outre, à mesure que des partitions sont ajoutées, la quantité de calculs augmente aussi et la quantité de traitement prise en charge par la base de données croît simultanément. Cela signifie qu’il peut également prendre en charge davantage d’utilisateurs simultanés. Par ailleurs, il n’y a pas d’impact sur les performances.
Bases de données non relationnelles et relationnelles
La deuxième caractéristique définissant une base de données NoSQL est l’absence de clés étrangères, de contraintes et de relations appliquées d’aucune sorte entre les données. Comme les données d’une base de données NoSQL sont stockées sur des serveurs physiques différents, l’application de contraintes ou de relations, ou le placement de verrous sur les données peuvent engendrer des performances négatives ou imprévisibles.
Toutefois, le fait de ne pas avoir de relations appliquées ne signifie pas que vous ne pouvez pas gérer les entités qui ont des relations dans une base de données NoSQL. Cela signifie simplement que vous devez le faire différemment.
Pourquoi ces types de bases de données sont-ils si différents ?
Comprendre l’évolution de l’aspect économique du calcul depuis la première introduction des bases de données relationnelles permet d’expliquer pourquoi ces deux types de bases de données sont si différents.
En 1970, quand les bases de données relationnelles furent inventées, le coût du stockage et de la mémoire était élevé par rapport à celui du calcul. Le but de la normalisation d’un modèle de base de données était de réduire les données en double et, par conséquent, le coût au sein d’une base de données. Le moteur de base de données appliquait des verrous pour imposer une sémantique ACID (atomicité, cohérence, isolation, durabilité) stricte et exécuter des opérations sur l’ensemble des données requises. Les verrous appliqués sur les données garantissaient leur cohérence, mais en faisant des compromis sur la concurrence, la latence et la disponibilité.
Aujourd’hui, le coût du stockage et de la mémoire est relativement bon marché par rapport à celui du calcul. Ainsi, pour être rentable, nous n’avons plus besoin d’optimiser l’efficacité du stockage. Avec des charges de travail nécessitant des niveaux accrus de concurrence et de disponibilité ainsi que des latences moins élevées, un nouveau type de base de données optimisé pour ces exigences était nécessaire, donnant naissance aux bases de données NoSQL.
Les mêmes raisons sont à l’origine de l’un des objectifs de la modélisation des données pour une base de données NoSQL, à savoir d’assurer que la lecture et l’écriture des données soient économes en calculs. En partie parce que les opérateurs relationnels comme les jointures entre documents n’existent pas dans les bases de données NoSQL, les données doivent être stockées telles que l’application les utilise afin d’être les plus efficaces possible. Souvent, les données doivent être dénormalisées, dupliquées ou stockées à l’encontre de nombreuses règles de normalisation relationnelle utilisées pour la modélisation des données relationnelles.
Pouvez-vous utiliser NoSQL pour des charges de travail relationnelles ?
À ce stade, vous vous demandez peut-être si les bases de données NoSQL peuvent être utilisées pour des charges de travail relationnelles. Et la réponse est oui ! Les bases de données NoSQL peuvent absolument être utilisées pour des charges de travail où il existe des relations entre les différentes entités.
Les bases de données NoSQL sont souvent utilisées quand une base de données relationnelle ne parvient pas à répondre aux besoins de performances, d’échelle ou de disponibilité souhaités de l’application.
Les techniques de conception utilisées pour une base de données NoSQL diffèrent de celles de la modélisation de données pour une base de données relationnelle. Ces techniques ne sont pas non plus intuitives pour une personne avec une expérience en conception de bases de données relationnelles. Les bonnes pratiques que vous apprenez pour générer des bases de données relationnelles sont souvent des anti-modèles pour la conception d’une base de données NoSQL.
Pour le reste de ce module et dans le module de modélisation avancée, nous vous guiderons dans l’utilisation des techniques de modélisation des données, pour que vous obteniez une base de données NoSQL à hautes performances.