KoDe Software accélère vos requêtes Tableau… pour commencer

Pour tout vous avouer, j’avais eu l’occasion d’interviewer Michel Koskas en février 2013. La société s’appelait alors Vivamens. A son grand dépit, je n’avais rien publié suite à cette entrevue… car je n’avais pas compris grand chose. Docteur et Normalien en mathématiques, inventeur d’algorithmes, Michel Koskas avait bien tenté de se mettre à la portée d’un cancre comme moi… sans y parvenir. Soit il est vraiment trop Normalien, soit je suis vraiment trop cancre. Il a fallu que Bruno Saint-Cast, s’intéresse à cette entreprise, et me propose une interview croisée pour que je sois en mesure de partager cet article avec les lecteurs de Decideo.

S’il jouait au baseball, Bruno Saint-Cast s’appellerait plutôt Sandy Koufax. Lanceur d’entreprises pour le premier, de balles pour le second. Car après Brio Technology, Salesforce.com, Tableau Software et d’autres encore, Bruno Saint-Cast a souvent su dénicher de bons poulains. Et justement, s’il est totalement inconnu dans le monde du baseball, il est plutôt reconnu dans l’élevage de chevaux de course. Dans le civil, au volant d’un camion/écurie/hôtel sur mesure, il sillonne la France pour présenter ses protégés. Il a donc deux vies, qui se résument en une seule, sélectionner, faire grandir et encadrer jusqu’à ce que ses entreprises et chevaux, aient gagné leur indépendance. Il passe alors à la génération suivante. Son dernier poulain informatique s’appelle Kode Software.

Michel Koskas : Je viens du domaine de la combinatoire des mots, une branche de l'informatique théorique qui n'a aucune connexion avec les bases de données. Les champs académiques sont très disjoints les uns des autres. Certains concepts ne sont pas passés entre le domaine de la combinatoire des mots et celui des bases de données, et inversement. Nous avons bien entendu breveté notre technologie, aux États-Unis, au Canada et en Europe. De plus, nous n’avons pas tout mis dans notre dépôt de brevet, pour conserver confidentielles certaines de nos recherches. La structure de données que nous avons amélioré s’appelle les « radix trees (arbres radix) » ou « tries », qui sont décrits dans la littérature scientifique depuis plusieurs décennies. Mais la forme de « tries » que nous utilisons ne figure pas dans la littérature scientifique. Elle permet de décrire des données tout en étant proche du microprocesseur pour que les calculs soient efficaces. Bien sur, nous ne sommes pas à l’abri que quelqu’un d’autre fasse la même chose, ou même quelque chose de mieux.

Bruno Saint-Cast : Michel est trop modeste. Le risque que d’autres chercheurs parviennent au même résultat est extrêmement faible. D’une part, parce que les spécialistes des arbres radix du niveau de Michel Koskas dans le monde, se comptent sur les doigts d’une main; et que le croisement des compétences avec les bases de données est encore plus rare ! Par ailleurs nous ne travaillons pas que sur les « radix trees ». Ils ont donné matière à plusieurs algorithmes, mais nous avons deux autres travaux en cours, le « data lift » et la dé-corrélation.

Michel Koskas : Lorsque l’on décrit les données à l’aide de cette structure de données, le temps de résolution des requêtes SQL est proportionnel à la taille du résultat, indépendant du volume des données. Cette caractéristique est unique à notre structure de données, et elle explique déjà un partie du gain de performance. Le deuxième point est la résolution des jointures : Dans une base de données relationnelle, les jointures sont un problème épineux à résoudre. Lorsqu’une requête fait intervenir plusieurs tables, on créé entre ces tables, cet espèce de plat de spaghetti que sont les jointures. A tel point qu’on dénormalise presque toute la base de données, avec des schémas en étoile ou en flocons. Cela présente de nombreux inconvénients, comme une énorme inflation du volume des données; les modifications deviennent extrêmement complexes à mettre en oeuvre. De plus, les données s’éloignent du schéma mental de l’utilisateur, puisque tout est centralisé dans une table de faits.
Dans Kode, nous avons imaginé un « ascenseur » entre les tables; le « data lift » qui permet de passer d’une table à l’autre, sans dénormaliser la base de données. On peut avoir un nombre illimité de jointures dans une requête.
Dernier point, nos algorithmes de résolution de problèmes complexes : prenons l’exemple d’une vue avec une autre vue imbriquée. Du point de vue informatique, c’est une requête avec une sous-requête corrélée, qui se résout habituellement par une boucle. Nous avons créé des algorithmes de décorrélation des sous-requêtes, qui nous permettent de les résoudre sans boucle. C’est dans ce cas, que nous obtenons les ratios de performance les plus spectaculaires. C’est le cas également pour les produits cartésiens avec agrégats. Nous avons développé des algorithmes très rapides. Par exemple sur un test TPC-H contre HP Vertica, nous avons obtenu le résultat 4000 fois plus rapidement : sur le produit cartésien entre deux tables, respectivement de 6 millions et 1 million de lignes, Kode résout le problème en 4 secondes, lorsque Vertica a besoin de 4 heures pour la même tâche.
Notre ratio de performance augmente même avec la taille des données, et avec la complexité des requêtes. Sur de petites bases de données et des requêtes simples, nous ne ferons pas mieux que nos collègues :-)
Mais dès que l’on a des requêtes un peu complexes, des jointures, ou des volumes de données un peu importants, en général, les ratios augmentent très rapidement.

