Gestion de données du modèle relationnel vers le modèle NoSQL

Gestion de données : du modèle relationnel vers le modèle NoSQL

L’historique des bases de données 

 Le premier système de base de données date des années 1960 : c’est le IBM IMS (International Business Machines Information Management System). Ce système a été développé dans le but de suivre les achats pour la mission Apollo pour son voyage vers la lune. Ce système était basé sur une modèle hiérarchique de données, entrainant aucune indépendance des données entre elles, mais aussi entrainant la duplication de ces données.[9] Dans les années 1970, le CODASYL (Conference on Data System Languages), un organisme américain de codification de bases de données, propose la standardisation de comment les programmes accèdent à une base de données, avec le langage COBOL (Common Business Oriented Language). Ce dernier étant basée sur un modèle en réseau. Les données sont reliées entre elles sous forme de réseau ou de graphe. Ce modèle a l’avantage d’être simple pour implémenter des données structurées en graphe, mais il est plus complexe que l’IMS, l’IMS étant un espace hiérarchique, le COBOL un hyperspace multidimensionnel. Le COBOL n’offre ni d’indépendance de données physiques ni de données logiques.Dans les années 1970 aussi, le modèle relationnel a été proposé par Ted Codd, car il a remarqué le temps pris par les programmeurs de IMS pour la maintenance de leur application, que ce soit au niveau physique ou au niveau logique. Ted Codd a proposé : le stockage de données en simple structure de données (en tables), l’accès de données avec un langage de haut niveau, et le stockage physique laissé à l’implémentation. Ainsi, l’indépendance logique et physique des données est atteinte. De plus, le modèle relationnel a l’avantage d’être flexible pour représenter presque tout. Les premières implémentations des bases de données relationnelles sont : System R de IBM Research, INGRES de University of California Berkelery, et Oracle de Larry Ellison. Le SQL est devenu le standard dans les années 1980.Le modèle orienté-objet fait apparition dans les années 1980 couplant les objets et les bases de données. Ce modèle n’a pas été répandu à cause de la complexité de ses requêtes et aussi à cause de l’absence d’interface standard comme le SQL. Ce dernier modèle a entrainé de nouveaux recherches dans les débuts des années 1990. Ces recherches consistaient à étendre le concept du modèle relationnel avec le concept des objets. Le projet de recherche le plus notable a été Postgres de University of California Berkelery, qui a entrainé deux bases de données Illustra et PostgresSQL. Plusieurs bases de données ont adopté ce modèle relationnel objet plus tard tel qu’Oracle Database et Microsoft SQL Server[3][18]. Pendant les années 1990, il n’y avait pas d’avancements majeurs. Mais c’était la période 2 du départ de deux références en bases de données open-source : MySQL et PostgreSQL. Avec l’augmentation croissante de l’internet et de leurs utilisateurs, les fonctionnalités des bases de données open-sources ne suffisent plus. Il est nécessaire d’échelonner les données pour pouvoir supporter un grand nombre d’utilisateurs connectés. Certains ont utilisé l’échellonnage vertical en utilisant de machines plus performantes, mais n’obtiennent pas de résultats satisfaisants. D’autres ont créé un middleware personnalisé en dispersant une base de données sur des groupements de nœuds, qui sont des machines moins chères. Lors des traitements de requête, le middleware transfert ou réécrit ces requêtes pour être traités dans un ou plusieurs nœuds du cluster. Ces derniers retransmettent les résultats au middleware qui envoie une simple réponse à l’application demandeur. Le modèle NoSQL est né de cette forte utilisation de l’internet, mais aussi de l’utilisation des systèmes parallèles et distribués dans la deuxième partie des années 2000. En effet, la quantité de données augmentait en même temps que le nombre d’utilisateurs, il était alors nécessaire de trouver une nouvelle stratégie à utiliser que ce soit dans la structure des données, mais aussi dans la structure du système en entier. En abandonnant la garantie des transactions et le modèle relationnel des traditionnelles bases de données, le modèle NoSQL opte plutˆot sur l’éventuelle consistance des données et d’autres modèles de données (clé/valeur, documents, orienté-colonne, graphes). Ce modèle a une haute disponibilité et un haut échellonnage. De plus il est usuellement open-source.

Le succès du modèle relationnel

