Slides pour la présentation di Big Data 2022.

1. Innovations récentes et futures
autour de la base NoSQL
Apache Cassandra™

2. PRESENTATION
(10 MIN)
DEMO
(10 MIN)
JEUX
INTERACTIF
(10 MIN)
11H15

3. Cédrick
Lunven
Developer Advocates, Communauté, partenaires, évènements
3
@clunven
Directeur Developer Relations
➢ Speaker
➢ Streamer
➢ Auteur
➢ Formateur
➢ Community Manager
➢ Developpeur d’Applications
➢ Architecte Technique
➢ Avant-vente
➢ Support

4. Agenda
1. Apache Cassandra™: Rappels et cas d’usages
2. Tour d’horizon des nouveautés 4.0 et 4.1
3. En route vers Cassandra 5.0 4.2
4. Stargate, une data gateway pour simplifier les développements
5. K8ssandra pour des deploiements aisés en production
4

5. Agenda
● Apache Cassandra™: Rappels et cas d’usages
● Tour d’horizon des nouveautés 4.0 et 4.1
● En route vers Cassandra 5.0 4.2
● Stargate, une data gateway pour simplifier les développements
● K8ssandra pour des deploiements aisés en production
5

6. NODE
NODE
NODE
NODE
NODE NODE
NODE
ApacheCassandra™
1 Installation = 1 NOEUD
✔ Capacité = ~ 2-4To
✔ Performance =4 Tx/sec/core
Communication
✔ Gossiping
✔ Masterless
DataCenter | Anneau
= Base de données NoSql Distribuée

7. ApacheCassandra™ = Scalabilité Linéaire

8. ApacheCassandra™ = Scalabilité inégalée

9. Facteur de
réplication (RF)
0
50
33
17
83
67
La donnée est distribuée, partitionée, repliquée
Plage de
Token

10. Distribution géographique (DDN) Déploiements Hybrid-Cloud et
Multi-Cloud
Architectures distribuées
On-premise

11. High Throughput
High Volume
Heavy Writes
Heavy Reads
Event Streaming Log Analytics
Internet of Things Other Time Series
Mission-Critical
No Data Loss
Always-on
Scalabilité
Disponibilité
Distribuée
Cloud-native
Caching Pricing
Market Data Inventory
Banking Retail
Tracking /
Logistics
Customer
Experience
Containers Hybrid-cloud
Kubernetes Multi-cloud
Modern Cloud
Applications
Global Presence
Workload Mobility
Compliance /
GDPR
Cas d’usages ApacheCassandra™:

12. Agenda
● Apache Cassandra™: Rappels et cas d’usages
● Tour d’horizon des nouveautés 4.0 et 4.1
● En route vers Cassandra 5.0 4.2
● Stargate, une data gateway pour simplifier les développements
● K8ssandra pour des deploiements aisés en production
12

13. Cassandra 4 est arrivée !
6 ans !
Avant il était conseillé d’attendre 6
mois ou x.6, plus maintenant.
○ Property-based / fuzz testing
○ Replay testing
○ Upgrade / diff testing
○ Performance testing
○ Fault injection
○ Unit/dtest coverage expansion

14. Cassandra 4.x utilisée en PRODUCTION

15. 4.0 = “Stabilité et rapidité“
Facilité d’utilisation
Virtual Tables
Securité et monitoring
Full Query Logging
Communications Inter-node
Zero Copy Streaming +
ASYNC Communication
Fiabilité
Performance and options des Repairs
Performance
Support de JDK11

16. Virtual Tables
● Accéder aux données de monitoring
via CQL en lieu et place de JMX.
● Simplifier l’interface et les accès
● Activé par défaut, READ ONLY
● Ce n’est pas un remplacement mais
un ajout.

17. ● 2 keyspaces system_views et
system_virtual_schema
● Les données ne sont pas dans les
SSTABLES mais calculées
dynamiquement et spécifiques à
chaque noeud.
Virtual Tables

18. Audit Logging
● Tracer les modifications sur les
tables, QUI, QUAND, QUOI. Utile pour
les régulations.
● Loguer tous les champs:
○ user,host,source ip address
○ source port, type, category
○ keyspace, scope,operation
● Désactivé par défaut et activable
avec nodetool et cassandra.yaml
● Impact minimum sur les read/write
paths.

19. Communications InterNode Asynchrones
● Optimisation du protocole
○ Suppression redondances
○ Réduction taille messages
● Communications Asynchrones
○ Utilisation de NIO (+20%)
○ Thread-per-peer
○ Moins de context-switching
● Autres Optimisations
○ Hint messaging
○ Application timeout
○ Paxos (messagingServiceStack)
○ Unknown tables
https://issues.apache.org/jira/browse/CASSANDRA-8457
https://issues.apache.org/jira/browse/CASSANDRA-15066

