Mises à jour, insertions, suppressions d'Elasticsearch : comprendre leur fonctionnement et leurs limites

Introduction

La gestion du streaming de données depuis un système source, tel que PostgreSQL, MongoDB ou DynamoDB, vers un système en aval pour la recherche et l'analyse en temps réel constitue un défi pour de nombreuses équipes. Le flux de données implique souvent des outils ETL complexes ainsi que des intégrations autogérées pour garantir que les écritures à volume élevé, y compris les mises à jour et les suppressions, n'accumulent pas de CPU ni n'impactent les performances de l'application finale.

Pour un système comme Elasticsearch , les ingénieurs doivent avoir une connaissance approfondie de l'architecture sous-jacente afin d' ingérer efficacement les données en streaming . Elasticsearch a été conçu pour l'analyse de journaux où les données ne changent pas fréquemment, ce qui pose des défis supplémentaires lors du traitement des données transactionnelles.

Rockset, en revanche, est une base de données cloud native, supprimant une grande partie des outils et des frais généraux nécessaires pour importer les données dans le système. Comme Rockset est spécialement conçu pour la recherche et l'analyse en temps réel, il a également été conçu pour une mutabilité au niveau du champ , réduisant ainsi le processeur requis pour traiter les insertions, les mises à jour et les suppressions.

Dans ce blog, nous comparerons la manière dont Elasticsearch et Rockset gèrent l'ingestion de données et fournirons des techniques pratiques pour utiliser ces systèmes pour des analyses en temps réel.

Recherche élastique

Ingestion de données dans Elasticsearch

Bien qu'il existe de nombreuses façons d'ingérer des données dans Elasticsearch, nous couvrons trois méthodes courantes pour la recherche et l'analyse en temps réel :

• Ingérer des données d'une base de données relationnelle dans Elasticsearch à l'aide du plug-in d'entrée Logstash JDBC

• Ingérer des données de Kafka dans Elasticsearch à l'aide du connecteur Kafka Elasticsearch Service Sink

• Ingérez des données directement depuis l'application dans Elasticsearch à l'aide de l'API REST et des bibliothèques clientes

  
  

Ingérez des données d'une base de données relationnelle dans Elasticsearch à l'aide du plug-in d'entrée Logstash JDBC. Le plug-in d'entrée Logstash JDBC peut être utilisé pour décharger les données d'une base de données relationnelle telle que PostgreSQL ou MySQL vers Elasticsearch à des fins de recherche et d'analyse.

Logstash est un pipeline de traitement d'événements qui ingère et transforme les données avant de les envoyer à Elasticsearch. Logstash propose un plugin d'entrée JDBC qui interroge périodiquement une base de données relationnelle, comme PostgreSQL ou MySQL, pour les insertions et les mises à jour. Pour utiliser ce service, votre base de données relationnelle doit fournir des enregistrements horodatés qui peuvent être lus par Logstash pour déterminer les modifications survenues.

Cette approche d'ingestion fonctionne bien pour les insertions et les mises à jour, mais des considérations supplémentaires sont nécessaires pour les suppressions. En effet, Logstash ne peut pas déterminer ce qui a été supprimé dans votre base de données OLTP. Les utilisateurs peuvent contourner cette limitation en implémentant des suppressions logicielles, où un indicateur est appliqué à l'enregistrement supprimé et utilisé pour filtrer les données au moment de la requête. Ils peuvent également analyser périodiquement leur base de données relationnelle pour accéder aux enregistrements les plus récents et réindexer les données dans Elasticsearch.

Ingérez des données de Kafka dans Elasticsearch à l'aide du connecteur Kafka Elasticsearch Sink . Il est également courant d'utiliser une plate-forme de streaming d'événements comme Kafka pour envoyer des données des systèmes sources vers Elasticsearch à des fins de recherche et d'analyse en temps réel.

