Elasticsearch, qu'est-ce que c'est

Posted on jeu. 08 juin 2017 in Elasticsearch

Elasticsearch est une technologie à la mode, avec de belles promesses, mais concrètement, c'est quoi ?

En résumé, Elasticsearch est un système de base de donnée NoSQL hautement distribué et scallable.

NoSQL

Serveurs SQL traditionnels

Lorsqu'une application interroge un serveur de base de donnée, généralement, il s'agit de requêtes SQL envoyées à des serveurs Oracle, MySQL/MariaDB ou PostgreSQL pour les plus connus. Cela impose quelques contraintes :

  • Utilisation d'un language additionnel, le SQL
  • Définition d'un schéma figé CREATE TABLE ma_table(id INT, colonne1 TEXT, colonne2 INT);, aux changements compliqués
  • Installation/Import des drivers propres au serveur de BDD
  • Utilisation d'un unique serveur non-scalable et non-distribué (même si cela devient tout doucement possible, ça reste réellement compliqué)

Elasticsearch

De son côté, Elasticsearch permet d'enlever certaines de ces contraintes :

  • Utilisation de requêtes REST (Json over HTTP)
  • Le schéma n'est pas figé, et l'ajout d'un champ se fait à la volée
  • Pas besoin de drivers puisque que le protocol est vraiment standard (même votre navigateur internet peut le faire)
  • Elasticsearch a été pensé dès le début pour être distribué et scallabe

Inconvénients

D'un autre côté, tout n'est pas rose pour elasticsearch, loin de là. Chaque système a ses avantages et ses inconvénients. Typiquement, Elasticsearch est un gouffre à ressource (disqur dur/RAM) et ne pas avoir de schéma figé ne veut pas dire qu'il ne faut pas avoir de schéma tout court. Au contraire. Elasticsearch sera d'autant plus utilisable et performant que votre base de donnée aura un schéma.

Hautement distribué et scallable

L'intérêt d'avoir sa BDD éclatée sur plusieurs serveurs

Un système est dit "distribué" quand il ne réside pas sur un seul serveur, mais plusieurs.

Par exemple, MySQL est un système qui ne peut être installé que sur un seul serveur. Si vous installé un 2e serveur MySQL, il vous sera impossible d'accéder aux données présentes sur le 1e serveur en l'interrogeant. (En vrai, c'est possible, mais après moults efforts fait par un/des experts).

Dans le cas d'Elasticsearch, installez-en un, puis un deuxième, puis un centième si vous le voulez, ils partageront leurs données que vous pourrez récupérer en interrogeant le serveur de votre choix.

Comment vont grossir vos données

Admettons que d'ici quelques semaines ou mois vos données auront doublé de volume. Et que la semaine prochaine vous aurez atteind les limites de capacité de votre serveur.

Comment cela se passe pour un serveur traditionnel SQL ? Facile, vous achetez un autre serveur plus gros (ou vous demander un nouvelle VM plus grosse), et vous déplacez les données dessus. Cela peut prendre de quelques heures à quelques semaines pour mener à bien cette opération, en fonction de la taille de vos données, des applications les utilisant, des administrateurs, etc...

Et pour Elasticsearch, me direz-vous ? Demandez un nouveau serveur ou une nouvelle VM, mais au lieu de migrer les données dessus, vous l'ajoutez au groupe de serveur. Les serveurs vont alors se répartir les données équitablement, comme si vous aviez ajouté à chaud du disque, de la RAM et du CPU sur un serveur, et vous voilà reparti pour un tour. Cela prend entre 5 minutes et une demi-journée. Et sans downtime. Aucun.

Usage

Attention. Elasticsearch, que nous allons étudier dans cette série de post, a beau être une technologie merveilleuse, il n'en faut pas pour autant remiser vos serveurs SQL.

Ce sont 2 technologies différentes qui n'adressent pas les même usages.

Relationnelle

Les jointures sont propres au système SQL et n'existent pas dans le monde NoSQL. Ou sont bien moins performante.

Typiquement, les relations qu'il peut y avoir entre enregistrements (on parle souvent de base de donnée relationnelle) n'existent qu'en SQL. Si cela est important pour vous ou votre application, passez votre chemin. Ou changez votre manière de penser et votre application de fond en comble.

Grossissement dans le temps

Si vous savez que vous n'allez pas avoir plus de données dans le futur, ou que le grossissement se fera à un taux dérissoir, prenez une base de donnée SQL. Dans le cas contraire, regardez les système NoSQL de près, cela pourrait vous sauvez la vie dans un futur pas si lointain.

Au final, je vous renvoie vers cet excellent post thehftguyblogpost, en particulier le graphique de décision qui y est attaché. Choix SQL ou NoSQL (voir en plus grand)