Cassandra vs ScyllaDB - Partie 1 : Les prétentions

Vincent Heng , Baptiste Sagazan 13 mai 2019

Introduction

Une fin d’après-midi ensoleillé, alors qu’on prenait un Datapéro* avec les collègues, quelqu’un a posé cette question fâcheuse :

« Est-ce que vous connaissez une autre base de données colonne que Cassandra ? »

Question fâcheuse, déjà, parce qu’on était concentrés à trouver qui avait mangé la dernière chips.

Question fâcheuse, ensuite, parce qu’on ne trouvait pas la réponse à une question si évidente. C’est vrai, on entend souvent Java vs C#, AWS vs GCP, Windows vs Linux, Nintendo vs Sony, mais Cassandra vs… ?

Image 1 : Google autocomplétion sur le thème : cassandra vs ...

Les 9 premiers résultats ne sont pas vraiment des bases de données colonne, au mieux des bases de données clés-valeurs. Hbase on connait mais on n’est pas vraiment fans donc on l’omet ici, et voilà qu’apparaît timidement le nom de ScyllaDB.

Ah, mais je connais ScyllaDB ! C’est une base de données colonne migrable de manière transparente depuis Cassandra, bien plus rapide et utilisée par personne.

Il y a quelque chose qui cloche dans ta phrase… Enquête.

Ecosystème

Il était une fois ScyllaDB...

ScyllaDB ça vient d’où ? Pourquoi on n’en parle pas plus ? Deux questions tout à fait pertinentes. L’histoire de ScyllaDB commence en décembre 2014 par une startup du nom de Cloudius Systems. Cette startup spécialisée dans le développement d’applications C++ est à l’origine de deux projets :

