Les bases de données NoSQL clé-valeur et la base Cassandra open source

L’explosion des volumes et des formats de données, conjuguée avec des infrastructures mal adaptées à leur croissance exponentielle, poussent vers l’usage des bases de données NoSQL, plus évolutives et plus scalables, et qui reposent sur une infrastructure distribuée. Le paradigme clé-valeur est la base des bases NoSQL, et Cassandra est l’un des plus grands succès des bases de données NoSQL open source.

Les bases de données clé-valeur et la base open source Cassandra appartiennent à la famille des bases de données NoSQL (Not only SQL), conçues à l’origine pour répondre aux besoins de performance des géants du Web (Amazon, Google, Facebook). Elles ne répondent pas au modèle relationnel des bases de données classiques, dites SQL (Structured Query Language) en référence au modèle de langage de requête structurée. Contrairement au discours de certains observateurs, les bases NoSQL ne s’opposent pas aux bases SQL, elles sont une alternative à ces dernières qui n’offrent ni l’évolutivité ni la scalabilité nécessaires aux besoins de croissance exponentielle des volumétries de données, de puissance de traitement et des infrastructures qui les hébergent. Et elles viennent compléter les fonctionnalités des bases de données afin de les adapter à des usages contextuels.

La base de données relationnelle se présente sous la forme d’une table dans laquelle les informations sont classées en deux dimensions. Les colonnes sont les relations, et les lignes représentent les enregistrements. Pratiquement tous les systèmes relationnels utilisent le langage SQL pour interroger la base, un langage aujourd’hui standard qui permet de manipuler des opérations algébriques relationnelles comme l’intersection, la sélection ou la jointure. Cette simplicité a permis aux bases de données relationnelles SQL de devenir un (le) standard depuis les années 70. Cependant, aujourd’hui, le modèle relationnel se heurte à l’explosion massive des données, de leurs sources, de leurs formats (données qui peuvent être organisées en lignes et en colonnes, mais également texte, email, image, son, vidéo, etc.), et le besoin impératif du passage à l’échelle. Dans ce contexte explosif, mais désormais quotidien, les bases relationnelles si elles ont la capacité de traiter de gros volumes de données, elles enregistrent en revanche d’insupportables pertes de performance. À cela s’ajoute la multiplication des architectures distribuées, qui impose de disposer nativement de mécanismes d’identification des données, de partage, de gestion des charges et de réplication de données entre les nœuds. Les architectures transactionnelles, pour intelligentes et logiques qu’elles soient, montrent très vite leurs limites. C’est là qu’entrent en jeu les bases NoSQL.

Les bases de données NoSQL

Les bases de données NoSQL reposent sur 3 principes issus du théorème de CAP d’Eric Brewer, et spécialement adaptés aux données massivement partagées :

Consistance (Consistency) : tous les clients voient la même vue même lorsqu’il y a des mises à jour.

Haute disponibilité (Availability) : l’ensemble des clients peuvent trouver des données répliquées, même lorsqu’une avarie survient.

Tolérant à la partition (Partition-tolerance) : le système est tolérant au partitionnement.

Attention cependant, seuls deux des trois principes peuvent être respectés en même temps. Si l’on prend l’exemple d’Amazon, ce sont les deux derniers principes qui sont choisis, car les besoins en disponibilité et en partitionnement sont souvent plus importants que la consistance. C’est généralement le cas sur la plupart des déploiements de bases NoSQL.

Les bases NoSQL peuvent être réparties en quatre grandes familles :

– Clé–valeur

Les données sont représentées par un couple clé–valeur, la valeur pouvant être une simple chaîne de caractères ou un objet. Ce modèle n’a pas la complexité du paramétrage à l’origine des bases de données transactionnelles, il offre une forte évolutivité grâce à l’absence de structure ou de typage. En contrepartie, toute l’intelligence de ces bases repose sur les modèles d’interrogations, tandis que la communication se résume à quelques opérations simples, PUT, GET et DELETE. À l’exemple des bases Voldemort (Twitter) ou Riak.

– Orientée colonnes

Proche de la table de la base de données relationnelle, ce modèle dispose de la capacité de créer des colonnes dynamiquement. De nouveau, la simplicité est au rendez-vous lors de la création de la base, une colonne pouvant être créée au cours d’un enregistrement, sachant que le nombre de colonnes peut varier d’un enregistrement à un autre, évitant les colonnes de valeur NULL. Les bases orientées colonnes reposent sur le concept Big Table de Google. À l’exemple des bases HBAse ou Cassandra.

– Orientée documents

Reposant sur le paradigme clé–valeur, cette base remplace la valeur par un document de type JSON ou XML. Une seule clé permet ainsi de récupérer l’ensemble des informations de manière hiérarchique, ce qui imposerait plusieurs jointures dans le monde SQL. À l’exemple de la base CouchDB.

– Orientée graphe

Ce modèle de représentation des données se base sur la théorie des graphes, à savoir la notion de nœuds, de relations et de propriétés, ce qui facilite la représentation du monde réel, par exemple dans les réseaux sociaux. À l’exemple de la base Neo4J.

Parmi les avantages des bases de données NoSQL, que nous avons évoquées ci-dessus, figure celui d’un ticket d’entrée qui est peu élevé pour le développeur, puisque la plupart des solutions proposées sur le marché reposent sur un modèle open source. Leur utilisation peut cependant également se justifier dans des modèles d’usage qui ne sont pas impactés par les volumes ou la charge associée à leur traitement. En effet, les bases NoSQL présentent l’avantage d’être plus agiles, plus durables, et d’offrir une maintenance plus intelligente, ce qui offre lorsqu’elles sont maîtrisées une intéressante robustesse.

Les bases de données clé–valeur

