Introduction à Apache Cassandra — IppEvent chez OVH 2017-03-02

Introduction à Apache Cassandra
Jérôme Mainaud

Ippon Technologies © 2017
Architecte logiciel chez Ippon Technologies
Manager Technique
@jxerome
jmainaud@ippon.fr
Jérôme Mainaud

Ippon Technologies

Acteur de l'innovation

Cassandra
● Base de données
● No SQL
● Modèle Table partitionnée
➔ Autrefois : "Famille de colonnes"
● Projet Apache

Inspiration
● Amazon Dynamo
➔ Architecture distribuée
➔ Anneau distribué
➔ Cohérence à terme (Eventual consistency)
● Google BigTable
➔ Modèle de stockage
➔ Famille de colonnes

Ambitions
● Scalabilité linéaire
➔ Plus de perf ? → Ajouter un nœud
➔ Plus de volume ? → Ajouter un nœud
● Haute disponibilité
➔ Pas de SPOF
➔ Tous les nœuds sont équivalents

Cluster
● Décentralisé (pair-à-pair)
➔ Pas de maître, ni d'esclave
● Multi-Datacenter
➔ Répartition géographique
➔ Ségrégation opérationnel / analytique
● Gossip Protocol
➔ Une fois par second
➔ échange des infos cluster
➔ avec trois nœuds tirés au sort

Zero Downtime
Très Haute Disponibilité

● Transactions ACID
● Modèle de données inadapté
Quand ne pas utiliser Cassandra ?

Tables partitionnées

Dimensionnement
● Dimension d’une table
➔ Aucune limite du nombre de partition dans une table
● Dimension d’une partition
➔ La partition doit tenir un seul nœud
➔ Max 2 milliards de cellules par partition (en pratique < 100 000)
➔ Max 2 Go par cellule (en pratique < 100 Mo par partition)
● A partir de la version 3.6
➔ Optimisation du fonctionnement des grandes partitions
➔ Limites à revoir à la hausse.
➔ Mais il faut toujours borner les partitions

Clé primaire
Primary key = partition key + clustering columns
➔ Partition key → partition (obligatoire pour une requête)
➔ Clustering key → regroupe les colonnes en lignes (conservées classées)
PRIMARY KEY (invoice_id, item_id)
PRIMARY KEY ((customer_id, year), date, event_id)

Type de données
● int, bigint, float, double, decimal, varint, smallint, tinyint
● text (utf-8), ascii, varchar
● boolean
● timestamp (millisecondes / epoch), date, time (nanoseconde / minuit)
● UUID, TimeUUID
● inet
● blob
● map (permet de retrouver les modèles dynamiques)
● set
● list
● counter (type très spécial)
● User Defined Type

CQL 3
● Langage équivalent au SQL
● Géré directement par le driver
● Facilite la modélisation et l'utilisation de Cassandra
● cqlsh
➔ ligne de commande
Note: les exemples suivants sont inspirés de KillrVideo
https://killrvideo.github.io/

Créer une table
CREATE TABLE IF NOT EXISTS videos (
videoid uuid,
userid uuid,
name text,
description text,
location text,
location_type int,
preview_image_location text,
tags set<text>,
added_date timestamp,
PRIMARY KEY (videoid)
);
✱ Create table
● « if not exist » facilite le
rejeu d'un script de
création
● Utilisation d'une
colonne multivaluée
(tags)

Créer une table
CREATE TABLE IF NOT EXISTS user_videos (
userid uuid,
added_date timestamp,
videoid uuid,
name text,
preview_image_location text,
PRIMARY KEY (userid, added_date, videoid)
)
WITH CLUSTERING ORDER BY (added_date DESC, videoid ASC);
✱ Create table
● Relation 1-N
user → vidéo
● Les vidéos sont
classées dans l'ordre
antichronologique.

Ajouter des données
insert into videos (
videoid,
userid,
added_date,
location,
location_type,
name,
tags
) values (
c211719c-ef66-b8a3-fa96-a05b6ed10e8e,
522b1fe2-2e36-4cef-a667-cd4237d08b89,
'1975-12-31 08:00:00+0000',
'http://www.youtube.com/watch?v=oI0yW4m9aaE',
0,
'Cassandra Crossing',
{'disaster movie', 'train'}
);
✱ Insert
● Command insert
● Les UUIDs s'écrivent
nativement
● Les ensembles (set)
avec des accolades
● La clé primaire doit être
renseignée
● Les écritures sont
atomiques

Modifier des données
update user_videos
set
name = 'Cassandra Crossing'
where
userid = 522b1fe2-2e36-4cef-a667-cd4237d08b89
and added_date = '1975-12-31 08:00:00+0000'
and videoid = c211719c-ef66-b8a3-fa96-a05b6ed10e8e;
insert into videos (
userid,
added_date,
videoid,
name
) values (
522b1fe2-2e36-4cef-a667-cd4237d08b89,
'1975-12-31 08:00:00+0000',
c211719c-ef66-b8a3-fa96-a05b6ed10e8e,
'Cassandra Crossing'
);
✱ Update
● Command update
● Insert et update sont
deux façons d'écrire la
même commande :
UPSERT