OSv : un OS conçu spécialement pour le cloud permettant de simplifier les stacks utilisées par les VM. C’est une application open source sous licence Apache.
Seastar : un framework C++ que l’on retrouvera dans ScyllaDB (spoiler alert!). Il promet notamment :
un networking plus performant en laissant de côté la stack Linux, par l’utilisation de l’intel DPDK qui permet d'accélérer le processing de packet.
Une amélioration des communications entre threads au sein du CPU en limitant les “Locking operations”.
La mise en place d’une architecture Shared-nothing (chaque noeud est alors indépendant et autonome dans l'exécution des tâches) permettant une meilleure scalabilité horizontale.

Fort de ses deux précédentes expériences, Cloudius Systems devient ScyllaDB inc. et lance en 2015 ScyllaDB, une base de données open source sous licence Apache, distribué NoSQL orienté colonne faisant directement concurrence à Cassandra. Mis en avant par ses concepteurs comme étant Cassandra mais en C++. Le challenger supporte les mêmes protocoles (CQL, thrift), formats de fichier (SSTable) et peut être facilement interverti avec sa grande soeur.

Des arguments forts...

Par l’utilisation de leur framework maison Seastar et de son architecture Shared-nothing, il devient possible de séparer le jeu de données à processer sur les différents coeurs. Dans cette organisation, les coeurs ne partagent pas la donnée ou la mémoire et les interactions entre coeurs sont donc minimisées. S’associe à cela l’utilisation d’un système asynchrone pour gérer ces interactions, évitant ainsi les opérations bloquantes. Cela permet à ScyllaDB inc. d’annoncer : ”qu’il est nécessaire pour Cassandra d’avoir un cluster 10 fois supérieur en taille pour obtenir des résultats équivalents.”

Cassandra et ScyllaDB peuvent être interchangés. Cette affirmation est peut-être un peu exagérée, néanmoins il est possible en suivant une procédure décrite sur la documentation de ScyllaDB (ici) de bel et bien passer d’un cluster Cassandra à un cluster ScyllaDB. C’est une opération coûteuse en temps mais qui ne nécessite pas, selon la documentation, une indisponibilité du service lors de la migration. En effet, le cluster Cassandra est progressivement remplacé, dans un premier temps en écriture, puis ensuite en lecture.

Mais une visibilité réduite

La promesse semble trop belle pour être vraie ; si un outil si performant existe pourquoi n’est-il pas plus mis en avant ? De nos jours, il est impensable d'utiliser une technologie avec une communauté peu active. D’autant plus lorsque la technologie est open source, cela devient même un facteur de choix lors d’un benchmark. Et ici encore ScyllaDB ne manque pas d’arguments, tout d’abord de nombreux grands clients soutiennent et mettent en avant la solution : Samsung SDS (La branche IT de Samsung) avec un benchmark impressionnant disponible ici. AppNexus, Mogujie, Outbrain, Kenshoo, Olacabs, Investing.com, Eniro, IBM’s Compos pour ne citer qu’eux. Les retours sont unanimes. La solution ScyllaDB propose des performances excellentes même avec les paramètres d’usine, en comparaison au modèle Cassandra qui nécessite d’être optimisé pour en tirer les meilleurs résultats.

Test de popularité sur le sacro-saint Stack Overflow : c’est ici que les choses se compliquent pour ScyllaDB. En effet, l’outil est quasiment absent de la stack. Là où Cassandra tourne autour de 0,10% du total de questions sur le mois et HBase oscille vers 0,5%, ScyllaDB ne représente même pas assez de questions pour être présent dans les trends. Serait-ce dû à une documentation si limpide qu’elle ne laisse pas place aux questions ou bien à une quasi non-utilisation de l’outil hors des grands groupes partenaires ?

Image 2 : Graphe de tendance sur Stack Overflow des tags : Cassandra et HBase, ScyllaDB n’étant pas présent

Une offre triple

Outil open source, ScyllaDB possède une offre community permettant à chacun d’utiliser le service gratuitement. La limitation de l’offre community est sur le nombre de noeuds disponibles (5) pour leur manager de cluster.

Il y a donc en parallèle deux offres disponibles moyennant finance :

Enterprise, qui propose tout d’abord de pouvoir manager un nombre illimité de clusters par le biais de leur Scylla Manager, et l’accès à un support 24/7. Le pricing quant à lui n’est pas fixe, il est nécessaire de faire une demande au service pour qu’ils évaluent la donnée et qu’ils conviennent d’un prix.
Cloud, basé sur AWS : Scylla inc. propose également un service managé de leur solution. Celui-ci est optimisé pour les machines i3 de chez AWS et il ne semble pas qu’il y ait la possibilité d’utiliser un autre cloud provider. En ce qui concerne la tarification pour une machine, voici la tarification en location à l’heure et pour une réservation annuelle :

Type	Amazon ($)	ScyllaDB ($)	Total ($)	Estimated Monthly price ($)	Estimated Annual price ($)
i3.large (hourly)	0,156	0,174	0,330	240	2891
i3.large (Annual reserved)	0,107	0,105	0,212	155	1860

Performance

Maintenant que nous avons une idée de l’offre que propose ScyllaDB, comment expliquent-ils une telle amélioration de performance vis-à-vis de son concurrent direct ?

L’équipe marketing ne sourcille pas : un lien vers leur benchmark est disponible sur leur page d’accueil. Ils nous promettent des performances jusqu’à 10 fois supérieures ainsi qu’une réduction des coûts de serveurs de 2,5 fois sur AWS par rapport à un cluster Cassandra.

2.5X reduction in AWS EC2 costs

Applications using Scylla can perform 10x better and are more reliable

La différence majeure entre Cassandra et ScyllaDB, comme nous le disions plus tôt, c’est le langage utilisé. Cassandra est développée en Java et ScyllaDB en C++. Calmez-vous, on ne parle pas du vieux débat de problème de performance dont souffrait Java avant 1997 et qui entache sa réputation depuis.

Ici, c’est concret : le garbage collector de Java a du mal à gérer les grosses quantités de RAM. Par exemple, pour une machine de 256 Go de RAM il est recommandé pour l’utilisation de Cassandra de limiter le HEAP SIZE à 64Go (Documentation Cassandra). Ce n’est pas un problème en soi car la RAM n’est censée contenir que le tas c’est à dire le contenu des variables. En cas de besoin supplémentaire, il est recommandé d’utiliser un système de cache externe, et c’est là que ça coince.

Une sombre histoire de cache…

Il serait extrêmement lent de lire sur disque à chaque requête sur base de données. Pour optimiser les temps de réponse, Cassandra et ScyllaDB gardent en cache les partitions les plus souvent requêtées (il est désactivé par défaut sur Cassandra mais il reste une bonne idée pour augmenter les performances). Pour rappel, un accès RAM est 50 à 500 fois plus rapide qu’un SSD avec une connectique en PCIe. Ceci étant, en production il est impensable de laisser tourner toute l’infrastructure sur une unique machine. Le réseau devient alors plus limitant que les accès disques.

ScyllaDB utilise un système de Row cache. C’est simplement un tableau associant l’ID de la partition recherchée à la partition.

Pour Cassandra, c’est un système Key cache + Page cache.

Le key cache, stocké dans le tas (RAM allouée à Java), est un tableau associant l’ID de la partition à sa position dans le page cache. Géré nativement par le système d’exploitation, le page cache contient les partitions sous forme de SSTables (Sorted String Tables), une suite de String clé-valeur triés.

Image 3 : A gauche la gestion du cache de Java et à droite celle de ScyllaDB

En déléguant la gestion de son cache au système d’exploitation, Cassandra allège la taille de la RAM à allouer à sa JVM. Cependant, en utilisant un gestionnaire de cache extérieur, la JVM doit sérialiser les objets avant de les mettre en cache, et les désérialiser en sortie, processus qui semble être coûteux.

C’est tout ?

Conceptuellement, ScyllaDB apporte quand même 2 optimisations majeures. La première, c’est l’indépendance des threads. En effet, comme abordé en première partie de cet article, chaque thread se partage un morceau de la mémoire et n’a jamais besoin de communiquer avec les autres threads grâce à l’architecture “Shared-nothing”.

La deuxième optimisation se fait côté réseau. L’utilisation du Data Plane development Kit permet d’améliorer la vitesse de traitement des packets.

Et maintenant ?

ScyllaDB est un challenger agressif face à Cassandra. Par sa compatibilité avec l’existant et ses optimisations techniques, l’outil espère convertir ~~la fanbase~~ les utilisateurs de Cassandra.

La plupart des chiffres évoqués durant cet article ont été avancés par ScyllaDB. Bien qu’ils donnent la méthodologie de benchmark de manière totalement transparente, mon scepticisme couplé à mon 6ème sens d’araignée me poussent tout de même à vouloir vérifier ces affirmations utopiques. Ainsi, préparez-vous dans un prochain article à un benchmark maison des chiffres avancés par ScyllaDB.

En attendant, santé !

* Deux mots sur les Datapéros

Chez Ippon on aime la data et les apéros, du coup on s’est dit pourquoi ne pas mélanger les deux ? Le nom était tout trouvé : les “Datapéros”. On y discute régulièrement de sujets data trendy autour d’un verre. C’est lors de l’un de ces rassemblements, que l’idée de cet article est née.