# Cassandra ...

## ... or not

---

## C'est quoi Cassandra?

---

## Base de données

- Créée par Facebook (2008)
- Projet Apache (écosystème communautaire)
- DataStax : principal acteur commercial (support, AstraDB, DSE, ...)

---

Base de données

- Orientée Famille de colonnes:
 - **1 famille** : ensemble de lignes
 - **1 clé par ligne** : simple ou composée (n colonnes)
 - **Valeur(s) par clé** : non requêtables
 - **Schéma fixe** : même structure pour toutes les lignes

---

Base de données

- Orientée Famille de colonnes
- Distribuée:
 - **Répartition** : Partition tolerance clé de répartition en plus de clé primaire

---

## C'est à dire ?

![](./img/3-what.jpg)

---

![](./img/4-col-oriented.step1.svg)

---

![](./img/4-col-oriented.step2.svg)

---

![](./img/4-col-oriented.step3.svg)

---

![](./img/4-col-oriented.step4.svg)

---

![](./img/4-col-oriented.step5.svg)

---

Base de données

- Orientée Famille de colonnes
- Distribuée:
 - Répartition
 - Multi-master: disponibilité Selon répartition, 1 master par partition

---

Base de données

- Orientée Famille de colonnes
- Distribuée:
 - Répartition
 - Multi-master
 - Compromis Consistance/latence “ajustable”

---

Niveau de consistance

- Limite minimale: Données sur 1, 2 ou 3 noeuds, ou sur tous

---

Niveau de consistance

- Limite minimale: 1, 2, 3, *ALL*
- Par quorum: selon réplication et noeuds Exemple : Si réplication à 3 avec 5 noeuds, alors quorum local à 2

---

![](./img/5-simple-repl.step1.svg)

---

![](./img/5-simple-repl.step2.svg)

---

![](./img/5-simple-repl.step3.svg)

---

![](./img/5-simple-repl.step4.svg)

---

Base de données

- Orientée colonnes
- Distribuée
- Performance écriture:
 - Example: Uber
 - Dizaines de millions de requêtes/s
 - Pétaoctets de données
 - Centaines de clusters (6 à 450 nœuds)

---

- CQL: SQL like
 - Ticket d'entrée faible pour les habitués SQL
 - Outils de validation syntaxe et grammaire (tests)

```sql
INSERT INTO a_table(foo, bar, lorem) VALUES(1, 2, '..');
UPDATE a_table SET foo = 1 WHERE lorem = '..'; -- !upsert
DELETE FROM a_table WHERE foo = 2;
```

---

- CQL
- Batch: Économie d'échelle
 - Réutiliser ressources pour plusieurs requêtes Exemple : Réduire roundtrip réseau, I/O
 - Garantir l'atomicité (si une seule partition)
 - Pas magique : à ne pas généraliser (surtout en multi-partitions)

```sql
BATCH
  INSERT INTO merchant(country, brand, ..)
  VALUES ('FR', 'IM', ..);

INSERT INTO merchant(country, brand, ..)
  VALUES ('FR', 'EM', '..');
APPLY BATCH;
```

---

- CQL
- Batch
- Écriture conditionnelle:
 - `INSERT` Exemple : Créer un vendeur uniquement si nouveau

---

![](img/6-cond-insert.step1.svg)

---

![](img/6-cond-insert.step2.svg)

---

- CQL
- Batch
- Écriture conditionnelle:
 - `INSERT`
 - `UPDATE` Exemple : Versioning article

---

![](img/7-cond-update.step1.svg)

---

![](img/7-cond-update.step2.svg)

---

- CQL
- Batch
- Écriture conditionnelle
- Colonne "static": partage même valeur / n lignes partition

---

## Et sinon ...

![](img/8-what-else.jpg)

---

- Pas de transaction: atomic batch, idempotence

---

- Pas de transaction
- Transformation sur mise à jour: uniquement possible sur colonnes compteurs ou collections

![](img/9-transformed-upd.svg)

---

- Pas de transaction
- Transformation sur mise à jour
- Requête multi-partitions
 - Impossible sur opération d'écriture

---

- Pas de transaction
- Transformation sur mise à jour
- Requête multi-partitions
 - Impossible sur opération d'écriture
 - Fortement déconseillé en batch: empêche l'atomicité, contention du coordinateur

---

- Pas de transaction
- Transformation sur mise à jour
- Requête multi-partitions
 - Impossible sur opération d'écriture
 - Fortement déconseillé en batch
 - Fortement déconseillé en lecture: <tt>SELECT .. IN</tt>

---

- Pas de transaction
- Transformation sur mise à jour
- Requête multi-partitions
- Pas de requête relationnelle: <tt>JOIN</tt> ou nested query
 - Possible avec d'autre DB distribuée/orientée colonne (ex : ClickHouse, MongoDB)

![](img/10-no-rel-query.svg)

---

Cas où il ne faut (vraiment) pas s'en servir?

- Développement
 - **Recherche multi-filtres**: respect strict ordre de la clé Exemple : Point de vente Pays/Enseigne/...

---

![](img/11-col-filtering.step1.svg)

**Recherche par Pays**: 👌

```sql
SELECT * FROM a_table WHERE Pays = 'FR';
```

---

![](img/11-col-filtering.step2.svg)

**Recherche par Pays et Enseigne**: 👌

```sql
SELECT * FROM a_table WHERE Pays = 'FR' AND Enseigne = 'IM';
```

---

![](img/11-col-filtering.step3.svg)

**Recherche par Enseigne**: ❌

```sql
SELECT * FROM a_table WHERE Enseigne = 'IM';
```

Impossible de filtrer par `Enseigne` sans `Pays`.

---

Cas où il ne faut (vraiment) pas s'en servir?

- Développement
 - Recherche multi-filtres
 - Allow filtering: Filtrage côté client; Déconseillé

<blockquote>When your query is rejected by Cassandra because it needs filtering, you should resist the urge to just add <tt>ALLOW FILTERING</tt> to it.</blockquote>

---

Cas où il ne faut (vraiment) pas s'en servir?

- Développement
 - Recherche multi-filtres
 - Allow filtering: déconseillé
 - Index secondaire: généralement déconseillé

<blockquote>Secondary indexes are tricky to use and can impact performance greatly.</blockquote>

---

Cas où il ne faut (vraiment) pas s'en servir?

- Développement
 - Recherche multi-filtres
 - Allow filtering: déconseillé
 - Index secondaire: généralement déconseillé
 - Dénormalisation automatique: Materialized view "Tables" virtuelles mises à jour sur chaque écriture
 - Meilleures performances que Index secondaire: Plus stables depuis Cassandra 4 À restreindre à des cas spécifiques

---

![](img/12-mat-view.svg)

---

Cas où il ne faut (vraiment) pas s'en servir?

- Développement
 - Recherche multi-filtres
 - Allow filtering: déconseillé
 - Index secondaire: généralement déconseillé
 - Dénormalisation automatique: Materialized view "Tables" virtuelles mises à jour sur chaque écriture
 - Meilleures performances que Index secondaire
 - Perte de performance en écriture (varie fortement selon workload)

---

Cas où il ne faut (vraiment) pas s'en servir?

- Développement
 - Recherche multi-filtres
 - Allow filtering: déconseillé
 - Index secondaire: généralement déconseillé
 - Dénormalisation automatique: déconseillé en systématique
 - Dénormalisation applicative: complexe
 - Dupliquer manuellement dans différentes tables
 - Conserver avantage batching

---

Cas où il ne faut (vraiment) pas s'en servir?

- Développement
 - Recherche multi-filtres
 - Recherche par intervalles: range query
 - Le critère doit faire partie de la *clustering key*
 - On ne peut filtrer une colonne que si la précédente est aussi filtrée (en égalité)
 - On ne peut pas rajouter un critère si la colonne précédente est une range query

---

Cas où il ne faut (vraiment) pas s'en servir?

- Développement
 - Recherche multi-filtres
 - Recherche par intervalles
 - Distribution hétérogène: selon cas d'utilisation
 - Diminution parallélisme
 - Dépassement cache I/O
 - Partitionnement "à priori" (vs rollover ElasticSearch); Exemple : article/pdf
 - Contournement par Synthetic sharding

---

Cas où il ne faut (vraiment) pas s'en servir?

- Développement
 - Recherche multi-filtres
 - Recherche par intervalles
 - Distribution hétérogène
 - Différentes manières de référencer les mêmes données
 - Read-before-update: hausse read par rapport à write
 - Compromis dénormalisation (compensation applicative, problématique consistance/atomicité)

---

Cas où il ne faut (vraiment) pas s'en servir?

- Développement
 - Recherche multi-filtres
 - Recherche par intervalles
 - Distribution hétérogène
 - Différentes manières de référencer les mêmes données
 - Qualité du driver

```java
bind(Object... values)
```

---

Cas où il ne faut (vraiment) pas s'en servir?

- Développement
 - Recherche multi-filtres
 - Recherche par intervalles
 - Distribution hétérogène
 - Différentes manières de référencer les mêmes données
 - Qualité du driver
 - Ordre résultats lecture figé par table

---

![](img/13-fixed-filtering.svg)