Modifier des données
update videos
set tags = tags + { 'ovh', 'ippon' }
where
videoid = c211719c-ef66-b8a3-fa96-a05b6ed10e8e;
select name,
tags
from videos
where videoid = c211719c-ef66-b8a3-fa96-a05b6ed10e8e;
name | tags
--------------------+---------------------------------------------
Cassandra Crossing | {'disaster movie', 'ippon', 'ovh', 'train'}
(1 rows)
✱ Update
● UPDATE permet
d'ajouter ou de retirer
des éléments d'un
ensemble
● Les écritures sont
atomiques

Lire les données
select name,
videoid,
userid,
added_date,
tags
from videos
where videoid = c211719c-ef66-b8a3-fa96-a05b6ed10e8e;
@ Row 1
------------+--------------------------------------
name | Cassandra Crossing
videoid | c211719c-ef66-b8a3-fa96-a05b6ed10e8e
userid | 522b1fe2-2e36-4cef-a667-cd4237d08b89
added_date | 1975-12-31 08:00:00+0000
tags | {'disaster movie', 'train'}
(1 rows)
✱ Select
● La clé de partition doit
être indiquée

select name,
added_date,
videoid
from user_videos
where userid = 522b1fe2-2e36-4cef-a667-cd4237d08b89
and added_date = '1975-12-31 08:00:00+0000';
select name,
added_date,
videoid
from user_videos
where userid = 522b1fe2-2e36-4cef-a667-cd4237d08b89
and added_date >= '1970-01-01 00:00:00+0000'
and added_date < '1980-01-01 00:00:00+0000';
Lire les données
✱ Select
● Il est possible de
rajouter des critères sur
les clustering columns
● La clé de partition doit
être indiquée
● L'ordre des clustering
columns dans la clé est
importante
● Le critère de dernière
clustering column
indiqué peut être une
inégalité

Vues matérialisées
✱ Vues
● Les requêtes possibles
sur une table restent
limitées
● Les données sont
dénormalisées pour
permettre les requêtes
nécessaires
● Les vues matérialisées
sont une aide pour la
dénormalisation
create materialized view if not exists video_by_name
as
select name,
videoid
from videos
where name is not null
and videoid is not null
primary key (name, videoid);

Cluster
● Nœud
➔ instance de Cassandra (JVM)
● Cluster
➔ ensemble de nœuds qui constituent une base de données
➔ un cluster constitue un anneau unique dans lequel se positionnent tous les nœuds
● Data center
➔ Un ensemble de nœuds associés assurant un niveau de réplication
➔ Permet la séparation de la charge de travail
➔ Peut correspondre à des datacenters réels ou virtuels
● Rack
➔ unité de disponibilité
➔ ensemble de nœud susceptibles de tomber en panne en même temps

Répartition des données
Consistent Hashing
➔ Les données sont regroupées dans des partitions
identifiées par une clé de partition
➔ La clé de partition est hashée (Murmur3) → entier
sur 64 bits
➔ Chaque nœud est positionné sur l’anneaux des
valeurs (initial_token) et est responsable de la
plage antérieure
Token
ring
- 263
+ 263
0
- 262
+ 262

Virtual Nodes — vnodes
● Plusieurs nœuds virtuels pour un même nœud physique
● Facilite le gestion de la montée en charge équilibrée des petits clusters
● Exemple
➔ cluster avec 6 nœuds
➔ 256 tokens par nœuds (num_token)
➔ 1536 segments

● Réplication simple
➔ La donnée est répliquée sur les successeurs de la première réplique.
● Réplication avec prise en compte de la topologie
➔ Facteur de réplication paramétré pour chaque datacenter
➔ pour chaque datacenter, les données sont réparties dans les différents racks.
● Algorithme NetworkTopologyStrategy
➔ à la première réplique,
➔ à ses successeurs par ordre de token croissant tel que
○ répliquée sur les différents datacenters selon le taux configuré
○ répartie dans le plus grand nombre de racks possibles
Réplication

Réplication — Coordinateur
DC - Ouest DC - Est
1
4
Rack1
Rack2
Client
Valeur
Coordinateur
35
26Rack3
1'
4'
RackA
RackB
3'5'
2'6'RackC
Coordinateur
distant

Gossip
● Protocole de communication entre les nœuds
● Une fois par seconde, un nœud contacte entre un et trois nœuds tirés
au sort et échange avec eux les informations dont il dispose sur le
cluster
➔ État des nœuds
➔ Emplacement des nœuds (DC, rack)
➔ Les informations sont horodatées la plus récente et conservée