Confluent et Elastic se sont associés pour lancer le connecteur Kafka Elasticsearch Service Sink , disponible pour les entreprises utilisant à la fois les offres gérées Confluent Kafka et Elastic Elasticsearch. Le connecteur nécessite l'installation et la gestion d'outils supplémentaires, Kafka Connect.

À l'aide du connecteur, vous pouvez mapper chaque sujet dans Kafka à un seul type d'index dans Elasticsearch. Si le typage dynamique est utilisé comme type d'index, Elasticsearch prend en charge certaines modifications de schéma telles que l'ajout de champs, la suppression de champs et la modification de types.

L'un des défis qui se posent lors de l'utilisation de Kafka est la nécessité de réindexer les données dans Elasticsearch lorsque vous souhaitez modifier l'analyseur, le tokenizer ou les champs indexés. En effet, le mappage ne peut pas être modifié une fois qu'il est déjà défini. Pour effectuer une réindexation des données, vous devrez effectuer une double écriture dans l'index d'origine et le nouvel index, déplacer les données de l'index d'origine vers le nouvel index, puis arrêter le travail du connecteur d'origine.

Si vous n'utilisez pas de services gérés de Confluent ou Elastic, vous pouvez utiliser le plugin Kafka open source pour Logstash pour envoyer des données à Elasticsearch.

Ingérez des données directement depuis l'application dans Elasticsearch à l'aide de l'API REST et des bibliothèques clientes. Elasticsearch offre la possibilité d'utiliser les bibliothèques clientes prises en charge, notamment Java, Javascript, Ruby, Go, Python et bien d'autres, pour ingérer des données via l'API REST directement depuis votre application. L'un des défis liés à l'utilisation d'une bibliothèque cliente est qu'elle doit être configurée pour fonctionner avec la mise en file d'attente et la contre-pression dans le cas où Elasticsearch ne serait pas en mesure de gérer la charge d'ingestion. Sans système de file d'attente en place, il existe un risque de perte de données dans Elasticsearch.

Mises à jour, insertions et suppressions dans Elasticsearch

Elasticsearch dispose d'une API de mise à jour qui peut être utilisée pour traiter les mises à jour et les suppressions. L'API de mise à jour réduit le nombre de déplacements réseau et les risques de conflits de versions. L'API Update récupère le document existant de l'index, traite la modification, puis indexe à nouveau les données. Cela dit, Elasticsearch ne propose pas de mises à jour ou de suppressions sur place. Ainsi, l’intégralité du document doit encore être réindexée, une opération gourmande en CPU.

Sous le capot, les données Elasticsearch sont stockées dans un index Lucene et cet index est divisé en segments plus petits. Chaque segment est immuable, les documents ne peuvent donc pas être modifiés. Lorsqu'une mise à jour est effectuée, l'ancien document est marqué pour suppression et un nouveau document est fusionné pour former un nouveau segment. Afin d'utiliser le document mis à jour, tous les analyseurs doivent être exécutés, ce qui peut également augmenter l'utilisation du processeur. Il est courant que les clients dont les données changent constamment voient les fusions d'index engloutir une part considérable de leur facture globale de calcul Elasticsearch.

Compte tenu de la quantité de ressources requises, Elastic recommande de limiter le nombre de mises à jour dans Elasticsearch. Un client de référence d'Elasticsearch, Bol.com , a utilisé Elasticsearch pour la recherche sur site dans le cadre de sa plateforme de commerce électronique. Bol.com effectuait environ 700 000 mises à jour par jour de ses offres, y compris les modifications de contenu, de prix et de disponibilité. À l’origine, ils souhaitaient une solution qui restait synchronisée avec les changements au fur et à mesure qu’ils se produisaient. Mais, étant donné l'impact des mises à jour sur les performances du système Elasticsearch, ils ont choisi d'autoriser des délais de 15 à 20 minutes. Le regroupement des documents dans Elasticsearch a garanti des performances de requête cohérentes.

Problèmes liés aux suppressions et à la fusion de segments dans Elasticsearch

Dans Elasticsearch, des défis peuvent survenir liés à la suppression d'anciens documents et à la récupération d'espace.

