Apache Cassandra 4.0 débarque sous le signe de l'observabilité

Renforcer la supervision d’Apache Cassandra 4.0

Parmi les nouvelles fonctionnalités de Cassandra 4.0, dévoilée le 26 juillet, figurent les tables virtuelles, qui fournissent une table de base de données définie par une API, plutôt que d’utiliser les SSTables ordinaires.

Les tables virtuelles servent en premier lieu à exposer les métriques à travers le langage de requêtes Cassandra (Cassandra Query Language ou CQL) ou les informations de configuration comprise dans un fichier YAML. Pour le moment, ces tables sont immuables : elles ne peuvent être « altérées, abandonnées ou tronquées ». Une fois les données enregistrées, il n’est possible que de les lire. Chaque table virtuelle découle d’une interface de keyspace virtuel. Dans une base NoSQL, un keyspace est un objet qui rassemble des familles de colonnes.

La fonction Virtual Table dispose de deux keyspaces (system_virtual_schema et system_views) spécifiques comprenant trois tables qu’il ne faut pas modifier. Ces tables ne sont pas non plus répliquées et dépendent uniquement d’un stockage local, sur un noeud particulier. Les tables virtuelles peuvent contenir des informations sur le cache, les clients connectés à la base, la latence de lecture et d’écriture, l’utilisation du disque, etc. Avec quelques ajustements (et un détournement manifeste de son usage premier), cette capacité pourrait très bien servir à associer un protocole de type blockchain avec Cassandra.

La journalisation complète des requêtes (Full Query Logging ou FQL en VO) est une autre nouveauté. Elle permet aux administrateurs de la base de données d’obtenir tous les logs des requêtes provenant des requêtes CQL. FQL apporterait en premier lieu une meilleure gestion des performances. Plus spécifiquement, cette fonctionnalité serait « utile pour la capture du trafic en direct, ainsi que pour sa relecture », selon la documentation.

Cet outil est d’abord pensé pour « débugger le trafic des requêtes et la migration », évaluer les performances ainsi qu’auditer les requêtes CQL. Et comme le logging peut être gourmand en ressources, la communauté a prévu des options de limitation du heap et d’espace disque dur occupé pour empêcher les erreurs d’allocation de mémoire. L’impact sur la latence des requêtes serait réduit par l’écriture asynchrone des logs sur un thread. FQL est accessible depuis nodetool, un outil disponible via l’API JMX (Java Management Extensions) ou par le biais d’un manifeste YAML (cassandra.yaml) avant de l’activer avec nodetool.

Comme le suggèrent les extensions de fichiers utilisés, Cassandra repose en grande majorité sur du code Java. Pour l’instant, Java 8 est la version du framework supporté sur le long terme. Prochainement, Java 11 bénéficiera du statut LTS (actuellement, son usage en production n’est pas recommandé), alors que les itérations 9, 10, 12 et 13 ne seront pas prises en charge à long terme. L’information est à prendre avec de grosses pincettes au vu de la gestion complexe de ce SGBD, mais les benchmarks réalisés par des employés de DataStax et présentés dans une vidéo en décembre 2020 prédisent que l’adoption de Java 11 permettrait d’améliorer « de 25 à 85 % » le débit et la latence de Cassandra.

Cassandra 4.0 vue par un utilisateur

La société d’évaluation immobilière Clear Capital, basée à Sacramento, en Californie, utilise actuellement Cassandra gérée par Instaclustr comme couche de données, un composant « critique » pour sa plateforme d’évaluation immobilière.

Larry Robinson, directeur technique de Clear Capital, explique que la plateforme de l’entreprise est un système de données « à forte intensité », stockant environ 2 milliards d’évaluations dans Cassandra qui doivent être indexées et analysées à la demande. Un seul nouveau client des services financiers peut se traduire par 100 000 prêts supplémentaires en un mois, ce qui implique d’interroger constamment un grand volume de données.