Bruno Saint-Cast : Pour atteindre ces performances, nous utilisons en moyenne dix fois moins de ressources CPU que nos concurrents, et nous utilisons moins de mémoire centrale. Autre point important, nous sommes quasiment aussi rapides qu’une base de données relationnelle dans les mises à jour. Alors que les bases de données en colonnes sont habituellement beaucoup moins performantes que les bases relationnelles, quand il s’agit de faire des modifications de données.

Bruno Saint-Cast : Nous nous plaçons dans la tendance de la Business Intelligence en livre service. Et les requêtes lancées par les utilisateurs en libre service sont généralement très complexes. Les requêtes « ad-hoc » produites auparavant par des outils comme Cognos ou Business Objects, limitaient les choix de l’utilisateur à quelques paramètre pré-établis. L’ensemble était optimisé en back-office par des administrateurs de bases de données. Aujourd’hui en jouant à glisser-déplacer des tables, des champs, des jointures, l’utilisateur peut produire, sans s’en rendre compte, des monstres de complexité. En consommant dix fois moins de ressources, l’installation de Kode peut donner un véritable souffle à des installations existantes.
Enfin, tout cela est totalement automatisé. Des bases comme Sybase IQ totalisent 9 systèmes d’indexation différents. Chez Kode, un seul système d’indexation répond à tous les besoins. Nos systèmes s’installent en 5 minutes, avec zéro administration, et zéro optimisation.

Bruno Saint-Cast : Pas plus que Tableau Software n’était positionné dans la catégorie de Business Objects ou Cognos. Je crois que nous apportons quelque chose de nouveau, qui a d’ailleurs été reconnu par plusieurs spécialistes du domaine, dont Claude-Henri Meledo, directeur de Aldecis, qui estime que nous créons le segment du « self-service analytical database » ou « query booster ». Nous pouvons passer inaperçus en nous installant sur le poste de travail de l’utilisateur, en accélérant tout simplement ses requêtes sans qu’il ait de systèmes compliqués à installer en mémoire. Si c’est pour une communauté d’utilisateurs, Kode peut être installé sur un ou plusieurs serveurs. Nous avons dans ce cas, volontairement, choisi un positionnement de « boite noire ». Bien sur nous pouvons remplacer un Sybase IQ, HP Vertica ou Actian VectorWise, mais ce n’est pas notre objectif premier. Nous sommes en effet capables de reprendre les règles de gestion des bases de données que nous accélérons. Nous accélérons simplement les requêtes qui nous sont soumises. Mais nous pouvons également devenir la principale base de données analytique, d’un entrepôt de données que l’on voudrait extrêmement performant.
Prenons un exemple. Nous avons parmi nos clients EnvoiMoinsCher.com, un comparateur de prix dans le domaine du transport de colis. Ils utilisent VectorWise et l’ont déjà bien optimisé. Ils ont installé Kode - l’installation sur 5 serveurs a pris en tout moins de 5 heures - et ont immédiatement constaté une division par deux des temps de réponse aux requêtes. Ce n’est « que » une division par deux, car ils ont des requêtes déjà très optimisées par leurs DBAs, mais l’ont obtenue sans aucun réglage spécial de Kode. Kode a d’ailleurs par la suite remplacé VectorWise chez eux.

Bruno Saint-Cast : SAP HANA est une technologie en colonnes et en mémoire, comme Kode. Mais nous pouvons jouer entre les différents supports. Nous savons accélérer aussi bien en mémoire que sur disque. Il faut pour faire fonctionner SAP HANA des ressources mémoire extrêmement importantes. Nous ne nous sommes pas encore comparés à SAP HANA, mais nous devrions apporter les mêmes niveaux de gain.

Bruno Saint-Cast : La réponse est clairement oui, mais nous ne pouvons pas adopter un positionnement aussi large que cela. Nous n’avons pas toutes les fonctions d’administration, de contrôle d’accès, de sécurité, de redondance, qu’une base de données comme Microsoft SQL Server ! Ce n’est pas l’axe que nous souhaitons développer aujourd’hui.

