InfoQ était au JUG Summer Camp 2013 à La Rochelle, et j'y ai pu m'asseoir avec David Pilato pour discuter d'elasticsearch.
Simon Baslé pour InfoQ : David bonjour, pourrais-tu commencer par te présenter en quelques mots?
David Pilato : Donc je m'appelle David Pilato, j'ai travaillé dans différentes sociétés comme des sociétés de service en informatique, j'ai bossé chez SFR, dans le groupe Vivendi-Universal (toujours dans l'informatique), et puis pendant 8 ans j'ai travaillé pour la douane française, et dans le cadre de mes activités en douane j'ai découvert le projet elasticsearch que j'ai mis en place pour eux. Et du coup je suis tombé tellement amoureux de ce projet là que lorsque la société elasticsearch a été créée ça faisait complètement sens de rejoindre l'équipe, de participer au projet à temps plein. Et donc, c'est ce que je fait aujourd'hui. Je définis mon rôle comme "Technical Advocate", un rôle à la fois d'évangéliste et aussi de développeur, quand j'ai le temps entre deux conférences ou dans le train :). Aujourd'hui, je travaille moins sur le coeur d'elasticsearch, parce que je n'ai pas encore forcément le niveau de mes collègues qui ont des années et des années de search engine, de Lucene, etc... Donc je travaille plutôt sur la partie plugins, sur les parties interfaces, j'ajoute quelques fonctionnalités par-ci par là...
InfoQ : D'accord donc plutôt via le système de plugin que dans les arcanes de Lucene. Ok, alors si tu devais définir rapidement elasticsearch ?
David : Alors elasticsearch c'est un moteur de recherche, et qui dit moteur de recherche dit que c'est vraiment de la puissance brute en fait. Je dirais qu'il n'y a pas d'interface graphique livrée avec, quoiqu'on commence à voir émerger des petites choses dont on parlera sans doute tout à l'heure, mais donc ça veut dire que c'est un moteur qu'il faut adapter à ses besoins et au même titre que lorsque tu utilises une base de données, la base ne sait pas ce que tu vas stocker, dans notre cas, on ne sait pas du tout ce que tu va indexer dans elasticsearch. Il y a souvent des utilisateurs qui, lorsqu'ils démarrent elasticsearch, se disent "ok comment il va indexer les données de mon entreprise et où est l'interface graphique qui présente (je ne sais pas quoi, mes chambres d'hôtel, mes déclarations en douane ou que sais-je ?)". On ne sait pas ce que vous allez indexer, comment vous allez chercher et comment vous allez afficher les résultats. A vous donc d'exploiter la puissance du moteur.
Avec elasticsearch on est dans le monde NoSQL orienté documents, et ça tombe bien car on indexe ce qu'on appelle des documents, au sens large du terme, qu'ils soient structurés ou non. Elasticsearch est basé sur une bibliothèque merveilleuse qui s'appelle Apache Lucene. Cette bibliothèque, qui est développée en Java, est sans doute une des meilleures bibliothèques open-source (et voir même dans le monde close-source) et une des plus performantes. Elle a un inconvénient : elle est développée en Java. Ce n'est pas un inconvénient technologique ; ça n'est pas que le Java n'est pas bien. Au contraire ! Mais c'est juste que pour l'utiliser à partir d'autres technologies du style PHP, Perl, Python, .NET, etc... et bien ça devient un petit peu compliqué. Alors ce que va proposer elasticsearch, c'est d'ajouter des services au-dessus de Lucene et d'exposer l'ensemble des services fournis par Lucene à l'aide d'une couche HTTP/REST/JSon. Un des autres inconvénients de Lucene c'est qu'en fait il est limité quelque-part à la puissance de la machine sur laquelle il réside. On a une scalabilité verticale avec Lucene : on rajoute du processeur, on rajoute de la mémoire et Lucene va complètement en tirer les bénéfices. Par contre, lorsque l'on atteint les limites de la machine, on se retrouve bloqué. Ce que va rajouter elasticsearch, et c'est vraiment un de ses points forts, c'est une couche de distribution de vos données sur plusieurs noeuds, et donc proposer une scalabilité horizontale, qui va permettre de monter à des milliards et des milliards de documents sans difficulté.
Une dernière précision, elasticsearch c'est sous licence Apache2, donc facilement intégré, utilisé dans un système d'information, dans un projet commercial, partout où vous en avez besoin.
InfoQ :En parlant de cet aspect distribué, est-ce que tu peux nous décrire un peu les différents mécanismes qui rentrent en jeu dans la distribution, comment se passe la réplication entre les noeuds ? Est-ce qu'il y a du partitionnement, des noeuds maîtres ? Des limitations ?
David : Dans elasticsearch la distribution est assurée par le fait qu'on découpe ce qu'on appelle les index. Un index c'est un équivalent à ce qu'on pourrait trouver dans le monde relationnel sous forme d'un schéma de base de données en fait. Donc on va découper un index en plusieurs partitions, et chaque partition de cet index est une instance de Lucene. C'est comme ça qu'on va réaliser la distribution de nos données : c'est à dire qu'on va les distribuer sur tout un tas de petites instances Lucene qui vont elles être réparties sur différentes machines physiques. Ça c'est l'aspect découpage des données : le partitionnement.
Lorsqu'on envoie une donnée à l'indexation à l'un des noeuds du cluster, elasticsearch sait que par défaut il doit répliquer la donnée une fois dans le cluster. C'est évidemment des choses qui se configurent, on peut dire "j'ai besoin de répliquer 10x" ou "je n'ai absolument pas besoin de répliquer". Donc il y a une première partition Lucene qui va prendre la donnée, qui va l'indexer, vérifier que tout est conforme, etc... et dès que l'on aura fini cette opération primaire ce qu'elasticsearch va faire c'est de répliquer en parallèle sur l'ensemble des autres partitions (les replicas) et une fois qu'il aura atteint le quorum il renverra le résultat : il dira "c'est bon j'ai bien fait l'opération". Donc la réplication se fait en même temps que l'on fait l'indexation, avec une garantie pour l'utilisateur qui a envoyé sa donnée à indexer qu'à partir du moment où il a la réponse, il est sûr qu'elle a été répliquée même si le cluster s'arrête d'un seul coup, même si celui-ci n'a pas eu le temps vraiment derrière de complètement indexer la donnée, de toutes façons quand il va redémarrer il appliquera ce qu'il lui restait à faire.
A propos des noeuds maîtres, dans elasticsearch tout à été fait pour simplifier au maximum la vie des utilisateurs, des développeurs, des admins. Oui il y a la présence d'un noeud maître, et un seul, dans le cluster. S'il y en a plusieurs ça pose un problème, ça s'appelle le Split Brain et il ne faut absolument pas que ça arrive donc il y a des moyens en place pour éviter ce genre de choses... Il y a donc un noeud maître qui est chargé de prendre les décisions au niveau du cluster, mais on n'a pas nous à la main à définir qui est le noeud maître dans le cluster (on peut, mais par défaut le premier noeud par définition est maître, les autres noeuds qui arrivent deviennent esclaves). Si le noeud maître disparaît d'un seul coup (coupure volontaire ou crash par exemple) automatiquement il y a une auto-élection d'un autre noeud en tant que maître.
InfoQ : D'accord donc un mécanisme d'élection automatique... Et la tolérance à la panne sur le reste des noeuds, qui fait partie aussi de l'aspect distribué, comment est-ce géré ?
David : Exactement, le fait qu'on ait répliqué les données d'elasticsearch sur plusieurs machines fait que si un des noeuds qui contenait un certain nombre de données tombe, automatiquement elasticsearch est au courant que le noeud a disparu du cluster. Le noeud maître va justement prendre un certain nombre de décisions et va dire typiquement "maintenant je sais que les requêtes doivent être routées vers le noeud qui contient la partition répliquée" et en même temps elasticsearch va dire "il me manque du coup un nouveau réplica, ma donnée n'est présente qu'une seule fois dans le cluster", donc il va de lui-même rebalancer les shards et réajuster son cluster pour répondre à cet événement qui est la perte d'un noeud.
InfoQ : Une réplication de tout le contenu du shard à partir du moment où le noeud est tombé, qu'est ce que ça coûte ?
David: De la bande passante principalement, puisque si la bande passante est mauvaise la réplication peut être lente, et pendant ce temps de réplication si malheureusement on perd aussi le noeud qui contenait le dernier shard vivant là ça pourrait commencer à devenir problématique. Un des points sur lequel il faut vraiment avoir l'oeil quand on travaille avec elasticsearch c'est typiquement avoir une bonne connectivité réseau, une très bonne latence réseau. Aujourd'hui par exemple dans l'hypothèse de faire de la réplication multi-datacenter dans le monde, il ne vaut mieux pas utiliser la mécanique standard d'elasticsearch, parce que la latence réseau n'est pas suffisamment intéressante pour faire ces opérations de manière performante.
InfoQ : Et du coup il y a des possibilités de mettre en place des mécanismes alternatifs de réplication ?
David : Aujourd'hui on travaille chez elasticsearch pour la version 1.0 sur une API de snapshot/restore, l'idée étant de pouvoir à tout moment snapshoter un index sur filesystem, sur Amazon S3, sur Google Drive, etc... Et puis qui dit snapshot dit aussi restore, donc je suis capable de restaurer mon index ailleurs, dans un autre cluster, ou alors avec une autre configuration de mon index peut-être, ce qu'on appelle de nouveaux mappings... Et typiquement moi je vois bien çà pour faire un système de Disaster Recovery. En effet, dire que par défaut toutes les 15min je fais un snapshot de mon index et des nouveautés, et j'envoie ça ensuite à l'autre bout de la planète et je fais un restore là bas, donc au pire je vais perdre un petit peu de données. Ça n'est pas de la réplication synchrone mais ça sert de système de backup. Par contre on travaille, à beaucoup plus long terme, sur un mécanisme de cross-datacenter-recovery, qui à l'avenir nous assurera de pouvoir effectuer cette réplication de manière beaucoup plus synchrone et automatique, mais pour l'instant ça n'est pas quelque-chose qu'on a aujourd'hui, ce n'est pas quelque-chose que je conseillerais à nos utilisateurs que de dire "je vais faire cette réplication par elasticsearch". Ce que je ferais à la place de mes clients dans ce cas là c'est que je créerais deux cluster différents, un en Europe et l'autre en Asie par exemple, et quand j'indexe une donnée côté couche cliente et bien en fait je l'envoie à mes deux clusters, et là je gère cette problématique côté client.
InfoQ : Tu parlais donc de cette API REST par-dessus Lucene, est-ce que c'est une API qui reprend complètement celle de Lucene ? Est-ce qu'elle a été travaillée différemment pour apporter un peu de confort d'utilisation ? Quelles en sont les grandes lignes d'utilisation ?
David: C'est une bonne question. Un des éléments clés de cette API REST c'est qu'on ne parle qu'en JSON avec elasticsearch, donc les appels et les réponses d'elasticsearch sont en JSON. On expose la majorité des fonctionnalités de Lucene, mais en fait on expose beaucoup plus de fonctionnalités que ce que Lucene offre. Et globalement ce que vont faire les API c'est qu'elles vont être aussi capables de décider par exemple du shard vers lequel doit être indexé la donnée. Les instances de Lucene ne se connaissent pas entre elles, les Lucene ne sont pas fait pour communiquer entre eux, et donc ça va être une des décisions que vont prendre les API lors de la phase d'indexation : dans quel shard j'envoie ma donnée. L'intérêt de nos API c'est qu'elles masquent la complexité de persistance au développeur. Le développeur se connecte sur n'importe lequel des noeuds du cluster elasticsearch, qu'il ait ou non la donnée, et c'est le rôle des API de justement simplifier cet accès aux données, de simplifier l'accès au GET (je récupère un document si je connais son identifiant) ou au SEARCH (je veux exécuter une recherche qui va être distribuée sur l'ensemble des index Lucene).
Ce qu'on rajoute aussi c'est l'administration du cluster elasticsearch lui-même, la surveillance du cluster et toutes ces opérations très techniques en fait, elles sont aussi exposées sous forme d'API REST. Donc ça veux dire qu'on est capable de connaître à un instant t l'état technique d'un cluster, est-ce que par exemple en ce moment on a trop de fichiers ouverts sur notre filesystem ce qui risque de nous introduire des erreurs ? Voilà tout ça est monitorable sur le cluster elasticsearch, tout ça est exposé en REST au format JSON. Et on ajoute aussi des fonctionnalités supplémentaires au-dessus de Lucene, par exemple dans la version 0.90 on a sorti un API complète de suggestions, qui est un petit peu le Did You Mean? qu'on connait chez un grand moteur de recherche, et cette API de suggestion simplifie considérablement la vie du développeur parce qu'il n'a pas à se soucier de "je dois faire tel et tel type de requête dans mon index pour arriver à récupérer la suggestion", on simplifie et on apporte des services supplémentaires du point de vue fonctionnel.
InfoQ : Alors j'ai vu beaucoup dernièrement d'articles qui parlent de collecte et de recherche dans des logs, on associe beaucoup la stack Logstash et elasticsearch. D'ailleurs Logstash est maintenant encore plus associé à elasticsearch officiellement...
David : ...Oui puisque Jordan nous a rejoint en août effectivement...
InfoQ : Qu'est-ce qui fait de ce cas d'utilisation un cas aussi représentatif selon toi ?
David : Aujourd'hui ce que fait Logstash principalement c'est qu'il est dédié aux logs, et je dirais que c'est un bon point d'entrée pour nos clients qui des fois doutent un petit peu, se demandent si ça marche vraiment, et donc ils se disent "Tiens? Je vais tester avec mes logs de prod, aujourd'hui j'ai plein de machines, je sais pas quoi faire des tonnes de logs qu'elles crachent, ça serait peut-être bien que je récupère ces logs". Et pour ça, soit tu te fais toi-même un ETL et tu vas récupérer tes logs et essayer de transformer les dates (parce que suivant les différents produits les dates c'est juste l'enfer), soit tu utilises un truc qui est tout packagé qui s'appelle Logstash, et qui va pousser dans elasticsearch. L'intérêt pour nos clients c'est qu'ils ne prennent pas de risques, ce sont des données de prod mais pas des données business, et donc avec ça ils se rendent compte qu'ils arrivent à gérer des quantités énormes de données, et qu'ils arrivent surtout à leur donner du sens, à ces données...
Par ailleurs on a dans elasticsearch des fonctions d'analytics, au-delà du search. Donc non seulement on peut chercher des incidents, mais on peut essayer de trouver des moyens de corrélation. Bref, avec Logstash aujourd'hui on est très centré sur les logs, il va aller récupérer des informations sur les logs un petit peu partout. Mais en réalité ce qu'on est en train de faire aussi c'est dire que finalement on pourrait récupérer autre chose que des logs avec Logstash. On pourrait récupérer des flux Twitter, des flux Wikipédia, on pourrait récupérer peut-être quelque-chose qui vient d'une base de données relationnelle, ce genre de choses. C'est une mécanique qui aujourd'hui dans elasticsearch s'appelle les rivers en fait, c'est traité par le système des rivers qui permettent de faire tourner à l'intérieur d'elasticsearch, à l'intérieur des noeuds un composant qui va avoir ce rôle de récupération de données, de transformation et de déversement dans elasticsearch, mais c'est quelque-chose qu'on est en train de déprécier et ce au profit de Logstash... Donc de plus en plus, Logstash on va pouvoir le voir comme quelque-chose qui récupère de la donnée quelque part, qui la transforme comme il faut et qui la charge dans elasticsearch, et surtout de façon efficace, parce que le problème des rivers c'est qu'elles ne sont pas scalables, elles ne tournent que sur un seul noeud du cluster. Et en plus elles introduisent quelque chose que nous ne trouvons pas très bien c'est que potentiellement elles peuvent dégrader le cluster. Elles passent leur temps à faire quelque chose qui est de la collecte et de la transformation de données, qui n'est pas le coeur de métier d'elasticsearch.
Et donc l'idée de Shay Banon, l'auteur d'elasticsearch, est de dire que les rivers sont des greffons qu'on met dans elasticsearch mais qui n'ont pas de sens métier par rapport aux fonctionnalités qu'on veut offrir comme coeur de métier, donc c'est très bien de mettre ça à l'extérieur et dans un process autonome qui lui, est scalable, peut tourner sur plusieurs machines, être capable de monter en charge et d'indexer beaucoup beaucoup plus de données qu'aujourd'hui avec les rivers. Donc, on travaille sur cette transition, et c'est vraiment quelque chose qui va je pense arriver dans le domaine de Logstash, qui ne sera du coup plus seulement dédié aux logs, au même titre que elasticsearch n'est pas que dédié au search...
InfoQ : Toujours dans le cadre de cette recherche de logs, il y a cet outil qui a émergé c'est Kibana, pour la visualisation de toutes ces données, pour l'agrégation...
David : Exactement! Alors il se trouve que là au JUG Summer Camp je vais faire une présentation liée qui a pour titre "Make Sense of your (Big) Data!". Un petit mot d'abord sur le BigData, auquel on associe souvent elasticsearch, et souvent j'insiste sur le fait que elasticsearch est tellement pratique et facile à mettre en oeuvre pour les utilisateurs que ça peut aussi concerner le small Data. Donc n'ayez pas peur, utilisez-le dans tout les contextes, que ce soit Big ou pas vous pouvez l'utiliser parfaitement.
Et ce qu'on a repéré chez nos utilisateurs c'est que souvent ils collectent de la donnée, ils mettent ça dans des filesystems, ils mettent ça dans des bases de données (relationnelles ou pas), dans différents moteurs NoSQL qui existent sur le marché, ils mettent ça dans de l'Hadoop, tout un tas de technologies comme ça... Mais ils ont du mal à leur donner du sens à toutes ces données, ils ont du mal à extraire de l'information intéressante pour eux, et surtout ils ont du mal à le faire en temps réel ou quasi-réel. Et ce qu'on veut faire avec elasticsearch, c'est justement de permettre à nos utilisateurs de donner du sens à leurs données. Pour ça, on va leur permettre d'envoyer et de récupérer leurs données d'où qu'elles proviennent, que ce soit comme j'ai dit de différentes bases de données ou même d'elasticsearch qu'importe, et à l'aide de fonctionnalités qui s'appellent les facettes (qui sont en train de devenir les agrégations), de faire parler les données. Et le projet Kibana, historiquement, avait été développé au dessus de Logstash en Ruby. L'auteur de Kibana, Rashid Khan, a rejoint elasticsearch en janvier 2013, et quand il nous a rejoint il a complètement migré Kibana, vers une version qui s'appelle Kibana3 en fait, et qui est maintenant du full AngularJS, qui se connecte à elasticsearch, et qui permet surtout de fabriquer son dashboard comme on a envie de le fabriquer au moment où on a envie de le fabriquer. C'est à dire qu'on est pas limité à un dashboard fixe et particulier, vous avez un incident de prod à un moment sur des serveurs et bien vous voulez aller voir tel et tel type de données, essayer d'aller fouiller dans la donnée pour voir d'où vient à peu près le problème et bien vous allez pouvoir construire votre dashboard, faire des histogrammes de dates, faire des camemberts qui représentent la source, est-ce que c'est un problème PHP, un problème de Java ou que sais-je encore... Et donc vous allez réussir à naviguer dans vos données.
Ça peut s'appliquer à n'importe quel domaine, ça n'est plus que des logs, tout comme je disais Logstash va être capable de récupérer plus que des logs, et bien Kibana moi aujourd'hui je l'utilise typiquement dans mes démos pour faire de l'analyse marketing. Mon marketing à un instant t a envie de voir qui utilise mon service le plus, ou qui est le plus intéressé par tel et tel domaine comme la mode... J'avais collecté tout un tas de données sur mes utilisateurs et je vais leur donner du sens avec ça. Et puis tout d'un coup je suis le marketing, je décide aussi de collecter les identifiants de compte sociaux de mes utilisateurs, type Twitter ou Facebook, ou le nombre d'amis qu'ils ont sur Facebook par exemple, j'ajoute cette donnée dans mon ensemble NoSQL, je l'envoie dans elasticsearch et en tant que marketing je vais être capable d'ajouter çà à mon dashboard, et de créer mon propre dashboard quand j'en ai besoin, sans mise en prod lourde. Et c'est super dynamique, et encore une fois le gros gros intérêt c'est que c'est en temps quasi-réel, il y a à peu près 1sec de latence par défaut entre le moment où vous envoyez la donnée à l'indexation et le moment où elle devient analysable, et là on n'a pas besoin de faire tourner des processus pendant des jours et des jours pour extraire de la donnée et faire de la statistique.
InfoQ : D'accord, donc on peut avoir des graphes temps-réel, faire de l'analyse, et tout ça avec une interface graphique vraiment impressionnante en plus!
David : Oui c'est un très très bel outil, vraiment bien fait, et ce couple Kibana-Logstash je pense qu'il nous emmène vers des choses très très intéressantes pour nos utilisateurs à long terme.
InfoQ : Du coup un bel avenir pour Kibana, Logstash dans les prochaines versions avec ces gros changements, il y a d'autres fonctionnalités à venir pour elasticsearch ? Une roadmap que tu serais habilité à nous dévoiler ?
David: Alors la roadmap en fait on est en train de travailler dessus concrètement, parce que c'est une demande qui revient très souvent. On peut regarder la liste des issues dans GitHub mais bon, généralement quand on est DSI c'est une démarche un peu trop fastidieuse. Donc on va publier prochainement une roadmap claire et nette pour nos utilisateurs sur l'avenir d'elasticsearch à deux, trois ans. Les choses à court terme qui vont arriver c'est surtout pour la version 1.0, on va travailler sur les API de snapshot et restore dont j'ai parlé tout à l'heure, on va travailler sur un nouveau système de percolation aussi. La percolation c'est de la recherche inversée en fait. Imagine ça comme envoyer des alertes automatiques en cas d'événements qui seront indexées dans elasticsearch par exemple, ou pour de la classification d'information : est-ce que telle info est plutôt politique, économique, etc... quand je traite des informations télé... Aujourd'hui on a déjà une API de percolation mais on n'avait pas pensé qu'elle prendrait aussi bien, que nos clients s'en serviraient de façon aussi intensive. Aujourd'hui on sait qu'elle est limitée, au sens où elle n'est appliquée que sur un seul des noeuds, et donc la scalabilité de la percolation n'est quand même pas extraordinaire. Donc certains de nos clients, qui ne se servent d'elasticsearch que pour faire de la percolation, commencent à voir des limites. Et Martijn Van Groningen, qui est un de nos collègues et aussi un committer Lucene par ailleurs, a refait complètement la percolation pour la rendre hautement scalable.
Donc ça ça fait partie des nouveautés qui arriveront, l'autre élément que l'on va ajouter dans la version 1.0 c'est la refonte complète de ce qu'on appelle les facettes. Les facettes dont je parlais précédemment, c'est l'élément dont se sert énormément Kibana aujourd'hui. C'est l'agrégation de contenu, pour donner du sens à ses données, faire des histogrammes de dates sur des champs, faire un top ten des valeurs qu'on va trouver dans tel et tel champs, ce genre de choses. Et ça on est en train de refondre complètement, on va déprécier les facettes au profit de quelque-chose qu'on appelle désormais les agrégations, qui vont permettre typiquement de faire des facettes composables les unes entre les autres, et faire ainsi des facettes de facettes de facettes... On peut faire des facettes hiérarchiques, donc par exemple "donne moi la répartition par date de naissance de mes utilisateurs et pour chacune des années trouvées, dit-moi combien j'ai de pourcentage d'hommes et de femmes". Ou l'inverse, "donne-moi le pourcentage d'hommes et de femmes que j'ai, et donne moi la distribution par âge de chaque genre". C'est ce qu'on va pouvoir faire, et coupler ça avec des calculs statistiques sur d'autres champs, "et en plus donne moi le nombre moyen d'enfants qu'ils ont", ce genre de choses... Donc ça ça va être très très sympa parce que ça va aussi rendre beaucoup plus flexible le système des facettes et permettre à nos utilisateurs d'encore décupler la puissance de ce qu'ils peuvent faire avec les analytics sur elasticsearch. J'en profite pour dire que c'est Uri Boness, co-fondateur d'elasticsearch, qui a montré lors du dernier meetup elasticsearch France qui s'est tenu à Paris en début de semaine que ça fonctionnait très bien, et donc c'est vraiment quelque-chose qui est très très proche d'atterrir dans la master branch d'elastiscsearch et qui sortira avec la version 1.0. Voilà pour moi ce sont les trois points à noter importants, et après j'ai cité rapidement le fait qu'on allait essayer de travailler sur la réplication multi-datacenter à l'avenir, je pense que c'est des choses qui vont arriver à plus long terme. Mais la roadmap sortira prochainement, officiellement, et là je pense qu'on aura beaucoup plus d'informations à communiquer sur le sujet.
InfoQ : Très bien! Pour terminer, des petites astuces personnelles / choses à rajouter ?
David : Oui je voulais insister sur deux éléments, parce qu'après tout je vais en profiter pour faire ma pub - rires -. On a une communauté francophone qui est vraiment excellente, on est la communauté localisée dans le monde la plus forte, on a des meetups qui sont toujours complets avec 80-100 personnes, donc c'est vraiment exceptionnel, même lorsque l'équipe d'elasticsearch, les gens qui sont au Pays-Bas ou ailleurs, viennent en France et assistent à nos meetup ils sont à chaque fois émerveillés de voir à quel point ça prend bien ici en France. Ça se voit, ça se traduit dans le nombre de downloads d'elasticsearch, on va bientôt atteindre les 4 millions de download au total pour le produit, ce qui est énorme pour un projet technique comme ça, un très gros succès. Et on voit que le téléchargement depuis la France, dans nos statistiques, qu'on est le 1er ou le 2ème pays peut-être derrière les Etats-Unis, mais vraiment une très forte communauté. Donc j'encourage les gens qui vont lire cette interview à s'inscrire à notre compte Meetup.com, le compte elasticsearchFR, et de venir assister aux événements, partager leurs retours d'expérience avec nous, on avait vraiment de très très bons talks la dernière fois aussi, donc vraiment venez nombreux!
A propos des astuces sur elasticsearch je dirais qu'il y a un plugin que j'aime beaucoup, qui a été fait par l'un de mes collègues à Amsterdam, Boaz Leskes, qui s'appelle Sense. C'est un plugin que tu peux mettre dans Google Chrome typiquement. Il va te permettre de t'aider à fabriquer tes queries, de les exécuter facilement, tu as de l'auto-complétion derrière, donc en tant que développeur ça peut être très très pratique à utiliser, éviter d'écrire tout le JSON...
Voilà, faites-vous plaisir, découvrez le projet si vous ne le connaissez pas encore, allez-y !
InfoQ : Merci beaucoup David pour cet échange!
David: Avec plaisir!