< Tous les articles

Juin 19, 2020

Datastax / Cassandra

Datastax/Cassandra : Bonnes pratiques de modélisation et cas d’usages dans le e-business

Datastax Server Entreprise (DSE) est une base de données distribuée dite “no-SQL” (pas seulement SQL) s’appuyant sur la base open source Cassandra qui fait partie à l’origine des projets de la fondation Apache. Datastax est le principal contributeur de ce projet Apache Cassandra à hauteur de 80% (source Github).

Dans cet article nous allons expliquer pas à pas les caractéristiques d’une telle base de données et comment celle-ci est utilisé par les entreprises.

Base de données distribuée

Le terme de base de données distribuée fait référence au traitement de la donnée sur plusieurs “nœuds” dans un cluster de machines, la donnée volumineuse est découpée en “partition” entre les différents nœuds de la base, allégeant ainsi l’allocation de ressources pour le traitement des données (écriture / lecture).

Chaque nœud est unique et contient une partition des données. Cela permet une grande disponibilité des données mais surtout une haute tolérance aux pannes. A chaque instant un nœud est élu coordinateur pour gérer les requêtes clientes. (Voir fig. 1)

Figure 1 -Cluster Cassandra en “peer to peer”

Afin d’avoir une communication entre chaque nœud, l’architecture de Cassandra s’appuie sur un protocole de communication dit “peer to peer”. Le protocole va permettre la propagation de l’information sur tous les nœuds d’un même Data Center.

Cette architecture permet :

L’écriture et la lecture des données avec des temps de latence réduits,
Une augmentation de la charge de traitement des données entre les différents nœuds,
Une réduction drastique du risque de panne (si l’un des nœuds tombe un autre prend le relais),
La gestion d’un flux important de données par l’ajout de nouveaux nœuds.

Le cluster doit assurer au maximum le théorème dit de CAP (Voir Fig.2) :

Cohérence des données. (Consistency)
Disponibilité (Availability)
Résistance au partionnement. (Partition Tolerance)

Cassandra à fait le choix de se positionner sur la disponibilité et la résistance au partitionnement. En clair, celle-ci va prioriser la disponibilité des données sur leur cohérence via son architecture distribuée en nœuds. Néanmoins des solutions existent pour satisfaire ces trois points critiques. Tout d’abord Cassandra sauvegarde les données sur des partitions réparties sur des nœuds distincts du cluster. Le mécanisme dit de réplication respecte la règle du quorum de nœuds qui doit toujours être un nombre impair de copies : le nombre minimum de réplications est de 3 et constitue une valeur par défaut.

Mais ce mécanisme de réplication ne garantit pas que les données soient cohérentes entre chaque nœud du cluster. Si les données critiques (par exemple : coordonnées bancaire d’un client), il convient d’obtenir une cohérence irréprochable.

Pour ce faire les requêtes des clients sur la base peuvent fixer un niveau de consistance. Ce niveau de consistance indique combien de partitions vont être interrogées afin de vérifier que la donnée est bien mise à jour dans plusieurs partitions réparties sur des nœuds distincts du cluster. Ce système est utilisé en lecture et écriture pour les requêtes en base.

Figure 2 – théorème CAP

Relationnel ou non-relationnel ?

Cassandra utilise un format de base de données dit non relationnel entre les tables par opposition aux bases de données relationnelles (Oracle, MySQL, SQL Server…) qui mettent en œuvres des relations “1 à n” ou “n à n” entre les données des différentes tables (formes normales).

L’architecture NoSQL de la base de données Cassandra est basée sur la technologie “BigTable paper” inventée par Google. Le choix d’une orientation en colonne des données (par tuples de valeurs) permet de compresser les données et d’accélérer le traitement des opérations (MIN, MAX, SUM…) et la recherche sur des valeurs de clés communes.

Figure 3 – représentation du modèle de données

Le modèle de données des tables Cassandra se décompose ainsi :

La colonne : plus petite unité de la base, elle est composée d’un nom, d’une valeur et d’un timestamp (indication de la dernière mise à jour).
La Ligne : se compose d’une clé d’identification et d’une multitude de colonnes.
La famille de colonnes : Regroupement de ligne.
Le Keyspace : regroupe un ensemble de famille de colonne.