La représentation en clé–valeur est la plus simple des bases NoSQL. Ces dernières associent des clés à des valeurs, donc des données, avec l’objectif est de renforcer les performances des applications reposant sur des jeux de données relativement simples. Cette structuration légère permet d’effectuer des recherches très rapidement. Si l’on veut simplifier, les bases de données clé-valeur peuvent se résumer à des tables de hashage, avec des entités généralement rapatriées à partir d’un identifiant et de tables partitionnées. Un hash choisit en fonction des clés et sélectionne l’instance en charge du stockage les partitions de stockage. Le consistant hashing, qui repose sur un algorithme, assure la répartition la plus égale possible des clés entre les partitions. Par exemple, avec un hachage uniforme, les données sont équitablement réparties sur des partitions.

image-article-base-cle-valeur-casandra

Clé/Valeur : à une clé est associée une valeur (bases clé-valeur) ou plusieurs champs d’un enregistrement, chacun étant une valeur (bases orientées colonnes)

Cette approche permet de résoudre le problème de montée en charge et en volume, mais sans tolérance aux pannes. Celle-ci vient de la pratique de la réplication, qui consiste à répliquer chacune des instances de partition. À la différence d’une table de hashage unique, les données sont redondées. Sur un système d’information de plus en plus dispersé, chaque machine se voit attribuer plusieurs partitions afin de permettre la mutualisation de la capacité de réplication. Profitant d’une infrastructure distribuée, l’information est répartie sur plusieurs serveurs et plusieurs partitions par serveur, avec un niveau de protection étendu grâce à la réplication.

2

Base de données en cluster, les sonnées sont réparties, répliquées et redondées entre plusieurs nœuds (serveurs)

Ajoutons à cela une fonction de quorum pour les opérations de lecture et écriture qui permet de définir un niveau de consistance pour offrir la capacité d’être plusieurs à exploiter une même donnée. Ce système définit un nombre de répliqua pour chaque partition de données avec un quorum en lecture qui impose un nombre de réponses à attendre lors d’une requête, et le même principe en écriture avec un quorum qui définit le nombre de confirmations d’écriture à attendre lors d’une requête. Enfin, l’historique des versions est tracé, ce qui permet de déléguer la résolution de conflits selon des critères définis par les utilisateurs.

La base de données Cassandra

La base de données Cassandra est un projet de base de données NoSQL open source, qui a été développé par Facebook avant d’être versé à la fondation Apache. Pour la petite histoire, son nom lui a été donné par les ingénieurs de Facebook qui participaient à son développement comme un clin d’œil pour le moins explicite à la base de données Oracle ! Cassandra est une base de données NoSQL orientée colonnes qui répond au théorème CAP. Elle s’inspire fortement pour son moteur de stockage de Big Table de Google, et de l’architecture Dynamo pour sa couche de distribution de données. Cassandra repose également sur la notion de cluster. Un cluster est composé de nœuds, chacun étant un serveur physique, qui pour gérer les données communiquent entre eux via un protocole peer-to-peer nommer Gossip.

3

L’écosystème des composants techniques d’une architecture Apache Cassandra

Dans un cluster Cassandra on trouve des tables, avec des lignes et des colonnes, et des keyspaces qui globalement en choisissant le type de partitionnement peuvent être assimilés aux bases. Dans les tables, les données sont disposées sur des lignes appelées partitions. Dans chaque partition on trouve des colonnes. Les colonnes sont créées dynamiquement au moment de l’insertion de nouvelles données. L’intersection d’une ligne et d’une colonne est assimilée à une clé–valeur. Notons au passage que le nombre de colonnes est limité à 2 milliards… C’est un point important, car l’un des avantages des bases de données NoSQL orientées colonnes est qu’à l’inverse des bases de données transactionnelles, elles ne créent pas à l’avance d’espace pour chaque colonne, et qu’il est possible d’insérer une colonne sans cellule. Le stockage des données s’en trouve optimisé puisque les cellules vides n’occupent pas d’espace physique. Dans un cluster, une table répartit les clés entre plusieurs nœuds, soit de manière ordonnée, chaque nœud prenant en charge une plage de clés de partitions triées par ordre croissant ; soit de manière aléatoire, chacune prenant en charge une plage de la clé de partition distribuée uniformément. Si une répartition ordonnée présente l’avantage de conserver l’ordre, en revanche les nœuds ne sont pas équilibrés, c’est pourquoi il est généralement conseillé d’utiliser un partitionnement aléatoire qui évite les goulots d’étranglement dans le cluster en apportant une meilleure répartition de la charge. Enfin, notons que dans le cadre d’une lecture ou d’une écriture, chaque modification d’une donnée est l’objet d’une clé de partition fournie par le client, qui passe par une fonction de hashage dont le résultat est appelé token. Avec le token et la fonction de hashage dispersé, les données et la charge bénéficient d’une garantie de distribution uniforme sur tous les nœuds.

En conclusion

C’est ainsi que les bases de bases de données NoSQL, qui comblent les manques flagrants des bases de données transactionnelles en apportant de nouveaux modèles, plus de flexibilité et de scalabilité, et l’accès à une infrastructure distribuée et en cluster. Dans cette mouvance de fond des bases de données de nouvelle génération, Cassandra, base de données NoSQL open source, rencontre un grand succès tout en offrant un puissant moteur d’optimisation du stockage qui peut servir de base pour des déploiements stratégiques, comme le Big Data et son exploitation par les analytiques, ou encore l’Internet des Objets.

Nos sources :

http://nosql-database.org/

http://cassandra.apache.org/

http://www.planetcassandra.org/what-is-nosql/

http://www.planetcassandra.org/what-is-apache-cassandra/

Partager :
Partager sur Twitter
Partager sur LinkedIn
Partager par email

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *