Téléphone Next Decision02.34.09.31.70

Contact Next Decisioncontact@nextdecision.fr

Astuces pour bien pratiquer Elasticsearch

Nous analysons pour vous la suite Elasticsearch et vous livrons quelques astuces pour bien pratiquer ! 

L'architecture de développement Elasticsearch

L'architecture suivante a été appliquée sur la maquette Elasticsearch :

Avantages et inconvénients d'Elasticsearch

Ce serveur accueille donc 3 composants :

  • Logstash : L'ETL fourni nativement par Elastic pour charger la base de données Elasticsearch
  • Elasticsearch : La base de données
  • Kibana : L'outil de reporting qui, naturellement, permet de visualiser les données présentes dans Elasticsearch

Cette architecture convient bien à la mise en place d’une maquette mais n’est pas recommandée en production. En effet, la puissance des bases NoSQL est décuplée dans un environnement distribué. Le paragraphe suivant donne un exemple d’architecture cible de production.

Architecture de la production Elasticsearch

Voici un exemple d'architecture de production Elasticsearch :

Avantages et inconvénients d'Elasticsearch

Dans cette architecture, on note plusieurs différences par rapport à l’architecture maquette :

  • Cette architecture est distribuée : Il y a plusieurs noeuds Elasticsearch, ce qui permet de répartir à la fois les traitements et les données.
  • Les nœuds Elasticsearch sont discriminés en fonction de leur usage : D = data, I = Ingestion, M = Master. Ici les deux nœuds ont des fonctions bien précises. Les deux Master de la machine 3 ne contiennent pas de données et n'ont pas de fonction d'ingestion non plus. De cette manière, ils se comportent comme des répartiteurs de charge. Les autres nœuds possèdent la donnée (D) et peuvent indexer du contenu (I) en provenance de Logstash.

Comment modéliser avec Elasticsearch ?

Elasticsearch et le modèle dénormalisé

Dans les bases NoSQL, il n’est pas possible de réaliser des jointures entre tables. De cette manière, il n’est donc pas possible de réaliser des jointures entre index dans Elasticsearch. Si les bases NoSQL ne supportent pas les jointures, c’est parce que ces dernières sont coûteuses en terme de temps.

Pour pallier à cette « contrainte », il convient donc de dénormaliser notre modèle. Cependant, il ne faut pas dénormaliser sans réflexion.

Avantages et inconvénients d'Elasticsearch

Voici un exemple de modélisation dimensionnelle classique, avec 3 tables de faits :

  • Ventes
  • Orders (commandes)
  • Budget

Pour dénormaliser ce modèle, il n’est pas possible de tout intégrer dans un seul et même index, car cela n’a pas de sens d’un point de vue métier. En effet, mélanger les données de ventes et de budget n’a aucun sens (car n’étant pas liées aux mêmes dimensions).

Il conviendra donc ici de dénormaliser notre modèle de sorte à avoir un modèle par table de faits:

  • Ventes avec ses dimensions associées : produit, client, temps et mag
  • Orders avec ses dimensions associées : produit, client, temps et mag
  • Budget avec ses dimensions associées : mag et temps

D'un point de vue Elasticsearch, cela se concrétisera par la création de 3 index séparés contenant chacun un contexte métier différent.

Elasticsearch et le modèle imbriqué

Parfois, il est tout de même utile de «simuler» le côté relationnel, notamment lorsque le modèle comporte des hiérarchies fortes. Dans l’exemple suivant, nous avons 3 niveaux hiérarchiques:

Niveau 1 : FLUX

Niveau 2 : TRAITEMENT

Niveau 3 : ÉVÉNEMENT

Dans ce cas, il est donc possible d’utiliser les notions de «nested» pour imbriquer des éléments entre eux, comme dans l’exemple ci-dessous :

Avantages et inconvénients d'Elasticsearch

L'ingestion de données dans Elasticsearch

Avec Logstash

Nativement, Elastic propose la solution Logstash en tant qu’ETL. Ce dernier permet de réaliser des transformations de données puissantes. Par contre, ce dernier est un programme Java. Cela le rend donc potentiellement plus lent que d’autres solutions.

Via des APIS

De base, tout Elasticsearch fonctionne via des APIs. Il est donc possible d’utiliser les APIs existantes pour intégrer du contenu dans la base de données:

  • INDEX Api : Pour indexer du contenu, créer des index, etc.
  • SEARCH Api : Pour réaliser des requêtes sur les données présentes dans Elasticsearch

Via la suite de produits Beats

  • Metricbeat : Agent de transfert de métriques issues de services (Apache, NGinx, etc.)
  • Packetbeat : Agent de transfert de données réseaux
  • Winlogbeat : Agent de transfert des logs d’événements Window
  • Auditbeat : Agent de transfert de données d’audit Linux (auditd)
  • Heartbeat : Agent de surveillance de disponibilité