20. Zero Copy Streaming
● Avant streaming par partition:
serialise, compress, transfer,
decompress, deserialise, reindex
● Maintenant, toute la SSTABLE est
streamée en une fois. (jusqu’à 5 fois
plus rapide)
● Conséquence directe: le
boostrapping d’un noeud peut
également être amélioré d’un facteur
5.
https://cassandra.apache.org/blog/2018/08/07/faster_streaming_in_cassandra.html

21. Amélioration des “Repairs” ● Précédemment on streamait trop car
l’anti-compaction arrivait trop tard
(meme avec incrémental repair)
● Maintenant dans une transaction Paxos
(rollback)
● Anti Compaction directement avant le
streaming pour limiter les échanges.
● La construction des merkle tree
uniquement sur le nouveau pending
repair-pool.

22. Nouveau JDK, Nouveaux GC ● +25% de performance en débit et
latence
● Algorithme Shenandoah sur Java 11
réduit de 85% la latence pour certain
workloads.

23. https://www.datastax.com/learn/whats-new-for-cassandra-4

24. 4.1 = “Simplicité et Sécurité”
● Thèmes
○ Utilisation simplifiée
○ Sécurité et fiabilité
○ Extensibilité
○ Cloud-native
● 3 améliorations importantes
○ GuardRails (garde-fou)
○ Verrouiller des partitions
○ Points d’extension
https://medium.com/building-the-open-data-stack/apache-cassandra-4-1-building-the-database-your-kids-will-use-431f32210a30

25. GuardRails
● Le problème
○ Les utilisateurs exécutent des requêtes non
optimales
○ Les administrateurs ne configurent pas
correctement leur système
● La solution = “GuardRails”
○ Mettre des limites (faibles et fortes)
○ Désactiver certaines fonctionnalités
○ Désactiver certaines configurations
https://cassandra.apache.org/_/blog/Apache-Cassandra-4.1-Features-Guardrails-Framework.html

26. Verrouillage (Denylist) des partitions
Country City Population
USA New York 8.000.000
USA Los Angeles 4.000.000
FR Paris 2.230.000
DE Berlin 3.350.000
UK London 9.200.000
AU Sydney 4.900.000
FR Toulouse 1.100.000
JP Tokyo 37.430.000
IN Mumbai 20.200.000
DE Nuremberg 500.000
CA Montreal 4.200.000
CA Toronto 6.200.000
Partition Key

27. Verrouillage des partitions
USA New York 8.000.000
USA Los Angeles 4.000.000
UK London 9.200.000
AU Sydney 4.900.000
JP Tokyo 37.430.000
IN Mumbai 20.200.000
DE Berlin 3.350.000
DE Nuremberg 500.000
CA Montreal 4.200.000
CA Toronto 6.200.000
FR Toulouse 1.100.000
FR Paris 2.230.000

28. GuardRails - Limites fortes et faibles
● Configuration dans cassandra.yaml
● Expérience utilisateur:
partition_keys_in_select_warn_threshold: 5
partition_keys_in_select_fail_threshold: 18

29. GuardRails - Déactivation des fonctionnalités
● ALLOW FILTERING , configuration dans cassandra.yaml
● Vérification dans les system_views:
● Expérience utilisateur:
allows_filtering_enabled: false

30. Verrouillage des partitions
● Le problème
○ Certaines partitions sont très grosses et
difficilement opérables.
○ La latence en lecture et écriture augmentent
● La cause
○ Mauvais choix en termes de modèles de
données
○ Un jeu de données différents des attentes
○ Des attaques
● La solution
○ Interdire de modifier certaines partitions
https://cassandra.apache.org/_/blog/Apache-Cassandra-4.1-Denylisting-Partitions.html

31. Verrouillage des partitions
● Feature settings configured in cassandra.yaml
cqlsh> select * from system_distributed.partition_denylist;
ks_name | table_name | key
---------+------------+------------
foo | buz | 0x00000003
cqlsh> select * from foo.buz where key=3;
InvalidRequest: Error from server: code=2200 [Invalid query] message=
"Unable to read denylisted partition [0xDecoratedKey(9010454139840013625, 00000003)] in foo/buz"
cqlsh> select * from foo.buz where key=9;
key | c1 | c2 | c3 | c4
-----+----+----+----+----
9 | 1 | 3 | 4 | 5
9 | 9 | 3 | 4 | 5
cqlsh> insert into foo.buz (key, c1, c2, c3, c4) VALUES (3, 1, 1, 1, 1);
InvalidRequest: Error from server: code=2200 [Invalid query] message=
"Unable to write to denylisted partition [0xDecoratedKey(9010454139840013625, 00000003)] in foo/buz"