Figure 4 – BDD orientée colonne

Cette vitesse de traitement est indispensable dans le contexte lié au Big Data, de gros volume de données peuvent être envoyés de façon continue en base il s’agit d’être efficient en lecture et en écriture.

De plus les colonnes ne supportent pas les doublons de données (les valeurs nulles ne sont pas stockées), cela permet d’avoir des données compactes et fiables.

Pour effectuer des requêtes sur ses tables Cassandra utilise son propre langage : le CQL ou “Cassandra Query Language”.

Le langage Cassandra Query Language (CQL)

Le CQL est un langage proche du SQL standard, cependant quelques différences existent. Faisons un tour d’ensemble sur ces spécificités.

Tout d’abord la base peut s’organiser de façon à accueillir les données structurées classiques, mais aussi les données semi-structurés (format JSON et XML).

Il est obligatoire de saisir une clé primaire sur une des valeurs pour permettre au cluster de retrouver les données qui sont dispersées sur le data center. La clé est générée par Cassandra utilisant “Murmur3”, une fonction de traitement.

On peut se représenter une table comme ceci :

La clé primaire est appelée “Partition Key”, elle est unique et fait référence à une seule partition sur un seul nœud du cluster. Ainsi, Cassandra n’aura aucun mal à récupérer les données relatives à un élément de données.

Cassandra prend également en charge les “Clustering Key” qui contrôlent la façon dont les enregistrements de données sont regroupés et organisés au sein de chaque partition. Les enregistrements dans Cassandra sont stockés sous forme de listes de paires clé-valeur où le nom de la colonne est la clé.

Les bonnes pratiques

Prenons un exemple afin d’illustrer les grands principes de modélisation des données dans Cassandra. Nous créons une table nommée “magasin”, celle-ci va contenir le numéro du magasin, sa localisation, son directeur, une description du magasin et ainsi que ses stocks.

Le numéro d’identification du magasin va nous permettre de retrouver sa trace sur notre cluster en vérifier ce numéro avec ceux présents sur les nœuds.

Data modeling

Les trois principes fondamentaux de conception d’un bon modèle de données sont les suivants.

1. Répartir les données de manière équilibrée dans le cluster

En choisissant la bonne “Partition Key”, les données devront être réparties de façon équilibrée sur l’ensemble des nœuds du cluster afin que chaque nœud puisse récupérer une part égale des données. La distribution de ces données se fait via la “partition key” qui est une clé de partition générée par la base. Le hachage des données se fait pour chaque partition et va décider dans quel nœud la donnée va être stockée.

Figure 5 – Partitionnement et hachage

2) Minimiser le nombre de partitions à lire pour chaque requête type

Les partitions sont un ensemble de lignes qui partagent une même “Partition Key”. Il nous faut créer un modèle qui réduit au maximum le nombre d’appel en lecture en instantané dans un nombre minimum de partitions localisées sur des nœuds distincts du cluster.

Si ce principe n’est pas respecté, cela impacte la performance globale du cluster. En effet, lorsqu’une requête de lecture est lancée le nœud coordinateur va vérifier les nœuds qui contiennent la partition demandée.

Figure 7 – vérification des partitions key

3) Anticiper la croissance du volume de données

Un partitionnement de données qui est pertinent pour une centaine d’utilisateurs simultanés peut devenir un point de rupture unique du point de vue de la performance pour des millions d’utilisateurs simultanés.

C’est pourquoi la “Partition Key” d’une table doit prendre en compte les critères de performance cibles attendus par les applications clientes en appliquant des principes de partitionnement équilibrés sur des volumes croissants de données.

Pas de jointures

L’une des particularités avec le langage CQL est que vous ne pouvez pas effectuer de jointure classique entre deux tables comme on serait tenté de le faire sur un modèle de base classique (jointure clé primaire / clé étrangère).

Pourquoi ?

Vous perdrez énormément en performance et en montée en charge.

Que dois-je Faire ?

Le mot clé est la dénormalisation. Cassandra permet de regrouper dans un seul Keyspace un très grand nombre de données en grandes tables. Chaque table doit ainsi satisfaire à l’exécution d’une requête client. Il faudra donc prendre en compte dans la phase de modélisation des données les futures requêtes clientes afin de regrouper au maximum les données dans des tables uniques.