Michel Koskas : Mais Kode propose un outil de synchronisation avec les bases de données relationnelles. On peut donc faire une importation initiale, sélectionner certaines tables, et leurs mises à jour sont répercutées automatiquement dans Kode, à la volée. Autre amélioration que nous avons apporté; les index ne se dégradent pas avec le temps, il n’est pas nécessaire de les récréer régulièrement comme dans d’autres bases de données. Nous avons fait le test entre une base de données Oracle et Kode et nous avons constaté que le temps de synchronisation des opérations entre les deux bases était toujours inférieur à 4 secondes, même lorsque l’on submergeait la base Oracle de mises à jour.

Bruno Saint-Cast : cette fonction est très intéressante pour les clients qui voudraient se rapprocher d’une analytique en temps réel. Nous pouvons atteindre le quasi-temps réel, à très haute performance.

Bruno Saint-Cast : Je suis un utilisateur Tableau. Je commence à expérimenter quelques ralentissements dans l’accès à mes données. Cela devient de plus en plus fréquent, au point que la dernière annonce de Tableau 9 a été très focalisée sur la performance. Je peux télécharger une version individuelle de Kode, Kode Desktop. En cinq à dix minutes, l’outil aura répertorié les classeurs Tableau, puis « disparaitra ». C’est à dire que nous avons vocation à accélérer les requêtes de l’utilisateur sans que ce dernier n’ait à manipuler un logiciel supplémentaire. Il va simplement constater une accélération de 20 à 60 fois sur les temps de traitement de ses requêtes.
Le prix d’achat est de 200 euros par utilisateur, puis 50 euros par an et par utilisateur. Le prix moyen d’une licence Tableau est de quelques centaines de dollars. Nous pensons que la fonction d’accélération peut se positionner autour de 20 % du prix de la licence Tableau. Mais c’est un revenu en partie récurrent puisque l’utilisateur doit payer un abonnement de 50 euros par an pour le droit d’usage, la maintenance et le support.
Ensuite nous avons Kode Server. Là encore nous avons calculé le prix par rapport au prix de Tableau Server. Kode Server coûte donc 50 000 euros pour l’achat (sur un processeur 8 coeurs), puis 12 500 euros par an d’abonnement.

Michel Koskas : Pour expliquer un peu plus comment cela fonctionne; les classeurs Tableau sont au format XML. Nous lisons les schémas et créons un menu qui permet de sélectionner, si on le souhaite, les schémas que l’on souhaite accélérer. Si l’utilisateur souhaite accélérer un schéma, nous le dupliquons et créons le même schéma « Powered by Kode ». Les données sont dupliquées sur le serveur Kode, accélérées grâce à nos index, et à chaque lancement de Tableau, l’utilisateur sélectionne le schéma qu’il souhaite utiliser, l’original ou celui « Powered by Kode ». On ne touche bien entendu pas aux données Tableau, mais on duplique le morceau de XML dans le classeur Tableau qui concerne le ou les schémas que l’utilisateur veut accélérer.
Par ailleurs nous travaillons sur une version “cloud” de Kode. Nous travaillons avec Bittle, un éditeur français de BI en cloud, et nous avons intégré notre solution dans le cloud sans aucun problème. Kode Server pourrait dès demain être installé dans un centre de données comme Amazon. Nous devons juste améliorer les procédures pour automatiser encore plus l’installation.

Bruno Saint-Cast : Oui, la version boite noire s’installe et se configure automatiquement. Mais selon Claude-Henri Meledo, cela devrait au contraire être un régal pour les intégrateurs, parce que c’est une brique de plus dans l’architecture, et ils vont pouvoir apporter leur valeur ajoutée sur le paramétrage des lieux de stockage (disques, mémoire…). Il a trouvé qu’il y avait pas mal de fonctions avec lesquelles jouer pour apporter une valeur ajoutée à ses clients.

Bruno Saint-Cast : notre stratégie commerciale est, comme celle de Tableau, fondée sur la vente à distance. Avec un produit à 200 euros par utilisateur, il n’est pas possible d’aller voir chaque client individuellement. Notre structure commerciale sera très proche de celle de Tableau, sur les entreprises moyennes et sur les grands comptes. Nos forces sur le terrain seront plutôt focalisées sur les marchés de l’intégration (OEM). Nous sommes en discussion avec d’autres éditeurs de logiciels de BI, et ils semblent très intéressés. Nous travaillons déjà avec des intégrateurs comme Micropole, qui nous confirment qu’il y a sur Tableau un vrai problème de temps de réponse avec le développement de la « business discovery ».
Notre organisation commerciale sera très décentralisée. Notre centre d’appels sera peut-être dans quelques années à Barcelone, où on trouve les bons profils, mais pas à Londres où la tension est trop forte. Dans un premier temps nous allons gérer les ventes beaucoup en direct, et à distance, avec des partenaires dans des pays critiques comme la France, l’Allemagne ou l’Italie si nécessaire.