Elasticsearch effectue une fusion de segments en arrière-plan lorsqu'il existe un grand nombre de segments dans un index ou lorsqu'un segment contient de nombreux documents marqués pour suppression. Une fusion de segments se produit lorsque des documents sont copiés à partir de segments existants vers un segment nouvellement formé et que les segments restants sont supprimés. Malheureusement, Lucene n'est pas doué pour dimensionner les segments qui doivent être fusionnés, ce qui peut créer des segments inégaux qui ont un impact sur les performances et la stabilité.

En effet, Elasticsearch suppose que tous les documents sont de taille uniforme et prend des décisions de fusion en fonction du nombre de documents supprimés. Lorsqu'il s'agit de documents de tailles hétérogènes, comme c'est souvent le cas dans les applications multi-tenant, certains segments croissent plus rapidement que d'autres, ralentissant les performances des plus gros clients de l'application. Dans ces cas-là, le seul remède est de réindexer une grande quantité de données.

Défis de réplication dans Elasticsearch

Elasticsearch utilise un modèle de sauvegarde principal pour la réplication. Le réplica principal traite une opération d'écriture entrante, puis transmet l'opération à ses réplicas. Chaque réplica reçoit cette opération et réindexe à nouveau les données localement. Cela signifie que chaque réplica dépense indépendamment des ressources de calcul coûteuses pour réindexer le même document encore et encore. S'il y a n réplicas, Elastic dépenserait n fois le processeur pour indexer le même document. Cela peut exacerber la quantité de données qui doivent être réindexées lorsqu'une mise à jour ou une insertion se produit.

Défis liés à l'API en masse et aux files d'attente dans Elasticsearch

Bien que vous puissiez utiliser l'API Update dans Elasticsearch, il est généralement recommandé de regrouper les modifications fréquentes à l'aide de l' API Bulk . Lors de l'utilisation de l'API Bulk, les équipes d'ingénierie devront souvent créer et gérer une file d'attente pour rationaliser les mises à jour dans le système.

Une file d'attente est indépendante d'Elasticsearch et devra être configurée et gérée. La file d'attente consolidera les insertions, les mises à jour et les suppressions sur le système dans un intervalle de temps spécifique, par exemple 15 minutes, afin de limiter l'impact sur Elasticsearch. Le système de file d'attente appliquera également une limitation lorsque le taux d'insertion est élevé pour garantir la stabilité de l'application. Bien que les files d'attente soient utiles pour les mises à jour, elles ne permettent pas de déterminer quand de nombreuses modifications de données nécessitent une réindexation complète des données. Cela peut se produire à tout moment si de nombreuses mises à jour du système sont effectuées. Il est courant que les équipes exécutant Elastic à grande échelle aient des membres dédiés aux opérations qui gèrent et ajustent quotidiennement leurs files d'attente.

Réindexation dans Elasticsearch

Comme mentionné dans la section précédente, lorsqu'il y a un grand nombre de mises à jour ou que vous devez modifier les mappages d'index, une réindexation des données se produit. La réindexation est sujette aux erreurs et peut potentiellement détruire un cluster. Ce qui est encore plus effrayant, c'est que la réindexation peut intervenir à tout moment.

Si vous souhaitez modifier vos mappages, vous avez plus de contrôle sur le moment où la réindexation se produit. Elasticsearch dispose d'une API de réindexation pour créer un nouvel index et d'une API d'alias pour garantir qu'il n'y a pas de temps d'arrêt lors de la création d'un nouvel index. Avec une API d'alias, les requêtes sont acheminées vers l'alias ou vers l'ancien index, lors de la création du nouvel index. Lorsque le nouvel index est prêt, l'API des alias sera convertie pour lire les données du nouvel index.

Avec l’API des alias, il est toujours délicat de synchroniser le nouvel index avec les dernières données. En effet, Elasticsearch ne peut écrire des données que dans un seul index. Vous devrez donc configurer le pipeline de données en amont pour écrire deux fois dans le nouvel et l'ancien index.

