In-memory : Aerospike optimise ses index secondaires

Partenariat avec Starburst, croissance d’Apache Spark : Aerospike muscle son jeu

Ces mécanismes étaient réclamés de longue date, à en croire les discussions sur les forums de l’éditeur. Pourquoi maintenant ? En juin, Aerospike a conclu un partenariat avec Starburst, le principal contributeur derrière Trino (ex-PrestoSQL). Ensemble, ils ont conçu la couche de traitement Aerospike SQL by Starburst. Celle-ci doit faciliter l’exécution de requêtes SQL massivement parallèles par-dessus la base NoSQL. De plus, beaucoup de clients grand compte de l’éditeur semblent utiliser la base de données en corrélation avec Apache Spark.

« Avant la version 6.0, les requêtes liées à un index secondaire ne pouvaient être parallélisées qu’au niveau du nœud. Cela signifiait que si un cluster avait 40 nœuds, les connecteurs Spark et Presto (Trino) ne pouvaient effectuer les traitements sur 40 workers », écrivait Ronen Botzer, directeur produit chez Aerospike, en avril dernier. « Comme nos clients utilisent en production des clusters Spark comportant des milliers de cœurs, il était inacceptable que la grande majorité d’entre eux restent inactifs, c’est pourquoi ces connecteurs n’ont pas implémenté de support pour les requêtes d’index secondaire ».

Avec la version 6.1 présentée à la fin du mois d’août, les clients de l’édition entreprise ont un avantage supplémentaire, selon l’éditeur. Les index secondaires sont désormais stockés dans la mémoire partagée du système Linux sur lequel repose le SGBD, tout comme les index primaires. Cela permet de prendre en charge les redémarrages à chaud. Auparavant, leur présence avait tendance à ralentir la mécanique de redémarrage rapide de cette édition. À titre d’exemple, ce « fast restart » permet de recharger un nœud contenant 1 milliard d’enregistrements en 10 secondes au lieu de 40 minutes.

« Cependant, lors d’un arrêt et d’un redémarrage complet du nœud, tous les index secondaires doivent être reconstruits par un scan », prévient Ronen Botzer.

Une indexation en profondeur des documents JSON

De plus, avec la version 6.1, Aerospike adapte ses index secondaires et ses mécanismes de requêtes aux collections de documents JSON.

Pour rappel, Aerospike peut accueillir différents types de données de par la structure de son data store. Au lieu de baser son modèle de données sur les relations entre les tables, l’éditeur a pensé un modèle de données clé-valeurs qui s’adapte aux trois techniques de stockage suivant la fréquence d’accès aux données : en mémoire vive, en NVMe flash ou en mémoire persistante.

Pour cela, il s’agit de configurer des conteneurs Namespaces en leur attribuant un nom, une politique de rétention, de durabilité et un moteur de stockage. Chaque enregistrement contenant une clé d’identification, des métadonnées et des bacs (bins) est placé dans un namespace spécifique. Ensuite, dans un namespace, les enregistrements peuvent être regroupés dans des conteneurs logiques optionnels, des Sets.

Auparavant, les index secondaires et les scans étaient définis optionnellement au niveau du namespace, mais ils étaient configurés pour accélérer les requêtes au niveau d’un Set. Désormais, si un index secondaire n’est pas rattaché au nom d’un Set, il peut s’appliquer à l’ensemble du contenu du namespace. Cela implique pour les usagers de vérifier et/ou de reconfigurer leurs index secondaires existants. D’ailleurs, le nom d’un index secondaire ne peut plus dépasser 64 caractères. Ces décisions doivent « permettre d’aligner le fonctionnement des index secondaires sur celui des index primaires ».

Logiquement, des index secondaires spécifiques doivent assurer un niveau de performance supérieur. Néanmoins, il faut que les API et les outils tiers puissent les exploiter. Ainsi, l’éditeur a ajouté une commande pour obtenir des statistiques concernant la cardinalité de chaque index secondaire. Cette fonction sera utilisée par le connecteur Trino, Aerospike SQL et le connecteur Spark à des fins de planification et d’optimisation des traitements.

Les bins, eux, contiennent les données et leurs types. Un enregistrement peut contenir plusieurs bins. Chaque bin contient un type de données distinct. Dans Aerospike, il existe deux grands types de données : les données scalaires (String ou Integer) et les collections de types de données (Collection Data Type ou CDT). Les CDT peuvent contenir des listes (List, par exemple des séries temporelles), des cartes (Map) ou encore des données géospatiales (GeoJSON).

« Les CDT sont un surensemble de JSON, qui prend en charge un plus grand nombre de types de données comme éléments de la collection, tels que les entiers pour les clés Map et les données binaires pour les valeurs List », précise la documentation d’Aerospike.

Auparavant, les index secondaires ne pouvaient être bâtis que sur les clés de premier niveau d’une structure de données Map. « Cette méthode est généralement utilisée pour indexer les champs de premier niveau des documents JSON stockés sous forme de Maps dans Aerospike », indique l’éditeur.

Aerospike 6.1 fait sauter cette limitation et permet d’indexer les documents dans toutes leurs profondeurs. L’accès aux documents doit être accéléré, à une condition près.

« Cela permet aux développeurs d’accélérer les requêtes pour les documents où le prédicat est mis en correspondance avec des éléments imbriqués à des profondeurs arbitraires », commente Ronen Botzer.

Régler différents problèmes de performance

Dans la même veine que le redémarrage à chaud, Aerospike a également revu son mécanisme de réplication inter datacenter, XDR.

En l’occurrence, les clients et l’éditeur ont remarqué un problème lors du déclenchement du mode de récupération, du rembobinage d’un namespace à partir d’une dernière mise à jour (LUT) ou de la réhydratation d’un cluster.

« Dans la version 6.1, nous avons optimisé le chemin du code de récupération - réhydratation en réduisant le nombre de threads alloué par nœud et donc la contention liée aux verrous. »

Si le réseau subit des ralentissements à cause d’un pic de consommation ou qu’il dysfonctionne, les phénomènes de contention liée aux verrous peuvent se multiplier. Ceux-ci se produisent quand de trop nombreuses opérations d’écriture et de lecture s’exécutent simultanément sur une même partition.

« Dans la version 6.1, nous avons optimisé le chemin du code de récupération/réhydratation en réduisant le nombre de threads alloué par nœud et donc la contention liée aux verrous. Il en résulte une amélioration significative des performances », écrit Ronen Botzer.

Sur Gartner Peer Insights, les utilisateurs louent les performances du SGBD NoSQL, mais évoquent des coûts importants en licence et en équipements ainsi qu’une complexité supérieure par rapport aux autres produits disponibles sur le marché.

La feuille de route présentée en mai vise à résoudre certaines de ses difficultés. L’éditeur compte adapter son SGBD et les librairies associées pour les exécuter sur des instances équipées des processeurs ARM et Graviton 3 d’AWS dès la version 6.2, en sus d’un mécanisme de restauration ponctuelle (point in time recovery). La 6.3 devrait se positionner dans la continuité de la 6.1 puisque les index secondaires pourront être stockés au choix sur des disques flash NVMe ou de la mémoire persistante.