InfoQ FR : Bonjour Jean-Claude et Edouard, pouvez-vous commencer par vous présenter ?
Jean-Claude Tagger : Bonjour je m'appelle Jean-Claude Tagger, je suis un des deux associés dirigeants de QuasarDB, je viens plutôt du monde des grandes entreprises de l'informatique. Entre autres, j'ai été le Directeur Général de Dell France, Président de Nec pour l'Europe, j'accompagne depuis 2008 un certain nombre de startups éditeurs de logiciels et quand j'ai rencontré QuasarDB, j'ai été conquis, jusqu'à y investir et maintenant à m'y consacrer à plein temps.
Edouard Alligand : Edouard Alligand, je suis informaticien, j'ai environ 15 ans d'expérience. Je suis à la base programmeur noyau sous FreeBSD Windows. Depuis 2008, je suis un impatrié car j'habitais en Allemagne. J'ai fondé QuasarDB en France et j'ai commencé à travailler sur ce qui est actuellement le moteur, nous avons réussi notre première vente fin 2013 et nous avons réalisé notre premier tour de table en juillet 2014 pour 1 million de $. Nous sommes en pleine expansion grâce à notre moteur révolutionnaire.
InfoQ FR : Justement, est-ce que vous pouvez présenter la solution QuasarDB ?
Edouard Alligand : QuasarDB est une base de données distribuée pair-à-pair qui a été conçue avec deux impératifs : la performance et aucun spof (single point of failure). Philosophiquement, on est dans une approche où on est là pour répondre à des nouveaux types de problèmes et certainement pas concurrencer les bases de données relationnelles qui font déjà très bien beaucoup de choses. En fait, on est là pour répondre à "j'ai énormément de données en vrac, je n'ai pas vraiment de schéma ou celui-ci n'a pas de sens, et je souhaite manipuler ces données. Je souhaite le faire sans contraintes, rapidement et de manière souple". Eventuellement après dans mon SI, j'ai derrière d'autres bases de données relationnelles, ou d'autres types de bases orientées document, orientées graphe. Mais avant tout, QuasarDB est une sorte de lac de données dans lequel je mets tout et je peux faire des manipulations extrêmement rapides, et surtout je veux des garanties fortes sur la manipulation des données, c'est à dire que quand je vais faire des manipulations sur mes données, je n'ai pas à me préoccuper de savoir s'il y a des problèmes de cohérence, de disponibilité. Si la base de donnée me répond "oui", c'est que c'est bon. Si elle me répond "non", c'est que j'ai eu un petit problème technique et je sais récupérer l'erreur.
InfoQ FR : Est-ce que vous pouvez décrire l'architecture de QuasarDB ?
Edouard Alligand : L'architecture est du pair-à-pair, basé sur l'algorithme Chord du MIT. Cela combine le meilleur des deux mondes : du maître esclave et du pair-à-pair. C'est à dire que toutes les opérations sur la base sont ACID et en revanche, on est vraiment distribués dans le sens ou vous pouvez accéder à la base à partir du moment où vous avez au moins un noeud up.
InfoQ FR : Et en termes de modèle de données ?
Edouard Alligand : Le modèle est double. Le premier est le modèle clé/valeur : vous identifiez votre donnée par une clé. Vous pouvez faire un ensemble d'opérations sur ces clés, par exemple vous pouvez de manière atomique récupérer une valeur et la mettre à jour, faire du compare and swap, etc. Et surtout on a le principe des tags, car la clé/valeur c'est quand même un peu juste pour faire des recherches. Il n'y a pas d'histoire d'indexation, car pour nous c'est une technologie qui est autre (qu'on peut plugger sur Quasar si nécessaire). Vous prenez votre donnée, vous pouvez lui attribuer un nombre d'étiquettes et après vous êtes capable de faire des recherches à partir des étiquettes. C'est exactement le principe de Twitter où vous allez pouvoir mettre des tags et récupérer tout sur ces derniers. Imaginez que vous avez des capteurs matériels qui enregistrent dans Quasar, vous pouvez mettre des étiquettes selon l'emplacement physique de vos capteurs et par ordre chronologique de vos capteurs, et si vous voulez rapidement récupérer l'ensemble de toutes les données d'un tel capteur par jour, simplement en récupérant les étiquettes vous pouvez le faire. L'avantage de cette approche : cela scale parfaitement, extrêmement rapide et extrêmement souple. On reste dans la philosophie du non-schéma. Vous mettez des étiquettes, vous pouvez changer d'avis, les modifier a posteriori, en rajouter. Il n'y a pas de limites, toujours ce principe de "scalabilité infinie", pas de limite logique, la seule limite que vous ayez est matérielle - et souplesse extrême, puisque si vous commencez à faire du schéma, c'est peut être que vous avez besoin d'une base de données relationnelle. C'est vraiment "vous mettez tout en vrac, vous pouvez faire des manipulations et des traitements élaborés dessus, vous pouvez faire du Hadoop dessus mais vous gardez votre lac de données flexible".
InfoQ FR : Quelles sont les forces et les faiblesses de votre solution, par rapport à Redis par exemple, qui est également une solution clé/valeur ?
Edouard Alligand : La seule faiblesse que l'on a, c'est un peu moins de richesse au niveau des types, mais cela va être corrigé. Il est vrai qu'avec Redis, vous avez la possibilité d'énormément de richesse. Mais si vous prenez la liste de toutes les faiblesses de Redis, ce sont nos forces. Redis est mono-threadé avec une duplication qui est quand même extrêmement rudimentaire, choix technique de son fondateur, Antirez, qui a clairement dit ne pas vouloir se prendre la tête avec le multi-threading quand il a commencé à concevoir Redis. Nous, on a fait exactement l'inverse, on a voulu résoudre ce problème difficile. Donc on est en scale-up et en scale-out. D'ailleurs, on a des prospects qui utilisent Redis et qui en sont arrivés au bout car ils sont obligés de faire les scaling à la main, et ça ce n'est pas acceptable. Redis est une base de données extrêmement ludique et souple, mais en revanche elle ne scale pas du tout, ni en up, ni en out. Nous on le fait, et le scale-out veut aussi dire qu'il n'y a pas de problème de taille de donnée, de volume de base. De plus, on est hot plug and play, c'est à dire que quand votre base est saturée, vous rajoutez un noeud, elle grossit, ce qui est impossible avec Redis. Et nous tournons sous Windows et ceci de manière native.
InfoQ FR : Sur quelles plate-formes tournez-vous et quels sont les langages supportés ?
Edouard Alligand : Nous tournons sur FreeBSD, Windows et Linux. Et nous sommes en train de faire un port Mac OS, qui est surtout utile pour le client. Concernant les lagages supportés : PHP, C, C++, Java, .NET et Python.
Jean-Claude Tagger : On a fait le choix d'être ouvert. C'est notre architecture qui est notre propriété, et le reste au contraire, on veut s'interfacer avec tout ce qui existe, c'est pour ça que l'on a la plupart des langages.
Edouard Alligand : Après, rajouter une API c'est envisageable. Nous sommes éditeur, il y a donc un vrai support. Si un client arrive avec un problème, on sait le résoudre. Notre équipe est composée de 7 personnes en interne qui constitue la R&D. Pour reprendre la philosophie, l'activité de QuasarDB il n'y en a que deux : c'est vendre le logiciel et concevoir le logiciel.
Jean-Claude Tagger : Pour tout le reste, on utilise des experts ou des meilleurs outils qui existent.
InfoQ FR : Petite question technique, le sharding est-il un sujet abordé ?
Edouard Alligand : Oui, c'est automatique. En fait, c'est l'algorithme Chord qui résoud ce problème. Le sharding se fait entrée par entrée, chaque noeud est élu maître d'une donnée, donc c'est là où vous avez la cohérence. Mais chaque donnée est maîtrisée par un noeud différent, du coup vous avez un balancing automatique. Et si vous rajoutez un noeud, vous avez une migration automatique. Quand je parle de rééquilibrage, qui est le gros point faible des consistent hashing comme nous, pour nous cela dure rarement plus d'une minute et une minute c'est catastrophique. Si vous prenez Cassandra, les migrations peuvent durer 3 jours. Cela veut dire que vous mettez un noeud et c'est 3 jours plus tard que le balancing est terminé. Pour nous, 1 minute c'est vraiment catastrophique, ou alors ce qui peut se passer c'est que vous avez 100 Go à faire transiter et dans ce cas là, nous ne sommes pas magiciens.
InfoQ FR : Et en termes de CAP, sur quels éléments avez-vous choisi d'optimiser ?
Edouard Alligand : C'est là où nous avons été très malins. Le CAP nous dit qu'à un instant t, seulement 2 des 3 contraintes peuvent être garanties, mais rien ne vous empêche de changer au fil du temps. Donc selon le contexte, on va être un des deux. On est plutôt consistant et available. En général, quand on a un doute, on sacrifie le partitioning, car dans un contexte de data center, le partitioning, c'est déjà que vous avez un problème catastrophique. Mais on sait résister à certains scénarios de partitioning, du coup en n'étant pas available et en répondant au client une erreur. Mais pour nous, ce qui est important au delà du CAP, c'est de toujours donner au client une réponse qui lui permette de faire des choses cohérentes. On a des types d'erreur où on lui dit "là, on est en train de se stabiliser, réessaie plus tard", et donc à la charge du client selon le contexte de dire "finalement je laisse tomber car je n'ai pas besoin tant que ça de la donnée" ou "je réessaie plus tard". Et on a le choix surtout de ne jamais décider à la place de l'utilisateur.
InfoQ FR : Quasar est maintenant disponible sur le Cloud. Quels ont été les facteurs de décision quant au choix de la plateforme Azure ?
Edouard Alligand : Cela peut s'expliquer par le fait que l'on a toujours eu une certaine proximité avec Microsoft. Puis ils ont été extrêmement proactifs et nous ont beaucoup aidé pour le faire. On a plus l'impression d'être les bienvenus qu'autre chose.
Jean-Claude Tagger : Oui, c'est vraiment ça. Ce ne sont pas des aspects techniques - même si c'est très bon - mais c'est vraiment la facilité de travailler avec eux.
Edouard Alligand : Après, on pense aussi que c'est une plateforme qui est en pleine expansion et qui a de l'avenir. Et vu qu'on supporte Windows, c'est également un facteur qui est entré en compte. Si les gens sont sous Microsoft, et étant donné que l'on supporte l'environnement, on a toutes les raisons d'être sur cette plateforme.
InfoQ FR : Aujourd'hui, qu'en est-il du mode d'hébergement de vos prospects clients ?
Edouard Alligand : Quasar, c'est un peu actuellement le private cloud, c'est à dire en cloud chez le client.
Jean-Claude Tagger : Oui pour l'instant. Maintenant on lance Azure, mais c'est vrai que nos premiers clients étaient dans le domaine de la finance de marché et c'est évidemment là qu'on voit les avantages. Par exemple, dans un cas de calcul de risques de marché où on va aller manipuler des données qui peuvent être très grossess, les benchs des clients ont bien montré qu'on était les seuls à tenir. C'est donc un des points importants, le format taille est un gros différenciateur.
A l'opposé de l'excellence dans l'écriture des programmes, c'est une base qui est très frugale. On peut donc même tourner sur des objets connectés. Ce sont des capteurs qui remontent de l'info sur une base centrale. Cette base peut être "embedded" ou résidente dans des objets connectés, plus ou moins intelligents. Cette particularité n'a rien à voir avec Azure - bien qu'il pourrait être le collecteur - en tout cas, on a des cas de figures qui sont assez intéressants, par exemple en domotique entreprise.
Edouard Alligand : De plus, Quasar consomme moins de mémoire et moins de disque que la plupart des bases. Donc, quand vous êtes dans du cloud et que vous payez au volume, cela a un gros intérêt.
InfoQ FR : Concernant Azure, quels services utilisez-vous déjà ?
Edouard Alligand : Actuellement, on est en VM Depot. On a une VM qui est gratuite d'utilisation pour les évaluations, qui est limitée à 1 noeud, ce qui permet aux gens de découvrir l'API et la plateforme. Et on est en train de travailler pour être dans le market place, les gens pourront mettre les instances Quasar dans leur machine virtuelle. Mais, pour le moment, on a juste cette VM qui vient d'être publiée.
InfoQ FR : Quelle est la road map à court terme ?
Edouard Alligand : Transaction et enrichissement par des types à la Redis. Quand je dis transactions, ce sont les vraies transactions ACID, on est pas dans le relationnel. Le but est vraiment de répondre au besoin "je veux faire plusieurs opérations en même temps et avoir une garantie de cohérence entre celles-ci". Le code est quasiment fini.
Le second point, c'est l'enrichissement par les types plus évolués. On va offrir comme dans Redis la possiblité au client de mettre des List et des set. C'est un vrai besoin que l'on a en interne pour les tags. Et nous allons égalemet sortir une versions 100% compatible Memcache, une version purement cache, sans persistance et les gens pourront l'utiliser en lieu et place de Memcache et bénéficier de la fiabilité du scale-up de Quasar, ce qui n'est pas le cas de Memcache qui ne scale-up pas.
InfoQ FR : Souhaitez-vous ajouter quelque chose ?
Jean-Claude Tagger : Oui, sur le fait que notre positionnement n'est certainement pas de remplacer les bases de données relationnelles. Nous sommes en complément, pour des cas d'usage qu'elles ne savent pas traiter. Nous ne sommes pas en mode "on va faire une base qui fait tout". On s'intègre à l'existant, et ceci grâce à tout ce qu'on a dit précédemment : le fait qu'on ait les APIs pour tous les langages et qu'on travaille dans tous les environnements.
InfoQ FR : Merci Edouard et Jean-Claude d'avoir répondu à nos questions !