Ensemble de fusée

Ingestion de données dans Rockset

Rockset utilise des connecteurs intégrés pour maintenir vos données synchronisées avec les systèmes sources. Les connecteurs gérés de Rockset sont adaptés à chaque type de source de données afin que les données puissent être ingérées et rendues interrogeables en 2 secondes. Cela évite les pipelines manuels qui ajoutent de la latence ou ne peuvent ingérer des données que par micro-lots, par exemple toutes les 15 minutes.

À un niveau élevé, Rockset propose des connecteurs intégrés aux bases de données OLTP, aux flux de données, aux lacs et aux entrepôts de données. Voici comment ils fonctionnent :

Connecteurs intégrés aux bases de données OLTP Rockset effectue une analyse initiale de vos tables dans votre base de données OLTP, puis utilise les flux CDC pour rester synchronisés avec les dernières données, les données étant disponibles pour interrogation dans les 2 secondes suivant leur génération par le système source.

Connecteurs intégrés aux flux de données Avec des flux de données comme Kafka ou Kinesis, Rockset ingère en continu tous les nouveaux sujets à l'aide d'une intégration basée sur l'extraction qui ne nécessite aucun réglage dans Kafka ou Kinesis.

Connecteurs intégrés aux lacs de données et aux entrepôts Rockset surveille en permanence les mises à jour et ingère tous les nouveaux objets des lacs de données comme les compartiments S3. Nous constatons généralement que les équipes souhaitent rejoindre des flux en temps réel avec les données de leurs lacs de données pour des analyses en temps réel.

Mises à jour, insertions et suppressions dans Rockset

Rockset dispose d'une architecture distribuée optimisée pour indexer efficacement les données en parallèle sur plusieurs machines.

Rockset est une base de données fragmentée de documents , elle écrit donc des documents entiers sur une seule machine, plutôt que de les diviser et d'envoyer les différents champs à différentes machines. De ce fait, il est rapide d'ajouter de nouveaux documents à insérer ou de localiser des documents existants, en fonction de la clé primaire _id pour les mises à jour et les suppressions.

Semblable à Elasticsearch, Rockset utilise des index pour récupérer rapidement et efficacement les données lorsqu'elles sont interrogées. Contrairement à d'autres bases de données ou moteurs de recherche, Rockset indexe les données au moment de l'ingestion dans un index convergé , un index qui combine un magasin de colonnes, un index de recherche et un magasin de lignes. L'index convergé stocke toutes les valeurs des champs sous la forme d'une série de paires clé-valeur. Dans l'exemple ci-dessous, vous pouvez voir un document et comment il est stocké dans Rockset.

Sous le capot, Rockset utilise RocksDB , un magasin clé-valeur hautes performances qui rend les mutations triviales. RocksDB prend en charge les écritures et suppressions atomiques sur différentes clés. Si une mise à jour arrive pour le champ name d'un document, exactement 3 clés doivent être mises à jour, une par index. Les index des autres champs du document ne sont pas affectés, ce qui signifie que Rockset peut traiter efficacement les mises à jour au lieu de perdre des cycles de mise à jour des index de documents entiers à chaque fois.

Les documents et tableaux imbriqués sont également des types de données de premier ordre dans Rockset, ce qui signifie que le même processus de mise à jour s'applique également à eux, ce qui rend Rockset bien adapté aux mises à jour des données stockées dans des formats modernes tels que JSON et Avro.

L'équipe de Rockset a également créé plusieurs extensions personnalisées pour RocksDB afin de gérer des écritures et des lectures élevées, un modèle courant dans les charges de travail d'analyse en temps réel. L'une de ces extensions est le compactage à distance qui introduit une séparation nette entre le calcul des requêtes et le calcul de l'indexation dans RocksDB Cloud. Cela permet à Rockset d'éviter que les écritures n'interfèrent avec les lectures. Grâce à ces améliorations, Rockset peut adapter ses écritures en fonction des besoins des clients et rendre de nouvelles données disponibles pour les interrogations même lorsque des mutations se produisent en arrière-plan.

