Un chtijug élastique

D’abord, quelques annonces

A 20 € ! Ca va être dur de faire valider la note de frais.

Pour les slides, c’est par là

Elastic, c’est 4 projets open-source :

  • Logstash (malheureusement écrit en JRuby)
  • Beats (alternatives à Logstash en go beaucoup plus simple). il y a FileBeats, NetworkBeats, MetricBeats
  • Elasticsearch (moteur d’indexation et de recherche JSON. Ne loupez pas l’interview de notre speaker chez lescastcodeurs)
  • Kibana (outil de dashboard)

Et un ensemble de solution commerciales appelées génériquement X-Pack

En particulier, graph permet d’éviter le problèmes des supernoeuds dans les graphes (un problème auquel je suis assez sensible, mais je m’éloigne du sujet).
Et prelert va identifier les erreurs « exceptionnelles » grâce à de l’apprentissage.

A quoi sert elasticsearch ?

Ben à faire des recherches floues, où à trier les résultats de recherche selon … un score. Et floue, ça implique de gérer les fautes d’orthographe, les textes approchants, les synonymes, …

Et maintenant, le coeur de la présentation : ingest node

Avec ingest, on peut remplacer l’architecture classique

iyxfbszfiyqhkn3bp4briaqiaupaxelvvas7bogmpowa5ifpxazotebfsoa4r1ixorlc91qnp2o7foom9mtmmmtkjkco3cvfsa5c1vc85kpm5kqwtyzc0g00

par une architecture beaucoup plus simple

iyxfbszfiyqhkn3bp4briaqiaupaxekvvygmbsgc1wsc5ylda5hpag01gjopbpsrk8ihbwkkllvn3y880000

Du coup, le pipeline de transformation Logstash (grok, date, mutate) est remplacé par un équivalent ingest (grok, date, remove). Il y a naturellement tout un tas de plugins (dont la lecture d’attachments avec Tika). Bon, autrement dit, on remplace un ETL par un autre, espérons juste qu’il soit plus performant. Et évidement, on peut créer ses propres plugins.

Il y a quand même un gros intérêt, puisque les pipelines ingest sont utilisables dans la plupart des urls d’appel à Elasticsearch. Et en particulier, dans l’un des trucs les plus balaizes : le reindex. Ce reindex permet la migration facile d’un cluster Elasticsearch d’une vieille version vers une nouvelle. Et ça, ça me paraît vraiment très chouette.

Comme dans n’importe quel ETL, il est possible de définir des failure processors qui vont être utilisés en cas d’échec lors de la série de transformation. On peut les définir par pipeline ou par processeur.

Dans un cluster, (parce que oui, Elasticsearch fonctionne toujours en cluster), il est possible de laisser tous les noeuds faire de l’ingestion, on d’en forcer certains à faire l’ingestion. En prod, d’ailleurs, il vaut mieux séparer les noeuds d’ingestion des noeuds de données.

Et si on regardait un plugin ?

Par exemple, le fameux plugin BANO (déja mentionné chez les castcodeurs). BANO pour base nationale d’adresses, parce que David est fan des adresses postales. Et cette base, ce sont des documents CSV (ou JSON) disponibles chez OpenStreetMap.
Donc David a un plugin qui lui permet de charger dans Elasticsearch la base des adresses, puis d’enrichir les adresses et les localisations GPS en ajoutant la donnée inverse.

Et maintenant, c’est le moment de la démo !

Et franchement, au début, la définition de pipeline d’ingestion est assez facile, et la définition des failure processors est tout aussi facile. J’imagine très bien les interfaces très graphiques faisables là-dessus.
Pour la récupération des données, le fait que ce soit un moteur de recherche fait que des résultats moins pertinents pourront être retournés par les requêtes, mais derrière les résultats les plus pertinents.

Un autre élément intéressant, c’est que la recherche est foutrement rapide : l’ingestion d’une coordonnée GPS avec ajout automatique des adresses (et donc recherche dans l’index des coordonnées) est immédiate (pour autant qu’on puisse le voir). Même si la coordonnée GPS n’est pas exactement la bonne.

Et avec tout ça, et le processor GeoIP, il est par exemple possible d’envoyer un courier à l’adresse donnée lors de la requête HTTP. Ca fout la trouille, hein ?

Au passage, l’un des trucs les plus intéressants selon moi est l’utilisation de JSON pour exprimer les requêtes : le code n’est pas moins clair qu’avec un langage de requête dédié (genre SQL).

Un autre intérêt d’Elasticsearch, c’est qu’il supporte les tâches longues, qu’on peut suivre et gérer (pour par exemple tuer les tâches trop longues).

Non mais, et si on développait vraiment un plugin ?

Eh bien ce serait aussi simple que d’écrire une classe étendant une superclasse abstraite.
Evidement, quand on regarde le code, on voit des choses … curieuses : trouver le point le plus proche en calculant la distance de tous les points, je peux dire que c’est pas le plus efficace (il n’y a pas d’index géographiques ou quadtrees dans Lucene ? Ah si, à priori, avec les bkdtree de Lucene 6).
Dans le même ordre d’idée, déclarer ses plugins en associant une clé à une factory … alors qu’on peut faire du CDI ? C’est pas fameux. mais bon, tout le monde n’est pas censé écrire des plugins.

Conclusion

L’un des plus gros intérêts de cette présentation, c’est de sortir Elasticsearch de son rôle le plus connu de stockage ELK pour bien montrer qu’avant tout, c’est un ETL moderne qu’on sous-utilise volontiers.

Et personnellement, en voyant cette présentation, j’ai eu l’envie un peu folle de resortir mes projets de livestream pour les porter dans une base plus moderne.

Et pour la blague, le premier rang, c’est pratique pour démontrer la présence quand le speaker fait des selfies

Publicités

Aujourd’hui c’est SEO

Je dis ça juste pour reprendre les excellents titres de Marion Montaigne (un hommage à une talentueuse artiste, en quelque sorte).

Bref, j’ai été informé ce week-end, par des canaux familiaux, que ce blog chez WordPress n’avait absolument aucune visibilité dans les moteurs de recherche.

N’écoutant que mon courage, j’ai donc tapé www.google.fr et fait quelques recherches sur ce site.

Des recherches comme

Nicolas Delsaux - Recherche Google - Opera_2013-08-20_09-23-35

De façon assez classique, voilà donc tous les sites dans lequels il va falloir que j’ajoute une référence vers ce nouveau blog histoire d’augmenter sa visibilité.

Bon, ce qui est gênant, c’est que je crois l’avoir déja fait … chez twitter (oui, je viens de vérifier, c’est déja fait).

Essayons donc chez viadeo et linkedin.

Au passage, il est assez marrant de voir que Google se trompe facilement dans la recherche d’image …

Ah, mais attendez, j’avais pas changé l’adresse de mon blog dans mon profil Google+, utilisé pour toute la googlesphère !

Bon, je la change, et onv erra ce qui se passe.

En attendant, une chose est sûre, la SEO,c ‘est quand même pas loin d’être de la magie noire.