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

[email protected]

Jérôme Mainaud


Ippon Technologies


Acteur de l'innovation

Cassandra


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

Quand utiliser Cassandra ?


Zero Downtime

Très Haute Disponibilité


● Transactions ACID

● Modèle de données inadapté

Quand ne pas utiliser Cassandra ?

Modèle de données


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_nameasselect name, videoid from videos where name is not null and videoid is not nullprimary key (name, videoid);

Architecture générale


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

Tokenring

- 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

Coordinateurdistant


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

Déploiement


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○ Intel Xeon E5-1630v3○ 6c /12t - 3,5 GHz / 3,8 GHz○ 64 Go DDR4 ECC 2133 MHz○ 4 * 800 Go SSD RAID 0

● EG-16○ Intel Xeon E5-1620v2○ 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 maintenancea. repair

b. sauvegardes

Procédure détailléehttp://docs.datastax.com/en/cassandra/3.0/cassandra/initialize/initMultipleDS.html

http://docs.datastax.com/en/cassandra/3.0/cassandra/initialize/initMultipleDS.html

http://docs.datastax.com/en/cassandra/3.0/cassandra/initialize/initMultipleDS.html

Blackfish&

DataMC


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

http://datamc.io/

http://datamc.io/



PARISBORDEAUX

NANTESLYON

MARRAKECHWASHINGTON DC

NEW-YORKRICHMOND

MELBOURNE

[email protected] - www.ippon-hosting.com - www.ippon-digital.fr

@ippontech-

01 46 12 48 48

mailto:[email protected]

mailto:[email protected]

http://www.ippon.fr

http://www.ippon-hosting.com

http://www.ippon.fr

introduction à apache cassandra — ippevent chez ovh 2017-03-02

Data & Analytics