Lancé en 2010, Elasticsearch a été l'un des premiers moteurs de recherche distribués conçus pour l'interrogation rapide des données à afficher dans l'analytique ou les résultats du Big Data. À l’époque, de plus en plus d’entreprises accumulaient d’énormes quantités de données, mais les moteurs de bases de données traditionnels n’étaient pas en mesure de suivre le rythme. Elasticsearch a été introduit sous forme de base de données vectorielle capable de stocker des données structurées et non structurées. C’était le premier grand bond en avant dans l’indexation du Big Data et les requêtes plus rapides lorsque l’analytique d’entreprise dépassait les téraoctets de données, entraînant des problèmes de performance.
Qu’est-ce qu’Elasticsearch ?
Elasticsearch est un datastore utilisé pour rassembler les données et les rendre consultables via une API. Il est basé sur Apache Lucene, un service d’indexation et de stockage qui distribue les données en partitions. Chaque partition contient ses propres données, mais les partitions sont séparées les unes des autres pour répartir les données entre les nœuds. Elasticsearch regroupe tous les partitions et fournit une API permettant aux développeurs d’interroger les données. Avec l’API, les administrateurs peuvent définir des autorisations pour des utilisateurs spécifiques afin de sécuriser davantage les données et de donner accès à des données spécifiques uniquement aux utilisateurs autorisés.
Les développeurs ne se limitent pas aux données structurées ou non structurées. Elasticsearch permet aux utilisateurs d’extraire des données structurées et non structurées, mais il interroge les données dans ses partitions distribuées comme si le stockage était une grande base de données. La façon dont Elasticsearch gère les données les rend beaucoup plus rapides qu’un moteur de base de données standard. Il est donc préférable pour les applications qui disposent d’outils d’analyse, de fonctionnalités de recherche sur un grand nombre de données ou d’une analyse du trafic réseau.
Composants essentiels de l’architecture Elasticsearch
Le premier composant central d’Elasticsearch est le nœud. Un nœud est un serveur ou un périphérique où les données sont stockées. Les clusters sont constitués d’un ensemble de nœuds. Les nœuds et les clusters peuvent être distribués entre les datacenters pour assurer la redondance, mais les données distribuées sont ce qui améliore les performances des requêtes de données. Elasticsearch est une base de données vectorielle, mais elle stocke les données sous forme de document. Un document est une entité qui stocke des données non structurées, bien que des données structurées puissent également y être stockées.
Les données sont fragmentées entre les nœuds. Les partitions sont une partie des données permettant de segmenter les grands datastores en portions plus petites, ce qui facilite la distribution et les requêtes simultanées pour rassembler les données dans un ensemble de résultats pour l’application frontend. Logstash est utilisé comme pipeline de données, qui prend les données sous leur forme brute et les transforme en une forme utilisable.
Elasticsearch dispose également d’une API qui est la passerelle vers les données. Les développeurs doivent s’authentifier dans l’API et l’interroger avec une clé. L’API contrôle l’accès aux données et la manière dont les développeurs peuvent les interroger. Le fait de disposer d’une API masque également l’architecture backend et la sécurise, ce qui la rend accessible aux développeurs qui ne connaissent pas le fonctionnement d’Apache Lucene et d’autres composants.
Nœuds et clusters
Un cluster est un groupe de nœuds, mais les nœuds ont leur propre rôle spécifique dans un cluster. Le nœud maître, en général, contrôle le cluster. Le nœud maître peut créer ou supprimer des index et suivre d’autres nœuds qui participent au cluster. Chaque cluster possède un nœud maître.
Un nœud de données stocke les données. Toute manipulation ou modification des données relève de la responsabilité du nœud de données. Lorsque vous agrégez des données, vous les ajoutez au nœud de données. La fonctionnalité de recherche se produit également au niveau du nœud de données.
Considérez la coordination des nœuds comme les passerelles qui contrôlent le trafic vers le bon nœud. Un nœud de coordination envoie des requêtes au nœud maître ou aux nœuds de données, en fonction de leur destination. Par exemple, lorsqu'une recherche est envoyée au cluster, le nœud coordinateur gère sa demande.
Elasticsearch dispose d’un pipeline pour transformer et déplacer les données. Le nœud d’ingestion est chargé de gérer les documents et de les transformer pour l’indexation. Elasticsearch recommande d’avoir un nœud d’ingestion indépendant des nœuds maître et de données dans les environnements où les transferts de données sont lourds.
Les nœuds éligibles à distance envoient des demandes à d’autres clusters du système Elasticsearch. Les requêtes de recherche peuvent trouver des données à l’aide de la fonctionnalité multi-cluster avec un nœud éligible à distance. La réplication des données entre les clusters relève également de la responsabilité des nœuds éligibles à distance.
Shards et répliques
Les recherches et requêtes rapides nécessitent des index. Les index sont la façon dont un datastore organise les données de manière à accélérer les recherches. Dans Elasticsearch, chaque index est composé d’un certain nombre de partitions. Les partitions sont stockées sur des nœuds où Elasticsearch les distribue dans le cluster pour un traitement plus rapide. Les partitions contiennent une copie des données, mais Elasticsearch peut effectuer des recherches simultanées sur plusieurs partitions.
La redondance est nécessaire pour le basculement et la tolérance aux pannes. Les répliques traitent donc une copie des partitions. Les répliques sont stockées sur différents nœuds afin de ne pas perdre de données en cas de défaillance d’un nœud. En cas de défaillance d’un nœud, Elasticsearch pourra alors accéder aux données sur une réplique sur un nœud différent.
Flux de données dans Elasticsearch
Elasticsearch fournit une API permettant aux développeurs d’envoyer leurs requêtes. L’API protège les développeurs de la complexité du back-end. Comme nous l’avons vu, le backend se compose de plusieurs composants, notamment des partitions, des nœuds, des index et des répliques. Au lieu d’obliger les développeurs à gérer les chercheurs Elasticsearch, le flux de données commence par une requête sur l’API.
L’API envoie d’abord la requête à un coordinateur. Le coordinateur l’envoie au nœud approprié où se trouvent les partitions. Une requête peut également être envoyée à plusieurs partitions avec leur propre ensemble de données. Le routage est effectué par le coordinateur, qui détermine les bons partitions pour la requête.
Une fois les documents collectés, les index des documents sont renvoyés au coordinateur. Lorsque plusieurs partitions renvoient des données au coordinateur, celui-ci organise les index, les fusionne et les trie. Une fois les index triés, le coordinateur récupère les documents réels des partitions. Une fois les données récupérées, elles sont renvoyées à l’application via l’API.
Bonnes pratiques pour optimiser l’architecture Elasticsearch
Elasticsearch est bien plus complexe que le moteur de base de données moyen, c’est pourquoi son optimisation repose sur une approche différente. Vous devez d’abord vous assurer que suffisamment de ressources s’exécutent dans le backend. Si les requêtes sont trop lentes, envisagez d’augmenter la capacité de stockage du processeur, de la mémoire ou du serveur.
Les index sont nécessaires à la recherche de données, mais certaines données ne sont pas aussi fréquemment utilisées que d’autres. Elasticsearch vous permet de geler les index, ce qui déplace les index inutilisés vers un autre partition. Les coordinateurs disposent ensuite de moins de partitions pour rechercher chaque requête, améliorant ainsi les performances.
Les pools de threads dans Elasticsearch contrôlent la taille des requêtes et doivent être optimisés pour prendre en charge la quantité de données traitées dans chaque requête. Configurez des pools de threads pour gérer suffisamment de données pour vos requêtes, mais ils sont également liés aux ressources des nœuds. Les nœuds et les pools de threads doivent disposer de ressources suffisantes, sans quoi vous pourriez constater une dégradation des performances lors des requêtes à volume élevé.
Conclusion
Elasticsearch est beaucoup plus complexe qu’une base de données standard, il est donc nécessaire de disposer de l’architecture et des ressources informatiques appropriées pour optimiser les performances. Utilisez les bonnes pratiques lorsque vous configurez Elasticsearch, mais il est également important de disposer des ressources informatiques appropriées pour prendre en charge les requêtes et le stockage de données nécessaires au back-end.
Pour vous assurer de disposer de ressources de stockage suffisantes, vous pouvez utiliser Pure Storage® FlashBlade®. FlashBlade soutient une croissance exponentielle pour les petites et grandes entreprises. Vos applications peuvent évoluer à mesure que de plus en plus d’utilisateurs stockent des données et prennent en charge un nombre illimité de clients.