Attention : Les agents Beats ne permettent pas de réaliser des transformations sur les données. Pour ce faire, il est possible de rediriger la sortie de Beats vers Logstash.

Avantages et inconvénients d'Elasticsearch

La mise à jour de données dans Elasticsearch

Ajout d'une donnée dans un document imbriqué

Il est possible d'utiliser l'API_update et le script pour ajouter un nouvel événement dans un traitement d'un flux :

Avantages et inconvénients d'Elasticsearch

Modification d'un champ dans un modèle imbriqué

Exemple de script pour mettre à jour dans un modèle Nested, toujours en employant l'API_update :

Avantages et inconvénients d'Elasticsearch

Comment requêter Elasticsearch ?

Requête via le langage naturel (DSL)

Nativement, Elasticsearch propose le langage DSL (Domain Specific Language) pour interroger les données présentes dans la base de données. Le format ressemble à l'écriture d'un document JSON.

Exemple de recherche :

Avantages et inconvénients d'Elasticsearch

Exemple de requête cherchant tous les enregistrements de l'index flux_elastic qui réunissent les conditions suivantes :

  • Statut = ERROR
  • Date_création comprise entre 01/01/2018 et 30/04/2018

Requête en SQL

Bien qu'il ne soit pas possible de requêter Elasticsearch en SQL, le moteur propose une API pour traduire des requêtes SQL en DSL :

Avantages et inconvénients d'Elasticsearch

L'API propose également "translate" :

Avantages et inconvénients d'Elasticsearch

Attention néanmoins, le format SQL n'est pas intégralement pris en charge. Par exemple, il n'est pas possible de réaliser des sous-requêtes, ni des jointures. Enfin, le DSL généré n'est pas forcément le plus optimisé mais il permet tout de même d'obtenir une trame de requête.

Requête via des APIS / Langages tiers

Enfin, il est possible d'utiliser l'API_search pour créer des recherches, à l'aide de n'importe quel autre langage, tel que Python, Perl, etc.

En Python, il y a le package Elasticsearch qui permet d'aller interroger / indexer du contenu dans la base de données :

Avantages et inconvénients d'Elasticsearch

La même chose est possible en Java :

Avantages et inconvénients d'Elasticsearch

Ou bien en Perl :

Avantages et inconvénients d'Elasticsearch

Elasticsearch pour d'autres usages ?

Analyse de logs

Historiquement, Elasticsearch est parfait pour de l'analyse de logs en temps réel. Voici un exemple d'architecture :

Avantages et inconvénients d'Elasticsearch

Dans le cas des événements Windows ou d'audits Linux, il n'y a pas de travail sur la donnée donc les logs peuvent directement passer de l'agent Beat vers Elasticsearch. Le fichier de log sur le serveur AIX a besoin, quant à lui, d'être parsé (découpé) et retravaillé. La donnée doit donc passer par Logstash avant d'aller dans Elasticsearch.

Retour au Wiki

Vous recherchez des consultants experts en Elasticsearch ? Next Decision est là ! alors Contactez-nous !

Laissez-nous vos coordonnées et nous vous rappellerons sous 24 heures.

 

Les adresses
Next Decision

Tel : 02.34.09.31.70
31 Rue Fouré
44 000 NANTES
contact@nextdecision.fr
Tel : 02.34.09.31.70
42 rue Glasgow
29 200 BREST
contact@nextdecision.fr
Tel : 02.34.09.31.70
11 Rue des Portes Mordelaises
35000 RENNES
contact@nextdecision.fr
Tel : 02.34.09.31.70
4 bis rue Bodinier
49 000 ANGERS
contact@nextdecision.fr

Tel : 09.51.29.09.35
116 rue Lamarck
75 018 PARIS
contact@nextdecision.fr

Tel : 09.51.29.09.35
37 Avenue Franklin Delano Roosevelt
75 008 PARIS
contact@nextdecision.fr

Tel : 09.51.29.09.35
5 Rue de Saintonge
75 003 PARIS
contact@nextdecision.fr

Tel : 02.34.09.31.70
235 avenue Emile Counord
33 300 BORDEAUX
contact@nextdecision.fr
Tel : 09.81.93.23.03
23 esplanade de l’Europe
34 000 MONTPELLIER
contact@nextdecision.fr
Tel : 02.34.09.31.70
32 Rue Matabiau
31 000 TOULOUSE
contact@nextdecision.fr
Tel : 02.34.09.31.70
40b rue De La Villette
69 003 LYON
contact@nextdecision.fr