Init.

.vscode/settings.json

@@ -0,0 +1,3 @@
+{
+    "editor.formatOnSave": false
+}

diagrams/diagrams.plantuml

@@ -0,0 +1,31 @@
+@startuml cassandra_data_model
+
+title "Modèle de donnée de Cassandra : Large colonne"
+
+rectangle "0-N Espace de clés" #8888ff {
+    rectangle "0-N Table" #88ffff {
+        rectangle "0-N Colonne" #ffff88 {
+            rectangle "0-N Ligne" #ff8888 {
+                rectangle "Valeur"
+            }
+            rectangle "Clé"
+        }
+    }
+}
+
+@enduml
+
+@startuml not_only_sql_venn
+
+title "NoSQL comme super-ensemble du SQL"
+
+rectangle NoSQL #8888ff {
+    rectangle SQL #88ffff {
+        rectangle MySQL
+        rectangle SQLite
+    }
+    rectangle Cassandra
+    rectangle Giraph
+}
+
+@enduml

presentation.md

@@ -0,0 +1,381 @@
+---
+marp: true
+header: Cassandra et les bases de données NoSQL
+footer: 3SE • Matthieu Jolimaitre • 24/06/2025
+---
+<!-- paginate: true -->
+
+<style>
+.cent {
+  display: flex;
+  align-items: center;
+  justify-content: space-around;
+  margin: 2rem;
+}
+
+small {
+  font-size: 0.75rem;
+}
+
+.cols {
+  display: flex;
+  align-items: center;
+  justify-content: space-around;
+
+}
+
+</style>
+
+# Cassandra et les bases de données NoSQL : architecture, performances et cas d’usage
+
+Analyser les principes de Cassandra, ses avantages par rapport aux bases relationnelles, et ses cas d’application dans le Big Data.
+
+> Matthieu Jolimaitre
+
+<br>
+
+<div class="cent">
+  <img width="300" src="./diagrams/cassandra_logo.png">
+  <img width="300" src="./diagrams/NoSQL_logo.jpg">
+</div>
+
+---
+
+## Sommaire
+
+<small>
+
+- Introduction aux bases NoSQL
+  - Pourquoi NoSQL ?
+  - Catégories (clé-valeur, document, colonne, graphe)
+- Architecture de Cassandra
+  - Peer-to-peer, partitionnement, réplication
+  - Consistency levels et CAP theorem
+- Modèle de données et requêtage
+  - Tables dénormalisées, CQL (Cassandra Query Language)
+- Performances et cas d’usage
+  - Écritures rapides, scalabilité horizontale
+  - Cas d’étude
+- Limites et comparaison avec d’autres NoSQL
+
+</small>
+
+---
+
+## Introduction aux bases NoSQL
+
+> Not Only SQL
+
+![bg fit right](./diagrams/not_only_sql_venn.png)
+
+---
+
+#### Le SQL
+
+Un modèle de donnée appuyé sur des tableaux et des scripts de modification.
+
+<br>
+
+```sql
+INSERT INTO checkouts
+  (id, user_id, book_id, checkout_date, return_date)
+VALUES
+  (1, 1, 1, '2017-10-15 14:43:18', NULL),
+  (2, 1, 2, '2017-10-05 16:22:44', '2017-10-13 13:00:12'),
+  (3, 2, 2, '2017-10-15 11:11:24', '2017-10-22 17:47:10'),
+  (4, 5, 3, '2017-10-15 09:27:07', NULL);
+```
+
+![bg fit right](./diagrams/sql_table_preview.png)
+
+---
+
+### Pourquoi NoSQL ?
+
+<div class="cols">
+
+<div>
+
+- Utiliser de nouvelles topologies.
+  - Fournir des interfaces de modification plus adaptés à la donnée.
+- Se détacher du modèle de données arrangées en tables.
+  - Modéliser des états plus complexes.
+  - Optimiser en fonction des données.
+
+</div>
+
+<div>
+
+- Autoriser des transgressions du principe ACID.
+  - Atomicité.
+  - Consistance.
+  - Isolation.
+  - Durabilité.
+- Apparition de nouveaux principes BASE.
+  - Basiquement Disponible.
+  - Souplesse de l'état.
+  - Éventuellement consistent.
+
+</div>
+
+</div>
+
+---
+
+### Catégories
+
+<small>
+
+- **clé-valeur** : Les données sont des valeurs accessibles par leur clé (souvent un texte).
+- **document** : Clé-valeur optimisé pour les données structurées.
+- **colonne larges** : Les données sont mises en tableau, mais le schéma d’un même tableau peut varier selon les lignes.
+- **graphe** : Les données sont arrangées dans des nœuds pouvant être référencés dans d’autres nœuds.
+
+</small>
+
+![bg fit right](./diagrams/nosql_categories.png)
+
+---
+
+## Architecture de Cassandra
+
+- Suit un modèle de donnée en **Large colonnes**.
+- **Distribuée** : Les données sont répliquées sur plusieurs 'nœuds' pour permettre une expansion horizontale et pour se rendre résilient aux pannes.
+- Garanti une **consistance éventuelle**.
+
+![bg fit right](./diagrams/cassandra_architecture.png)
+
+---
+
+### Peer-to-peer, partitionnement, réplication
+
+Différentes techniques pour répartir et synchroniser les données dans un système distribué.
+
+![bg fit right](./diagrams/nodes_gossip_example.png)
+
+---
+
+#### pair-à-pair
+
+Pour synchroniser les changements de données, **la grappe n’utilise pas un nœud autoritaire** orchestrant la synchronisation.
+
+À la place, les nœuds communiquent périodiquement par deux, sans hiérarchie, en utilisant un **protocole de 'potins'**.
+
+![bg fit right](./diagrams/gossip_protocol.png)
+
+---
+
+#### Partitionnement
+
+<small>
+
+Pour réduire la charge d’une requête sur la grappe, les données sont partitionnées entre les différents nœuds.
+
+C’est à dire qu’**une donnée n’apparaitra que sur 'certains' nœuds** de la grappe, et qu’une requête accédant à cette donnée devra être traitée par un de ces nœuds.
+
+Pour une donnée partitionnée, l’adresse du nœud contenant une ligne est comprise **dans sa clé primaire**.
+
+</small>
+
+![bg fit right](./diagrams/partition_example.png)
+
+---
+
+#### Réplication
+
+<small>
+
+Pour diminuer le **risque de perte** de donnée et augmenter la **disponibilité** d’une donnée, la réplication sert à contenir la même donnée dans plusieurs nœuds.
+
+Concrètement, les partitions ont chacune un **facteur de réplication** RF, et **une partition est copiée vers RF nœuds** différents à partir d’un nœud responsable de cette partition.
+
+Ce système est implémenté avec un mécanisme de jeton.
+
+</small>
+
+![bg fit right](./diagrams/replication_example.jpg)
+
+---
+
+### Consistency levels et CAP theorem
+
+Les bases de données distribués ont trois aspects propres :
+- **Consistance** : Toutes les lectures d’une même donnée retournent la version la plus récente de cette donnée.
+- **Disponibilité** : Maximiser le taux de réponse aux requêtes saines.
+- **Tolérance au partitionnement** : La dégradation de certains nœuds n’entraine pas une dégradation du système.
+
+---
+
+### Consistency levels et CAP theorem
+
+Le 'théorème de CAP' énonce qu’une base de donnée distribuée **doit se focaliser sur deux aspects**, car il est impossible d’en atteindre deux sans en sacrifier un.
+
+![bg fit right](./diagrams/CAP_theorem_venn.png)
+
+---
+
+## Modèle de données et requêtage
+
+Cassandra suit un modèle de **tables à colonnes larges**, les colonnes sont de taille et structure dynamique : Le même tableau peut avoir des lignes de colonnes différentes.
+
+Cela augmente la **flexibilité de modélisation** et diminue les **efforts de mise à jour du schéma** d’un tableau.
+
+![bg fit right](./diagrams/cassandra_data_model.png)
+
+---
+
+### Tables dénormalisées, CQL (Cassandra Query Language)
+
+<small>
+
+Le modèle de donnée est normalisé lorsqu'il réponds à plusieurs exigences :
+- **UNF** : Aucune colonne n'est dupliquée.
+- **1NF** : Les colonnes doivent contenir des valeurs primitives, et non des agrégats.
+- **2NF** : Chaque colonne d’un tableau dépends de toutes les clés primaires de ce tableau.
+- **3NF** : Les colonnes ne dépendent uniquement des clés primaires de leur tableau.
+
+</small>
+
+```
+ Normalisé                         │ Dénormalisé
+┌──────────────┐ ┌───────────────┐ │ ┌─────────────────────────┐ ┌───────────────┐
+│USERS BY EMAIL│ │USERS          │ │ │USERS BY EMAIL           │ │USERS          │
+├─────┬────────┤ ├──┬────────┬───┤ │ ├──┬─────┬────────┬───────┤ ├──┬────────┬───┤
+│email│ user_id│ │id│    name│age│ │ │id│email│    name│user_id│ │id│    name│age│
+├─────┼────────┤ ├──┼────────┼───┤ │ ├──┼─────┼────────┼───────┤ ├──┼────────┼───┤
+│b@o.b│       1│ │ 1│     bob│ 19│ │ │ 1│b@o.b│     bob│      1│ │ 1│     bob│ 19│
+│c@r.l│       2│ │ 2│ charlie│ 23│ │ │ 2│c@r.l│ charlie│      2│ │ 2│ charlie│ 23│
+└─────┴────────┘ └──┴────────┴───┘ │ └──┴─────┴────────┴───────┘ └──┴────────┴───┘
+```
+
+---
+
+- La dénormalisation :
+  - Réduit le nombre d’opération par lecture.
+  - Augmente le nombre d’opération par écriture.
+
+<br>
+
+```
+ Normalisé                         │ Dénormalisé
+┌──────────────┐ ┌───────────────┐ │ ┌─────────────────────────┐ ┌───────────────┐
+│USERS BY EMAIL│ │USERS          │ │ │USERS BY EMAIL           │ │USERS          │
+├─────┬────────┤ ├──┬────────┬───┤ │ ├──┬─────┬────────┬───────┤ ├──┬────────┬───┤
+│email│ user_id│ │id│    name│age│ │ │id│email│    name│user_id│ │id│    name│age│
+├─────┼────────┤ ├──┼────────┼───┤ │ ├──┼─────┼────────┼───────┤ ├──┼────────┼───┤
+│b@o.b│       1│ │ 1│     bob│ 19│ │ │ 1│b@o.b│     bob│      1│ │ 1│     bob│ 19│
+│c@r.l│       2│ │ 2│ charlie│ 23│ │ │ 2│c@r.l│ charlie│      2│ │ 2│ charlie│ 23│
+└─────┴────────┘ └──┴────────┴───┘ │ └──┴─────┴────────┴───────┘ └──┴────────┴───┘
+```
+---
+
+#### Cassandra Query Language : Un DSL pour Cassandra
+
+```sql
+/* Create a new keyspace in CQL */
+CREATE KEYSPACE myDatabase WITH replication = 
+   {'class': 'SimpleStrategy', 'replication_factor': 1};
+
+/* Create a new database in SQL */
+CREATE DATABASE myDatabase;
+```
+```sql
+/* Expiring Data in 24 Hours */
+INSERT INTO myTable (id, myField) VALUES (2, 9) USING TTL 86400;
+```
+
+- Les écritures sont peu coûteuses, donc il est encouragé de créer des tables redondantes plutôt que des requêtes complexes.
+  - Le filtrage est désactivé par défaut.
+
+---
+
+## Performances et cas d’usage
+
+- Distribué
+  - **Répliqué** : Forte résilience.
+  - **Partitionné** : Bonne mise à l’échelle.
+- **NoSQL** : Flexibilité.
+  - Modéliser sa donnée avec moins de contraintes.
+  - Adapter les schémas pour améliorer les performances.
+
+---
+
+### Écritures rapides, scalabilité horizontale
+
+Cassandra est une base de donnée optimisée pour la **mise à l’échelle**, c’est à dire offrir une grande disponibilité au détriment de la **consistance forte des données**.
+
+Donc elle est recommandée dans les cas où il y a une haute contention d’écritures, et où la consistance de la donnée n'est pas cruciale.
+
+![bg fit right](./diagrams/cassandra_scalability_benchmark.png)
+
+---
+
+### Cas d’étude : Discord
+
+![bg right](./diagrams/discord_background.webp)
+
+
+>  July, we announced 40 million messages a day, in December we announced 100 million. How do we do it? Cassandra!
+>
+> <br>
+>
+> https://discord.com/blog/how-discord-stores-billions-of-messages
+
+---
+
+#### Requirements
+
+> We defined our requirements:
+> 
+> - **Linear scalability** : We do not want to reconsider the solution later or manually re-shard the data.
+> - **Low maintenance** : It should just work once we set it up. We should only have to add more nodes as data grows.
+> - **Predictable performance** : We have alerts go off when our API’s response time 95th percentile goes above 80ms. We also do not want to have to cache messages in Redis or Memcached.
+> - **Not a blob store** : Writing thousands of messages per second would not work great if we had to constantly deserialize blobs and append to them.
+> 
+> Cassandra was the only database that fulfilled all of our requirements.
+
+---
+
+#### Distribution
+
+> Here is a simplified schema for our messages table (this omits about 10 columns).
+> 
+> ```sql
+> CREATE TABLE messages (
+>   channel_id bigint, bucket int, message_id bigint, author_id bigint, content text,
+>      PRIMARY KEY ((channel_id, bucket), message_id)
+> ) WITH CLUSTERING ORDER BY (message_id DESC);
+> ```
+
+- Nous notons une clé de partitionnement composite, utilisant l’ID d’un salon ET un nombre arbitraire pour contrôler la taille des partitions.
+
+---
+### Résultats
+
+![](./diagrams/discord_perf.png)
+
+> At the beginning of 2022, it had 177 nodes with trillions of messages
+
+---
+
+## Limites et comparaison avec d’autres NoSQL
+
+---
+
+#### Faible consistance
+
+- Une **consistance éventuelle** entraine un risque de **courses de données** pouvant rendre l’état du service invalide.
+
+![bg fit right](./diagrams/race_condition.png)
+
+---
+
+#### Coût de la mise à l’échelle
+
+![bg fit right](./diagrams/scaling_comparison.png)
+
+- Les performances sur un seul noeud sont relativement basses.
+
+---
+
+## Fin