**Tri par Pays**: ❌ (ordre partitions)

```sql
SELECT * FROM a_table ORDER BY Pays DESC;
```

---

![](img/13-fixed-filtering.svg)

**Tri par Enseigne pour un Pays**: 👌 (ordre clustering keys)

```sql
SELECT * FROM a_table WHERE Pays='FR' ORDER BY Enseigne DESC;
```

---

![](img/13-fixed-filtering.svg)

**Tri global par Enseigne**: ❌ (multi-partitions par Pays)

```sql
SELECT * FROM a_table ORDER BY Enseigne DESC;
```

---

![](img/13-fixed-filtering.svg)

**Tri par ID puis Enseigne**: ❌

```sql
SELECT * FROM a_table WHERE Pays='FR' ORDER BY ID DESC, Enseigne DESC;
```

---

Cas où il ne faut (vraiment) pas s'en servir?

- Développement
- Exploitation
 - Complexité:
 - Sauvegarde
 - Periodic Anti-anthropy Repair
 - Incremental Repair (mature depuis v4)

---

Cas où il ne faut (vraiment) pas s'en servir?

- Développement
- Exploitation
 - Complexité: 
 - Sauvegarde, Periodic Anti-anthropy Repair, Incremental Repair
 - Cohérence des outils (ex : incohérence options)

---

Cas où il ne faut (vraiment) pas s'en servir?

- Développement
- Exploitation
 - Complexité: 
 - Sauvegarde, Periodic Anti-anthropy Repair, Incremental Repair
 - Cohérence des outils
 - Supervision, Logs parfois sibyllins (ex : slow query, malgré amélioration outillage depuis v4)

---

Cas où il ne faut (vraiment) pas s'en servir?

- Développement
- Exploitation
 - Complexité:
 - ...
 - Cohérence des outils
 - Supervision, Logs parfois sibyllins
 - Imprévisibilité options/use case(ex : compaction/gc) Difficulté tuning, nécessité jouer plus paramètre en même temps plutôt que un à un comme généralement

---

---

Cas où il ne faut (vraiment) pas s'en servir?

- Développement
- Exploitation
 - Complexité: 
 - ...
 - Supervision, Logs parfois sibyllins
 - Support / expertise (DataStax, Amazon Keyspaces, Instaclustr, ...):
 - Coût important
 - Valeur variable selon besoins

---

Cas où il ne faut (vraiment) pas s'en servir?

- Développement
- Exploitation
 - Complexité: 
 - ...
 - Support / expertise (Coût, valeur variable, ...)
 - Documentation: abondante / parfois contradictoire
 - Atomicité/isolation batch
 - Compaction selon use case
 - Bulk load

---

Cas où il ne faut (vraiment) pas s'en servir?

- Développement
- Exploitation
 - Complexité:
 - ...
 - Documentation (abondante / parfois contradictoire)
 - Sizing
 - **Ticket d'entrée élevé**: Complexité opérationnelle réellement rentable lorsque plusieurs équipes ou applications mutualisent un cluster

---

Cas où il ne faut (vraiment) pas s'en servir?

- Développement
- Exploitation
 - Complexité:
 - ...
 - Sizing
 - Ticket d'entrée élevé
 - Physique/dédié recommandé: Cloud/Kubernetes possibles mais augmentent encore la complexité opérationnelle

---

Cas où il ne faut (vraiment) pas s'en servir?

- Développement
- Exploitation
 - Complexité:
 - ...
 - Sizing
 - Ticket d'entrée élevé
 - Physique/dédié recommandé
 - Reprise sur erreur
 - **Instabilité commit log**: intervention manuelle

---

Cas où il ne faut (vraiment) pas s'en servir?

- Développement
- Exploitation
 - Complexité:
 - ...
 - Sizing
 - ...
 - **Reprise sur erreur**
 - Instabilité commit log
 - Disque plein: complexité restauration noeud

---

- En ligne droite, ça va très vite
- Ne pas demander de changer de direction
- Le moindre écart se paie rapidement

---

## À expérimenter …

(non exhaustif, selon use cases)

- ClickHouse
- SyllaDB
- Yugabyte
- Kafka (forever retention)
- MongoDB sharding (distributed write, routing serveur)
- ElasticSearch

---

## À expérimenter …

(non exhaustif, selon use cases)

- ...
- MongoDB sharding (distributed write, routing serveur)
- ElasticSearch
- SGBD “classiques” en distributed flavour
  - Amazon RDS / Aurora, Google Cloud SQL, Azure CosmoDB
  - MySQL Cluster, PostgreSQL + Citrus

---

## Questions?

[@cchantep](https://www.linkedin.com/in/cchantep/)