Mises à jour, insertions et suppressions à l'aide de l'API Rockset

Les utilisateurs de Rockset peuvent utiliser le champ _id par défaut ou spécifier un champ spécifique comme clé primaire. Ce champ permet d'écraser un document ou une partie de document. La différence entre Rockset et Elasticsearch est que Rockset peut mettre à jour la valeur d'un champ individuel sans nécessiter la réindexation d'un document entier.

Pour mettre à jour des documents existants dans une collection à l'aide de l'API Rockset, vous pouvez envoyer des requêtes au point de terminaison Patch Documents. Pour chaque document existant que vous souhaitez mettre à jour, il vous suffit de spécifier le champ _id et une liste d'opérations de correctifs à appliquer au document.

L'API Rockset expose également un point de terminaison Ajouter des documents afin que vous puissiez insérer des données directement dans vos collections à partir du code de votre application. Pour supprimer des documents existants, spécifiez simplement les champs _id des documents que vous souhaitez supprimer et faites une demande au point de terminaison Supprimer les documents de l'API Rockset.

Gestion des répliques dans Rockset

Contrairement à Elasticsearch, une seule réplique dans Rockset effectue l'indexation et le compactage à l'aide des compactages à distance RocksDB. Cela réduit la quantité de CPU requise pour l'indexation, en particulier lorsque plusieurs répliques sont utilisées pour des raisons de durabilité.

Réindexation dans Rockset

Au moment de l'ingestion dans Rockset, vous pouvez utiliser une transformation d'ingestion pour spécifier les transformations de données souhaitées à appliquer sur vos données sources brutes. Si vous souhaitez modifier la transformation d'ingestion ultérieurement, vous devrez réindexer vos données.

Cela dit, Rockset permetune ingestion sans schéma et tape dynamiquement les valeurs de chaque champ de données. Si la taille et la forme des données ou des requêtes changent, Rockset continuera à être performant et ne nécessitera pas de réindexation des données.

Rockset peut évoluer jusqu'à des centaines de téraoctets de données sans jamais avoir besoin d'être réindexé. Cela remonte à la stratégie de sharding de Rockset. Lorsque le calcul qu'un client alloue dans son instance virtuelle augmente, un sous-ensemble de fragments est mélangé pour obtenir une meilleure répartition sur le cluster, permettant une indexation et une exécution de requêtes plus parallélisées et plus rapides. Par conséquent, la réindexation n’a pas besoin d’avoir lieu dans ces scénarios.

Conclusion

Elasticsearch a été conçu pour l'analyse de journaux où les données ne sont pas fréquemment mises à jour, insérées ou supprimées. Au fil du temps, les équipes ont étendu leur utilisation d'Elasticsearch, utilisant souvent Elasticsearch comme magasin de données secondaire et moteur d'indexation pour des analyses en temps réel sur des données transactionnelles en constante évolution. Cela peut s'avérer coûteux, en particulier pour les équipes qui optimisent l'ingestion de données en temps réel, et impliquer une charge de gestion considérable.

Rockset, quant à lui, a été conçu pour l'analyse en temps réel et pour rendre les nouvelles données disponibles pour interrogation dans les 2 secondes suivant leur génération. Pour résoudre ce cas d'utilisation, Rockset prend en charge les insertions, mises à jour et suppressions sur place, économisant ainsi le calcul et limitant le recours à la réindexation des documents. Rockset reconnaît également la surcharge de gestion des connecteurs et de l'ingestion et adopte une approche de plate-forme, intégrant des connecteurs en temps réel dans son offre cloud.

Dans l'ensemble, nous avons vu des entreprises qui migrent d'Elasticsearch vers Rockset pour des analyses en temps réel économiser 44 % uniquement sur leur facture de calcul. Rejoignez la vague d'équipes d'ingénierie passant d'Elasticsearch à Rockset en quelques jours. Commencez votre essai gratuit aujourd'hui.