Nous avons vu précédemment qu'Elasticsearch était un serveur de base de donnée NoSQL et en quoi cela le distinguait des serveur de BDD SQL habituels.

Mais maintenant, quand faut-il l'utiliser, dans quels cas faut-il l'utiliser ?

On distingue 2 grandes usages principaux à Elasticsearch : le stockage spécialisé de logs et l'usage en base de donnée "normale".

Le stockage de logs

Le rêve des administrateurs système et DevOps

Je ne vous ferais pas l'affront de vous expliquer ce que sont des logs. Par contre, quand vous avez quelques dizaines/centaines/milliers de serveurs dont vous vous occupez et que vous devez investiguer pourquoi tel grappe de serveur est partie en caraffe, c'est vite fastidieux de parcourir tous les logs systèmes de toutes les machines.

La seule solution vraiment intéressante, c'est de centraliser. Tous vos logs.

Et si en plus, on pouvait chercher facilement dedans et faire de la corrélation, ça serait le top.

Bienvenue dans le monde merveilleux d'elasticsearch et de ses amis filebeat, logstash et kibana.

Le but vers lequel tendre pour les dev

Un bon soft est toujours accompagné de bons logs applicatifs. Si votre super appli web ultra-responsive écrite en go+react ne produit pas de logs, correctement formatés, significatifs, etc... ce n'est pas un bon soft.

Ok, les logs, c'est pas sexy, mais pourtant, ça sauve la vie quand tout plante.

Vous pouvez faire simple : tout envoyer dans un fichier, sans formatage, et c'est l'adminsys qui s'occupera du reste. Mais vous pouvez (et c'est très fortement conseillé) convenir d'un format de log facilement parsable qui sera plus facilement utilisable. Le top, étant de les envoyer directement dans un elasticsearch.

Mais qu'est-ce que les dev en retire ? De belles métriques à présenter aux managers/commerciaux, des débogages (post-mortem ou pas) à coups de requêtes simili-SQL. Le tout dans une super interface ou une API simple (REST).

La base de donnée "normale"

Sur ce point, je vais vous faire pointer vers le graph fait par The HFT guy pour un résumé très visuel.

Contrainte forte sur le temps de réponse

Elasticsearch a été construit pour répondre à n'importe quelle requête très vite. Quelque soit la requête. Par défaut, tout est analysé et indexé pour permettre des temps de réponse très bas. Par exemple, sur un de mes systèmes en production actuellement, quelque soit la requête, elle est répondu en un temps moyen de 20ms, et un maximum de 200ms (et un temps median à 10ms).

Elasticsearch a été codé pour la vitesse. Et il va vraiment vite.

Scalabilité

Ce système de base de donnée peut tourner en test sur votre ordinateur portable, en intégration sur un petit cluster de 2 noeuds et en production sur un cluster de dizaines ou centaines de serveurs.

Il peut stocker plusieurs peta-octets de données, tout en garantissant les temps de réponse aux requêtes, la facilité d'accès à vos données.

Et ce qu'il y a de beau dans tout cela, c'est la facilité que vous aurez à augmenté la capacité de stockage de votre base de donnée : installez Elasticsearch sur un nouveau serveur, modifiez un seul paramètre dans son fichier de configuration, et voilà. Votre capacité a été augmentée.

Cela vous permettra de gagner en capacité aisément, même si vous ne l'aviez pas planifié au départ.

Bonus

En complément, viennent nativement avec Elasticsearch :

• Full-text search
• Facilité d'installation et de maintenance