Seeds
● Ajout d'un nouveau nœud
➔ Lorsqu’un nœud rejoint le cluster il contacte les serveurs de seed qui lui donnent les
informations sur le cluster et prend en compte sa présence
➔ La création du nouveau nœud est propagée aux autre nœuds par gossip
● Gossip
➔ Les nœuds seed interviennent plus souvent lors du gossip.
➔ Chaque nœud contacte au moins un seed à chaque tour

Consistency level
● Niveau de cohérence réglable
➔ Écriture: nombre d'acquittements nécessaires pour l'acquittement de la requête
➔ Lecture: nombre de lectures effectuées
● Les niveaux
➔ ANY (écriture uniquement)
➔ ONE
➔ QUORUM
➔ LOCAL_ONE
➔ LOCAL_QUORUM
➔ EACH_QUORUM
➔ ALL
Le niveau est défini à
chaque requête

Cohérence à terme — Eventual Consistency

Versions
● 2.1 : Version en fin de vie (utilisée par DSE 4.x)
● 2.2 : version intermédiaire en fin de vie
● 3.0.x : version de maintenance
➔ version de base de DSE 5.0
● 3.x : Tick-Tock release
➔ 3.( 2i ) : version avec ajout de fonctionnalités
➔ 3.( 2i + 1 ): version corrective
● Versions actuelles (2017-02-21)
➔ 2.1.17
➔ 2.2.9
➔ 3.0.11
➔ 3.7
Utiliser la
dernière release
de la version 3.0

Quelles instances ?
● 8 CPU
● 32 Go RAM
● 1 To SSD
➔ Si pas besoin de latence: 2 HDD (dont 1 petit pour les commit logs)
➔ RAID 0 sur disques données (JBOD si v > 3.2)
● 1 ou 2 cartes réseau min 1 Go
Proposition classique de départ à adapter aux besoins.
Doubler la mémoire si Spark est installé sur les mêmes machines.

Serveur dédié Public Cloud Private Cloud
● EG-32
○ Intel Xeon E5-1630v3
○ 4c / 8t - 3,7 GHz / 3,8 GHz
○ 32 Go DDR4 ECC 2133 MHz
○ 3 * 600 Go HDD SAS 15k RAID 0
● EG-64
○ 6c /12t - 3,5 GHz / 3,8 GHz
○ 64 Go DDR4 ECC 2133 MHz
○ 4 * 800 Go SSD RAID 0
● EG-16
○ 4c / 8t - 3,7 GHz / 3,8 GHz
○ 32Go DDR3 ECC 1600 MHz
○ 2 * 480 Go SSD
● HG-30
○ 30 Go
○ 8 vCore
○ 800 Go
○ ou 400 Go SSD
● HG-15
○ 15 Go
○ 4 vCore
○ 400 Go
○ ou 200 Go SSD
À dimensionner sur
mesure
Chez OVH

Exemple de cluster Cassandra sur OVH
✱ Points clés
● 2 DC
● 1 vRack cluster dédié
gossip
● Serveur applicatifs
répartis sur les deux
● LB IP pour répartition
charge et failover d'un
cluster

Construire un cluster
1. Installer Cassandra sur tous les nœuds
2. Choisir les nœuds seed
3. Configurer les instances de Cassandra
4. Démarrer les nœuds un par un en commençant par les seeds
5. Mettre en place les traitements de maintenance
a. repair
b. sauvegardes
Procédure détaillée
http://docs.datastax.com/en/cassandra/3.0/cassandra/initialize/initMultipleDS.html

Présentation générale

DataMC sur OVH

Blackfish
https://gitlab.com/blackfish/blackfish
VM CoreOS
Swarm Cluster
Mozilla Public License 2.0

Utiliser DataMC
1. Créer ou donner accès à un compte cloud public
a. OVH Public cloud
b. Cloud privé avec Openstack
c. Amazon
2. DataMC construit une infrastructure matérielle
3. DataMC donne l'accès à la console DataMC
4. Démarrer, gérer et arrêter les stacks selon les besoins
Le fonctionnement du système est supervisé par DataMC

Aller plus loin
http://datamc.io/
https://academy.datastax.com/
● DS101: Introduction to Apache Cassandra
● DS220: Data Modeling
● DS210: DataStax Enterprise Operations with Apache
Cassandra

PARIS
BORDEAUX
NANTES
LYON
MARRAKECH
WASHINGTON DC
NEW-YORK
RICHMOND
MELBOURNE
contact@ippon.fr
www.ippon.fr - www.ippon-hosting.com - www.ippon-digital.fr
@ippontech
-
01 46 12 48 48

Introduction à Apache Cassandra — IppEvent chez OVH 2017-03-02

Recomendados

Recomendados

Más contenido relacionado

La actualidad más candente

La actualidad más candente (20)

Destacado

Destacado (20)

Similar a Introduction à Apache Cassandra — IppEvent chez OVH 2017-03-02

Similar a Introduction à Apache Cassandra — IppEvent chez OVH 2017-03-02 (20)

Introduction à Apache Cassandra — IppEvent chez OVH 2017-03-02