Le modèle relationnel a déjà été utilisé en bases de données pendant plus de 30 années. La principale raison de ce succès est qu’il soit basé sur un modèle mathématique utilisant l’algèbre relationnel pour décrire les données et leurs relations. Cela entraine un modèle de données très spécifique et bien organisé. De plus, l’organisation logique des structures de données est indépendante du stockage physique de ces structures, ce qui facilite énormément le travail aux programmeurs. Des règles ont été développées dans la conception des bases de données pour éviter des anomalies concernant les données, comme des données inconsistantes.[4] Une de ces règles est l’utilisation des propriétés ACID permettant de gérer les transactions : [5] — Atomicité : ”Tout ou rien”, si une partie de la transaction est incomplète, toute la transaction est considérée comme échouée — Consistance : La base de données reste dans un état valide que ce soit avant ou après une transaction — Isolation : Les transactions sont indépendantes entre elles, c’est-à-dire que des transactions exécutées en même temps n’affectent pas l’exécution des autres — Durabilité : Une fois une transaction effectuée, elle reste stockée définitivement même si une coupure d’électricité ou des erreurs surviennent 

Les inconvénients du modèle relationnel

Avec l’avancement de l’internet, les développeurs ont de plus en plus besoin d’avoir : de plus grands volumes d’opérations d’écritures et de lectures, une faible latence en réponse et une grande accessibilité (availability) [15] Augmenter la performance est un problème que le modèle relationnel doit faire face : elle peut être améliorée en ajoutant des processeurs, de la mémoire vive ou de plus rapides 3 matériels de stockage. Ces derniers sont élevés en cout et ont une limite : la quantité de processeurs et de mémoire sur un seul serveur est limité. Les concepteurs en base de données proposent de concevoir à nouveau les schémas de données pour améliorer la performance au risque d’anomalies de données (c’est la dénormalisation) Utiliser plusieurs serveurs est aussi une autre option mais gérer un système de gestion de base de données relationnel sur plusieurs serveurs est une opération complexe. Comme par exemple pour transactions, le ”Tout ou Rien” doit être effectué sur tous les serveurs. Et plus le nombres de serveurs augmentent, plus la gestion des opérations de transaction devient couteuse. 

Le NoSQL

 L’émergence du NoSQL Face aux attentes dues à l’expansion de l’internet, des compagnies déploient des équipes dédiées au MySQL pour pousser et étendre les limites du modèle relationnel. Mais la plupart des compagnies n’ont pas le moyen pour utiliser de tels ressources. Pour ces derniers, le modèle relationnel n’est plus une option, et c’est le moment de considérer le modèle NoSQL. De plus, l’utilisation des systèmes parallèles et distribués devient de plus en plus appréciée. 

C’est quoi le NoSQL ? Le NoSQL est un terme utilisé pour tous les modèles de données et bases de données ne suivant pas les principes du modèle relationnel. Le modèle NoSQL est surtout lié à des données de grandes tailles, et aussi à un grand nombre d’utilisateurs.

Piliers du modèle NoSQL

1. Echellonnage C’est la faculté à s’adapter à la variation des flux selon la demande. S’il y a une augmentation du trafic sur un site, des serveurs peuvent être ajoutés dynamiquement pour prendre en main l’augmentation du flux. Et quand le trafic revient à la normal, les serveurs additionnels peuvent être éteints : c’est l’échellonnage horizontal. Contrairement au modèle relationnel qui l’échellonnage vertical, le modèle NoSQL adopte l’échellonnage horizontal. L’échellonnage horizontal nécessite un minimum d’administration tandis que l’échellonnage vertical est le fait d’augmenter la performance d’un unique serveur entrainant ainsi un temps d’inactivité 
2. Flexibilité Même si le modèle relationnel peut faire face à une grande variété de problèmes, mais à un autre aspect de flexibilité qu’il a des difficultés à gérer, surtout quand les données ne sont pas homogènes. Comme par exemple dans un e-commerce, les attributs des produits varient. Le modèle NoSQL n’ayant pas de structure de table fixe, ce modèle est plus flexible que le modèle relationnel. 
3. Accessibilité Les bases de données basées sur le modèle NoSQL sont conçus avec la possibilité d’utiliser de multiples serveurs à bas prix. Même si un serveur est hors service, un autre serveur du cluster peut gérer le flux. Quoique la performance n’est pas au maximum, l’application est toujours accessible. Pour le cas du modèle relationnel 4 qui fonctionne sur un seul serveur, l’application ne peut être accessible que grâce à un serveur de restauration. Mais ce serveur de restauration est seulement conçu pour se préparer à un éventuel arrêt du serveur et non pour procéder au traitement des flux.

Télécharger le document complet