Kit Wai Chan - Fotolia
DataStax repense l’architecture des index pour optimiser Cassandra
DataStax a dévoilé la disponibilité de Storage Attached Indexing pour la base de données NoSQL Cassandra. Cet ajout attendu de longue date doit simplifier l’exécution de requêtes à grande échelle et optimiser la consommation des ressources.
La nature des bases NoSQL oblige les éditeurs (et les communautés open source) à mettre en place des moyens pour accéder rapidement aux données. Apache Cassandra est originellement accompagnée de deux sortes d’index par famille de colonnes.
L’index primaire contient les clés de partitionnement qui déterminent l’emplacement des données sur un nœud d’un cluster. Les index secondaires (2i) doivent permettre d’effectuer des recherches sur des tables qui ne sont normalement pas accessibles d’une simple requête parce qu’elle ne fait pas référence aux clés contenues dans l’index primaire. Ils sont construits sur les valeurs des colonnes.
« En d’autres termes, disons que vous avez une table qui contient les adresses email d’utilisateurs. L’index principal serait l’identifiant de l’utilisateur, donc si vous voulez accéder à l’adresse d’un utilisateur particulier, vous pouvez le rechercher par son identifiant. Cependant, pour résoudre la requête inverse – entrer l’adresse pour récupérer l’ID de l’utilisateur – il faut un index secondaire », explique Harrison Dahme, ingénieur logiciel sur le site de son ancien employeur Pantheon.
Des index secondaires complexes à utiliser
Seulement les index secondaires, qui permettent des requêtes rapides semblables à celles accessibles dans MongoDB ne sont pas sans conséquence sur les performances, quand un index est construit sur une colonne qui contient beaucoup de valeurs différentes. Une requête réclamera autant de lecture qu’il y a de tables réparties sur les nœuds d’un cluster.
Multiplier cette approche à l’échelle provoquerait des goulets d’étranglement au niveau des passerelles API. Pour augmenter les performances, des entreprises comme Pantheon ou le cabinet de conseil londonien Outworkers ont choisi de « dénormaliser » les index primaires, de les personnaliser, afin d’ajouter plusieurs éléments interrogeables depuis les colonnes.
En vue d’améliorer les index secondaires, Datastax a développé un nouveau framework nommé Storage Attached Indexing (SAI). Celui-ci permet de définir un ou plusieurs index « à n’importe quelle colonne ou famille de colonnes, et pour presque tous les types de données Cassandra, y compris les chiffres, les textes et les collections de documents », relate la documentation de DataStax. Cela doit permettre de filtrer les requêtes en utilisant les commandes CQL equality, range (pour les données numériques uniquement) et CONTAIN.
Les Index SAI sont disponibles dans DataStax Enterprise 6.8.3 et dans la version managée DataStax Astra. Ils fonctionnent de la même manière sur l’une ou l’autre version. De même DataStax a effectué une proposition (Cassandra Enhancement Proposal CEP-7) pour l’intégrer dans la version open source de la base de données NoSQL.
Storage Attached Indexing « élimine bon nombre de ces compromis, rendant le développement et la modélisation des données dans Apache Cassandra plus faciles à utiliser, tout en augmentant la stabilité et les performances et en donnant aux architectes et aux opérateurs moins de pièces détachées à gérer », considère Ed Anuff, chef de produit chez DataStax, dans un communiqué de presse.
Premièrement, la gestion des index secondaires serait simplifiée ainsi que les configurations de Solr ou d’autres moteurs de recherche par-dessus la base de données. Deuxièmement, cette technique permettrait de réduire l’utilisation des disques durs.
Selon les expériences de l’éditeur, 10 index avec un milliard de lignes pèsent 37,9 Go, contre plus de 276 Go avec des index secondaires classiques. Le débit serait 43 % supérieur en comparaison avec ces derniers et la latence serait abaissée de 230 % en écriture. En lecture, ces deux mesures seraient légèrement meilleures, selon DataStax. Les index SAI apparaissent également comme des remplaçants tout trouvés aux index DSE Search, à la traîne selon le même tableau.
« SAI est également entièrement compatible avec une fonctionnalité connue sous le nom de streaming sans copie. Cette fonctionnalité permet lors du démarrage ou de l’arrêt des nœuds dans le cluster que les index soient entièrement diffusés en continu avec les SSTables, et ne soient pas sérialisés ou reconstruits à l’extrémité du nœud récepteur », écrivent les responsables techniques de DataStax. SAI reste toutefois optionnelle, et les autres méthodes d’indexation sont toujours disponibles.
Les entreprises dans le viseur… et AWS
Les gains de performances s’expliqueraient par le fait qu’à l’instar de l’index primaire, un index Storage Attached Index réside au même nœud que la table à laquelle il est associé. À l’inverse, les index 2i peuvent perdre la synchronisation avec l’index primaire et toute l’architecture associée n’est pas efficiente, des aveux de DataStax dans la proposition CEP-7.
Cette annonce succède à celle de la disponibilité de la DbaaS Astra et du Cass Operator, un opérateur Kubernetes pensé pour s’adapter à toutes les distributions de Cassandra. L’éditeur poursuit sa phase de simplification du SGBD, en améliorant les performances et en luttant contre l’image de l’objet technique très efficace, mais difficile à maintenir que se traîne Cassandra depuis plusieurs années.
Surtout, DataStax veut maintenir sa proximité avec la communauté open source, pour mettre AWS (et ses autres concurrents) dans le rétroviseur. Pour rappel, le géant du cloud avait présenté sa propre version managée et serverless de Cassandra en décembre 2019. In fine, DataStax veut attirer les entreprises avec une solution de plus en plus taillée pour leurs usages. Reste à voir si cela se vérifie dans la réalité.