32. Points d’extensions “Pluggability”
● Permettre d’ajouter des fonctionnalités sans modifier le coeur.
● Changements internes avec système de “plugins”
Stockage:
- Memoires (memtables)
- Disque (SSTables)
Network encryption:
- SSL certificats plus locaux
- Support des KMS comme Vault
Authentification
- Supports LDAP
- Support Kerberos partout (cqlsh)
Gestion des schémas
- Avant uniquement sur tables systèmes
- Maintenant par exemple ETCD (K8s)
Guardrails (règles et seuils)
- Extension de 4.1

33. Agenda
● Apache Cassandra™: Rappels et cas d’usages
● Tour d’horizon des nouveautés 4.0 et 4.1
● En route vers Cassandra 4.2
● Stargate, une data gateway pour simplifier les développements
● K8ssandra pour des deploiements aisés en production
33

34. 4.2 = “Fonctionnalités”
● Messages de Diagnostic via CQL (et non JMX)
○ Plus de “virtual tables”
○ Initialiement prévu en 4.1
● Storage Attached Index (SAI)
○ Indexation de plusieurs colonnes
○ Scalabilité et range queries
● Consensus protocol evolution
○ Paxos -> Accord
● Transactions ACID
●
https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-15%3A+General+Purpose+Transactions

35. Storage Indexed Storage
35
Intended to replace both 2i and SASI

36. Agenda
● Apache Cassandra™: Rappels et cas d’usages
● Tour d’horizon des nouveautés 4.0 et 4.1
● En route vers Cassandra 4.2
● Stargate, une data gateway pour simplifier les développements
● K8ssandra pour des deploiements aisés en production
36

37. Pourquoi une Data Gateway ?
37
Ubiquitous, API-based Consumption
MICROSERVICES
DEVELOPERS
Les développeurs souhaitent
travailler avec des APIs modernes
(Rest API)
Une gateway permet une
abstraction des communications
(language, protocole, états)

38. Stargate.io

39. Extensions pour API et Persistence
API
EXTENSIONS
PERSISTENCE
EXTENSIONS
Authentication

40. gRPC
CQL
GraphQL Document
API
Data
API
Cassandra
3.x
Cassandra
4.x
Cassandra
DSE 6.x
API Extensions and Persistence Extensions

41. Comparing Stargate Apis
Cassandra Query
Language
GraphQL REST Document
SQL like Table Model
Structured Data
Key-Value Data
Strong Types
Minimal query overhead
Hierarchy of
types and fields
Structured Data
Key-Value Data
Low query overhead
Row based
Structured Data
Key-Value Data
Weaker Types
High query overhead
JSON Documents
Semi-Structured Data
Weaker Types
High query overhead
Drivers Open API
More Performant More Flexible
gRPC
Structured Data (CQL)
Lighter weight
Native driver alternative
Low query overhead

42. Ça c’était avant...
NODE
NODE
NODE
NODE
NODE NODE
NODE
developers
Apps
Drivers
CQL
CQL
CQL
CQL
CQL
CQL
CQL

43. Stargate
Stargate
Et maintenant, avec Stargate...
NODE
NODE
NODE
NODE
NODE NODE
NODE
developers
Apps
Drivers
CQL
CQL
CQL
CQL
CQL
CQL
CQL
Stargate
CQL

44. Stargate V2
Nouvelle
architecture
Distribution
des
Services

45. Agenda
● Apache Cassandra™: Rappels et cas d’usages
● Tour d’horizon des nouveautés 4.0 et 4.1
● En route vers Cassandra 4.2
● Stargate, une data gateway pour simplifier les développements
● K8ssandra pour des deploiements aisés en production
45

46. + =

47. Apache
Cassandra®
Cass-Operator

48. Apache
Cassandra®
Cass-Operator
Metrics
Collector

49. Apache
Cassandra®
Cass-Operator
Cassandra
Medusa
(backup/restore)
Metrics
Collector
📁S3, GCP,...
Repear
(repair)

50. Apache
Cassandra®
Cass-Operator
Cassandra
Medusa
(backup/restore)
Metrics
Collector
📁S3, GCP,...
Repear
(repair)
Stargate

51. K8ssandra with kube-prometheus-stack

52. Agenda
● Apache Cassandra™: Rappels et cas d’usages
● Tour d’horizon des nouveautés 4.0 et 4.1
● En route vers Cassandra 4.2
● Stargate, une data gateway pour simplifier les développements
● K8ssandra pour des deploiements aisés en production
52

53. DataStax: The Open Data Stack for Real-time Data
Data ecosystem
AI
Search
Analytics
Contact :
marc.blanquer@datastax.com
Applications
Multi-Cloud & Cloud-Native
Multi-region, Inter-cloud, Serverless
and K8S microservices based
Database as a service based
on Apache Cassandra®
Stargate APIs
REST, GraphQL, schemaless Document APIs, gRPC or CQL
Streaming service based
on Apache Pulsar®
Invisible operations
Infrastructure, Security, Scalability,
High Availability, Resiliency
CDC
Data sources
Web
Applications
IoT

54. Merci !
T-shirts Stand A36
@clunven