Créer des requêtes de simulation de charge

Dès la phase de développement, il est nécessaire d’exécuter des requêtes de simulation de charge avant la mise en production

Pourquoi ?

L’objectif est d’évaluer les ressources (mémoire, CPU, stockage) de chaque nœud et le temps d’exécution moyen nécessaires à l’exécution des requêtes. Une charge trop importante peut considérablement accroître le temps de récupération des données d’une requête.

Que dois-je Faire ?

Effectuer des tests techniques dans un environnement de pré-production dont les nœuds du cluster correspondent au dimensionnement des nœuds dans l’environnement de production. Ces tests permettent d’établir des ajustements du cluster tels que :

La capacité en nombre de nœuds pour la production
L’augmentation / réduction des ressources des nœuds (mémoire, CPU, stockage).

Cassandra dans les entreprises

La base de données Cassandra est utilisée par de nombreuses entreprises possédant des profils variés. Deux cas d’usages dans deux domaines différents (tertiaire et banque) sont présentés.

Accor

Accor est l’un des leaders mondiaux du domaine hôtelier, le groupe dispose de 4900 hôtels répartis à travers 110 pays. Le groupe a dû revoir l’architecture de son réseau en 2015.

L’objectif était de transformer l’ancien modèle de gestion qui ne pouvait plus gérer la montée en charge des demandes de réservations et ne disposait pas de données en temps réelles (les données étaient pré-calculées). Cela amenait à une mauvaise expérience utilisateur et bien souvent à une perte ou une corruption des données.

La nouvelle architecture basée sur un cluster Cassandra répond parfaitement aux critères de montée en charge et permet au groupe Accor de disposer de données de réservations des clients en temps réel.

Figure 8 – Gestion des informations de réservation en temps réel au sein du groupe Accor

ACI Worldwide

ACI Worldwide propose un service de paiement électronique en temps réel et souhaitait une solution de détection de fraude.

Une transaction bancaire peu importe son profil est susceptible de fraude, une couche de détection a donc été mis en place quand une demande de déplacement de finance est créée. Avec l’essor du E-Commerce le nombre de transaction a augmenté de façon exponentielle. En pratique on estime que 1 transaction sur 85 est une fraude.

Les exigences de ACI Worldwide étaient les suivantes :

Nécessité d’un stockage de volumes massifs de données de transaction clientes d’une haute complexité.
Pouvoir gérer les différents profils de client (marchand / intermédiaire bancaire) et les pics d’utilisation du service.
Le but de la plateforme de détection est principalement de passer inaperçu pour le client en ne diminuant pas la vitesse de traitement de la transaction.

La base de données Cassandra est ici utilisée en adéquation avec la plateforme interne de détection de fraude, cette plateforme peut traiter les transactions avec une haute vélocité tout en garantissant la sécurité des requêtes.

En parallèle les données clientes sont utilisées pour améliorer le modèle d’apprentissage de détection de fraudes de la plateforme sans aucune interruption de service ou d’augmentation du trafic.

La solution obtenue combine ainsi prise de décision et Big Data afin d’améliorer le taux de détection des fraudes et de faux positif.

Conclusion

Les principaux avantages de l’architecture Cassandra sont les suivants :

Evolution dynamique : L’architecture distribuée d’un cluster Cassandra permet d’augmenter le nombre de nœuds ainsi que la puissance de traitement sans interruption de service.
Haute disponibilité : si l’un des nœuds tombe en panne un autre prend le relais.
Performances élevées : la scalabilité horizontale de la solution est gérée par l’augmentation du nombre de nœuds.
Stockage flexible : Cassandra autorise de nombreux format de données (structuré, semi-structuré). Elle peut s’adapter de façon dynamique en fonction des modifications de la structure des données.

Si vous souhaitez en savoir plus, le site de DataStax contient une documentation fournie et un blog ou la communauté est active. De plus, des workshops encadrés par Datastax sont organisés régulièrement pour se familiariser avec leurs technologies.

Vous pouvez retrouver et vous inscrire à ces événements à l’adresse suivante :

https://www.datastax.com/events/