« Cassandra, dans sa version open source pure, est tout à fait capable d’atteindre nos objectifs en matière de performances », affirme Larry Robinson. « Nous avons constaté que nous disposions de l’évolutivité et des performances nécessaires pour fournir de manière fiable à nos clients des informations analytiques sur le marché de l’immobilier et continuer à progresser en toute confiance. »

En ce qui concerne spécifiquement Cassandra 4.0, M. Robinson a déclaré qu’il était particulièrement enthousiaste à l’idée d’essayer les tables virtuelles. Il a noté qu’au lieu de recourir à Java Management Extensions pour accéder aux paramètres et aux métriques dans Cassandra, les tables virtuelles permettent d’interroger directement ces informations, ce qui améliore la gestion et les opérations de la base de données.

Des fonctionnalités tournées vers la sécurité

La fonction de tables virtuelles est également l’un des points forts de la mise à jour de Cassandra 4.0 pour Stefan Miklosovic, participant au projet Cassandra et ingénieur logiciel senior chez Instaclustr. Il s’attend à ce que les tables virtuelles soient populaires parce qu’elles sont spécifiques à chaque nœud de base de données et offrent une meilleure visibilité sur les métriques de ce nœud particulier.

En outre, Stefan Miklosovic s’est intéressé aux capacités d’audits et FQL d’Apache Cassandra 4,0, car elles apportent une nouvelle visibilité aux opérations du SGBD qui peuvent être importantes pour la sécurité.

« L’audit et la journalisation complète des requêtes sont des fonctionnalités cruciales et indissociables dont il faut disposer pour se conformer aux politiques d'audit et de sécurité dans de nombreuses organisations », déclare-t-il.

Par ailleurs, dans la vidéo de présentation de Cassandra 4.0, Patrick McFadin, contributeur à Cassandra et developer advocate chez DataStax, précise que la communauté a corrigé 1098 bugs et erreurs.

Prochaine étape, accélérer la reprise d’activité

Outre une optimisation du protocole de messagerie internœud, cette quatrième version doit améliorer le streaming. Dans l’architecture Cassandra, le streaming est un « processus utilisé par les nœuds d’un cluster pour échanger les données sous forme de SSTables ». Cette capacité sert principalement à réparer les tables, remplacer les hôtes, étendre un cluster ou encore l’amorcer.

Aussi, les responsables du projet ont substitué le modèle de streaming de message séquentiel par Apache Netty, un framework non bloquant (non blocking I/O) permettant d’accélérer la restauration des nœuds en cas d’échec. « Cela réduit considérablement les problèmes de performance liés à la signalisation, à la coordination et au changement de contexte des threads », écrivent les ingénieurs d’InstaClustr. Il s’agit de « débloquer » une fonction nommée « Zero Copy Streaming » permettant l’échange d’une table entière au lieu de la diviser et de l’envoyer sous forme de partitions. Là encore, les gains promis sont conséquents.

Enfin, pour les « experts de Cassandra » (la documentation de la base open source détaille les compétences requises) qui aiment tester les « nouvelles choses », la fonction expérimentale Transient Replication (ou réplication transitoire en français) doit limiter la surcharge de stockage tout en augmentant la redondance des données. Dans cette architecture, des nœuds qui répliquent totalement les données côtoient d’autres nœuds qui ne contiennent que les données « non réparées » pour les mêmes tokens associés au protocole de répartition. Quand un nœud dédié à la réplication ne peut plus recevoir les données non réparées, elles sont provisoirement répliquées sur les nœuds de réplication transitoire, puis renvoyées vers le bon nœud une fois réparées, et supprimées de leur espace de stockage éphémère. À l’avenir, les responsables de cette proposition comptent la rendre accessible « à une plus large audience » de développeurs.

Selon les contributeurs principaux, Apple, Netflix, Orange, Yelp, Instaclustr ou encore Sky UK utiliseraient déjà Cassandra 4.0 en production. Reste à savoir si les usagers plus modestes adopteront cette mouture.