L’internet, et plus récemment les métiers liés au cloud imposent de nouveaux enjeux à l’entreprise. Flexibilité, rapidité, sécurité et contrôle sont les mots-clés de l’IT moderne. Ce mouvement impose l’intégration de nouvelles technologies et l’utilisation d’applications de plus en plus agiles, notamment dans le domaine des SGBDs.
Les SGBDs sont particulièrement concernés, étant par nature le noyau central du système d’information.
Comment le SGBD a évolué pour répondre à ces nouvelles exigences ? Quels sont les enjeux liés aux bases de données modernes ? Comment protéger ces nouveaux outils applicatifs ?
Nous vous proposons, à travers cette série d’articles, de répondre à ces questions et de lever le voile sur les bases de données NoSQL.
Naissance d’un SGBD de type NoSQL ?
Depuis les années 2000, avec l’explosion des applications web et une croissance de leurs usages, les grands acteurs du Web ont dû faire face à de nouveaux enjeux concernant leurs infrastructures informatiques.
On remarquera l’explosion des volumes de données au cours des dix dernières années. Différentes études ont prévu une croissance exponentielle du volume de données entre 2015 et 2020. Face à cettcroissance, les solutions de base de données relationnelles Open Source ont montré rapidement leurs limites, en particulier dans le domaine du web.
Qui n’a pas été victime « d’une requête SQL de la mort » ?
Lorsque que des milliers d’utilisateurs requêtent une base de données pour accéder à une information, cette recherche peut être très couteuse en ressource et introduire des temps d’attentes aux utilisateurs.
Pour répondre principalement à ces besoins en performance mais aussi de manipulation massive de données, il est nécessaire de modifier son approche pour :
- Gagner en flexibilité et en souplesse concernant les architectures et infrastructures ;
- Gérer un important volume de données et une croissance exponentielle ;
- Garantir une montée en charge importante des infrastructures ;
- Stocker et restituer les données avec des temps de latence minimum.
Tout particulièrement pour les SGBDs, le modèle des bases de données relationnelles a été remis en cause par de fortes limitations en matière d’architecture distribuée.
Dans ce contexte, de nouveaux paradigmes ont fait évoluer les SGBDs. Cette réflexion, qui est basée sur une informatique distribuée, a donné naissance aux moteurs de base de données NoSQL (Not only SQL) Qui commencent à être présent dans les applications d’entreprise au travers des solutions suivantes :
- Apache Cassandra
- MongoDB
- Apache CouchDB
Nous pouvons aborder les moteurs NoSQL suivant deux axes :
- Les usages (besoins et type d’application) ;
- Le schéma de donnée utilisé par le moteur NoSQL
Note : Dans cet article, nous traiterons uniquement l’aspect infrastructure et la protection de ces nouvelles architectures.
Nous verrons principalement deux types d’usages pour les moteurs NoSQL :
- Pour des applications orientées performance : certains moteurs NoSQL ont pour but d’optimiser les performances de manipulation des données, soit en offrant un espace de cache en mémoire intermédiaire lors d’une requête d’un SGBDR (comme InnoDB memcached plugin pour MySQL), soit en tant que SGBD à part entière. Ces améliorations sont possibles grâce à différents mécanismes :
-
- Utilisation de la mémoire RAM pour stocker les données : la MemTable permet une exécution et manipulation des données directement depuis la mémoire RAM.
Moteur NoSQL Cassandra – Ecriture d’une nouvelle donnée
-
- Mais aussi avec une architecture distribuée des algorithmes permettant de traiter les requêtes sur les différents nœuds du cluster.
-
Bases de données Relationnelle vs NoSQL — Propriétés et théorèmes
Pour accompagner la transformation digitale mais aussi cette tendance du « big data », il a fallu étudier de nouvelles solutions pour contourner les limites des solutions SQL (principalement dues aux respects des contraintes ACID) dont les principales limites sont :
- Volumétrie
- Requête consommatrice de ressources et serveurs de plus en plus puissants
- Analyser des quantités de données en croissance (PetaOctets)
- Tolérance aux pannes (architecture rigide)
Un moteur NoSQL est conçu pour gagner en agilité et flexibilité pour ces nouveaux enjeux.
SQL : Les propriétés Atomicity, Consistency, Isolation, Durability ou contraintes ACID
Les bases de données relationnelles sont conçues pour fonctionner sur la base de transactions informatiques et doivent respecter les propriétés ACID afin de garantir les propriétés d’une transaction informatique ce qui limite l’approche d’informatique distribuée :
- Atomicity (Atomicité) : la propriété d’atomicité impose que l’ensemble des actions qui composent la transaction soit réalisé ; dans le cas contraire, la transaction est annulée et les données doivent être remises dans leur état initial avant la transaction. L’atomicité doit être respectée pour chaque situation, panne matérielle, ou toute interruption de service inattendue.
- Consistency (Cohérence) : Avant et après l’exécution d’une transaction, l’ensemble des données de la base doit passer dans un état valide à un autre état valide ou cohérent. Tout changement de donnée doit répondre aux règles définies de contraintes d’intégrité, rollback et autres .
- Isolation (Isolation) : Une transaction s’effectue de manière isolée, c’est-à-dire que toute transaction doit s’effectuer comme si elle était seule sur le système. Aucune dépendance entre les transactions.
- Durability (Durabilité) : Une transaction réussie est définitive ; c’est-à-dire que lorsqu’une transaction est confirmée, celle-ci est permanente même en cas de panne.
Contrairement à une base de données relationnelle et pour fonctionner avec une architecture distribuée, les moteurs NoSQL ne respectent pas les propriétés ci-dessus. Ils sont conçus pour s’appuyer sur le théorème CAP (Consistency, Availability, Partition tolerance). Ce théorème définit trois exigences de base qui sont nécessaires à une relation informatique (la cohérence, la disponibilité et la tolérance au partitionnement) lors de la conception d’applications dans une architecture distribuée.
Le théorème Consistency, Availability, Partition tolerance
- Consistency (Cohérence) : impose que la base de données doit être cohérente après chaque opération. Ce qui signifie que toutes les applications ou « clients » accèdent à la même donnée (valeur) à un instant T, et que ceux-ci sont cohérents entre eux.
- Availability (Disponibilité) : impose que le système soit toujours disponible, et que même en cas de panne le système ne connaisse aucun arrêt de service, ce qui garantit la continuité de service.
- Partition tolerance (Tolérance au partitionnement) : permet au système de continuer à fonctionner même en cas de problème de communication entre les serveurs (ex : problème de réseau). Les serveurs sont partitionnés en plusieurs groupes qui ne pourront pas communiquer entre eux.
Le premier constat est qu’un NoSQL ne pourra pas satisfaire toutes les exigences et ne pourra répondre qu’à 2 des 3 exigences ci-dessus. Par conséquent, les moteurs NoSQL répondent à un couple de combinaisons de C, A, P du théorème CAP.
Consistency & Availability, soit le couple AC : cluster de site unique, donc tous les nœuds sont toujours en contact. Lorsqu’une partition se produit, le système s’arrête (pas de gestion du split-brain).
Consistency & Partition Tolerance, soit le couple PC : Certaines données peuvent ne pas être accessibles, mais les données restent cohérentes. Moteur de type CP : Mongo DB, Hbase, Redis
Availability & Partition Tolerance, soit le couple AP : Le système est toujours disponible même sous partitionnement, mais certaines des données retournées peuvent être inexactes. Moteur de type CP : Cassandra, Couche DB, DynamoDB
Répartition des bases NoSQL selon théorème CAP
Note : ce théorème est toujours soumis à discussion et considéré comme « simpliste » car il impose d’abandonner la cohérence au profit de la disponibilité. Des travaux sont réalisés afin de le faire évoluer, notamment avec l’étude du théorème PACELC (Partition tolerance, Availability, Consistency, Availability Else Latency or Consistency) qui offre un arbitrage entre la latence et la cohérence.
Conclusion
Pour accompagner cette transformation digitale, les SGBDs ont dû évoluer afin de prendre en compte ces nouveaux traitements, assurer une haute disponibilité et une évolutivité simple du moteur NoSQL. Pour respecter ces besoins, un moteur SQL doit être du type AP (Disponibilité & Partition Tolerance), et donc impacter la cohérence des données. Concernant les moteurs NoSQL, nous pouvons faire la synthèse suivante :
- Principaux intérêts :
- L’évolutivité ou architecture scale-out : les lectures et les écritures sont réalisées depuis sur n’importe quel nœud du cluster.
- Informatique distribuée, gain en calcul : si l’on a besoin de plus de puissance, on rajoute simplement un serveur.
- Réduction des coûts grâce à une approche commodity hardware ;
- Flexibilité sur le schéma des données : pas de complexité du modèle de données.
- Inconvénients :
- Pas de standardisation ;
- La cohérence éventuelle des données n’est pas intuitive à programmer pour les développeurs des applications. Même si en réalité, la cohérence n’est pas totalement respectée, elle ne sera pour autant abandonnée.
- Personnaliser la protection et la sauvegarde des données
En conclusion de ce premier chapitre, les moteurs SQL traditionnels continueront à répondre à certaines problématiques applicatives et le passage au NoSQL n’est pas encore une obligation mais il se trouve être de plus en plus présent dans les applications. Pour cette raison, il est important de pouvoir protéger ces nouvelles technologies. Nous vous proposons, dans le second chapitre de notre série, de découvrir comment sécuriser une base de données Cassandra avec une sauvegarde Veeam.