Accueil Big Data Puis-je effectuer des jointures de style SQL dans Elasticsearch ?

Puis-je effectuer des jointures de style SQL dans Elasticsearch ?

0
Puis-je effectuer des jointures de style SQL dans Elasticsearch ?


Recherche élastique est un moteur de recherche et d’analyse open source distribué basé sur JSON, construit à l’aide d’Apache Lucene dans le but de fournir une fonctionnalité de recherche rapide en temps réel. Il s’agit d’un magasin de données NoSQL orienté document, évolutif et sans schéma par défaut. Elasticsearch est conçu pour fonctionner à grande échelle avec de grands ensembles de données. En tant que moteur de recherche, il offre des capacités d’indexation et de recherche rapides qui peuvent être mises à l’échelle horizontalement sur plusieurs nœuds.

Prise sans vergogne : Ensemble de fusée est une base de données d’indexation en temps réel dans le cloud. Il crée automatiquement des index optimisés non seulement pour la recherche, mais également pour les agrégations et les jointures, ce qui permet à vos applications d’interroger les données rapidement et facilement, quels que soient leur origine et leur format. Mais cet article vise à mettre en évidence certaines solutions de contournement. , au cas où vous souhaiteriez vraiment effectuer des jointures de style SQL dans Elasticsearch.

Pourquoi les relations entre les données sont-elles importantes ?

Nous vivons dans un monde hautement connecté où la gestion des relations entre les données est importante. Les bases de données relationnelles sont efficaces pour gérer les relations, mais avec des exigences commerciales en constante évolution, le schéma fixe de ces bases de données entraîne des problèmes d’évolutivité et de performances. L’utilisation des magasins de données NoSQL devient de plus en plus populaire en raison de leur capacité à relever un certain nombre de défis associés aux approches traditionnelles de traitement des données.

Les entreprises sont continuellement confrontées à des structures de données complexes où des capacités d’agrégation, de jointure et de filtrage sont nécessaires pour analyser les données. Avec l’explosion des données non structurées, il existe un nombre croissant de cas d’utilisation nécessitant la fusion de données provenant de différentes sources à des fins d’analyse de données.

Bien que les jointures soient avant tout un concept SQL, elles sont également tout aussi importantes dans le monde NoSQL. Les jointures de style SQL ne sont pas prises en charge dans Elasticsearch en tant que citoyens de première classe. Cet article explique comment définir des relations dans Elasticsearch à l’aide de diverses techniques telles que la dénormalisation, les jointures côté application, les documents imbriqués et les relations parent-enfant. Il explorera également les cas d’utilisation et les défis associés à chaque approche.

Comment gérer les relations dans Elasticsearch

Etant donné qu’Elasticsearch n’est pas une base de données relationnelle, les jointures n’existent pas en tant que fonctionnalité native comme dans une base de données SQL. Il se concentre davantage sur l’efficacité de la recherche que sur l’efficacité du stockage. Les données stockées sont pratiquement aplaties ou dénormalisées pour permettre des cas d’utilisation de recherche rapide.

Il existe plusieurs façons de définir des relations dans Elasticsearch. En fonction de votre cas d’utilisation, vous pouvez sélectionner l’une des techniques ci-dessous dans Elasticsearch pour modéliser vos données :

  • Relations un-à-un : mappage d’objets
  • Relations un-à-plusieurs : documents imbriqués et modèle parent-enfant
  • Relations plusieurs-à-plusieurs : dénormalisation et jointures côté application

Les mappages d’objets un à un sont simples et ne seront pas beaucoup abordés ici. Le reste de ce blog couvrira plus en détail les deux autres scénarios.


Vous souhaitez en savoir plus sur les jointures dans Elasticsearch ? Vérifier notre article sur les cas d’utilisation courants


Gérer votre modèle de données dans Elasticsearch

Il existe quatre approches courantes pour gérer les données dans Elasticsearch :

  1. Dénormalisation
  2. Jointures côté application
  3. Objets imbriqués
  4. Relations parents-enfants

Dénormalisation

La dénormalisation offre les meilleures performances de recherche de requêtes dans Elasticsearch, car il n’est pas nécessaire de joindre des ensembles de données au moment de la requête. Chaque document est indépendant et contient toutes les données requises, éliminant ainsi le besoin d’opérations de jointure coûteuses.

Avec la dénormalisation, les données sont stockées dans une structure aplatie au moment de l’indexation. Cependant, cela augmente la taille du document et entraîne le stockage de données en double dans chaque document. L’espace disque n’est pas une denrée coûteuse et il n’y a donc pas lieu de s’inquiéter.

Cas d’utilisation pour la dénormalisation

Lorsque vous travaillez avec des systèmes distribués, le fait de devoir joindre des ensembles de données sur le réseau peut introduire des latences importantes. Vous pouvez éviter ces opérations de jointure coûteuses en dénormalisant les données. Les relations plusieurs-à-plusieurs peuvent être gérées par l’aplatissement des données.

Défis liés à la dénormalisation des données

  • La duplication de données dans des documents aplatis nécessite un espace de stockage supplémentaire.
  • La gestion des données dans une structure aplatie entraîne une surcharge supplémentaire pour les ensembles de données de nature relationnelle.
  • Du point de vue de la programmation, la dénormalisation nécessite une surcharge d’ingénierie supplémentaire. Vous devrez écrire du code supplémentaire pour aplatir les données stockées dans plusieurs tables relationnelles et les mapper à un seul objet dans Elasticsearch.
  • La dénormalisation des données n’est pas une bonne idée si vos données changent fréquemment. Dans de tels cas, la dénormalisation nécessiterait la mise à jour de tous les documents lorsqu’un sous-ensemble de données devait changer et devrait donc être évitée.
  • L’opération d’indexation prend plus de temps avec des ensembles de données aplatis, car davantage de données sont indexées. Si vos données changent fréquemment, cela indique que votre taux d’indexation est plus élevé, ce qui peut entraîner des problèmes de performances du cluster.

Jointures côté application

Les jointures côté application peuvent être utilisées lorsqu’il est nécessaire de maintenir la relation entre les documents. Les données sont stockées dans des index séparés et les opérations de jointure peuvent être effectuées du côté de l’application pendant la durée de la requête. Cela implique toutefois d’exécuter des requêtes supplémentaires au moment de la recherche à partir de votre application pour joindre des documents.

Cas d’utilisation des jointures côté application

Les jointures côté application garantissent que les données restent normalisées. Les modifications sont effectuées au même endroit et il n’est pas nécessaire de mettre constamment à jour vos documents. La redondance des données est minimisée avec cette approche. Cette méthode fonctionne bien lorsqu’il y a moins de documents et que les modifications de données sont moins fréquentes.

Défis liés aux jointures côté application

  • L’application doit exécuter plusieurs requêtes pour joindre des documents au moment de la recherche. Si l’ensemble de données comporte de nombreux consommateurs, vous devrez exécuter le même ensemble de requêtes plusieurs fois, ce qui peut entraîner des problèmes de performances. Cette approche n’exploite donc pas la véritable puissance d’Elasticsearch.
  • Cette approche entraîne une complexité au niveau de la mise en œuvre. Cela nécessite d’écrire du code supplémentaire au niveau de l’application pour implémenter des opérations de jointure afin d’établir une relation entre les documents.

Objets imbriqués

L’approche imbriquée peut être utilisée si vous devez conserver la relation de chaque objet du tableau. Les documents imbriqués sont stockés en interne sous forme de documents Lucene distincts et peuvent être joints au moment de la requête. Il s’agit de jointures indexées, dans lesquelles plusieurs documents Lucene sont stockés dans un seul bloc. Du point de vue de l’application, le bloc ressemble à un seul document Elasticsearch. L’interrogation est donc relativement plus rapide, puisque toutes les données résident dans le même objet. Les documents imbriqués traitent des relations un-à-plusieurs.

Cas d’utilisation des documents imbriqués

La création de documents imbriqués est préférable lorsque vos documents contiennent des tableaux d’objets. La figure 1 ci-dessous montre comment le type imbriqué dans Elasticsearch permet d’indexer en interne des tableaux d’objets en tant que documents Lucene distincts. Lucene n’a aucune notion d’objets internes, il est donc intéressant de voir comment Elasticsearch transforme en interne le document original en champs aplatis à valeurs multiples.

L’un des avantages de l’utilisation de requêtes imbriquées est qu’elles n’effectueront pas de correspondances entre objets, ce qui évite les résultats de correspondance inattendus. Il connaît les limites des objets, ce qui rend les recherches plus précises.


objets imbriqués elasticsearch

Figure 1 : Tableaux d’objets indexés en interne en tant que documents Lucene distincts dans Elasticsearch à l’aide d’une approche imbriquée

Défis avec les objets imbriqués

  • L’objet racine et ses objets imbriqués doivent être complètement réindexés afin d’ajouter/mettre à jour/supprimer un objet imbriqué. En d’autres termes, une mise à jour d’un enregistrement enfant entraînera une réindexation de l’intégralité du document.
  • Les documents imbriqués ne sont pas accessibles directement. Ils ne sont accessibles que par le document racine associé.
  • Les requêtes de recherche renvoient l’intégralité du document au lieu de renvoyer uniquement les documents imbriqués qui correspondent à la requête de recherche.
  • Si votre ensemble de données change fréquemment, l’utilisation de documents imbriqués entraînera un grand nombre de mises à jour.

Relations parents-enfants

Les relations parents-enfants exploitent rejoindre le type de données afin de séparer complètement les objets avec des relations en documents individuels : parent et enfant. Cela vous permet de stocker des documents dans une structure relationnelle dans des documents Elasticsearch distincts qui peuvent être mis à jour séparément.

Les relations parents-enfants sont bénéfiques lorsque les documents doivent être mis à jour souvent. Cette approche est donc idéale pour les scénarios où les données changent fréquemment. Fondamentalement, vous séparez le document de base en plusieurs documents contenant le parent et l’enfant. Cela permet aux documents parent et enfant d’être indexés/mis à jour/supprimés indépendamment les uns des autres.

Recherche dans les documents parents et enfants

Pour optimiser les performances d’Elasticsearch lors de l’indexation et de la recherche, la recommandation générale est de s’assurer que la taille du document n’est pas importante. Vous pouvez tirer parti du modèle parent-enfant pour diviser votre document en documents distincts.

Cependant, la mise en œuvre de cette mesure présente certains défis. Les documents parents et enfants doivent être acheminés vers la même partition afin que leur jonction pendant la requête soit en mémoire et efficace. L’ID parent doit être utilisé comme valeur de routage pour le document enfant. Le _parent Le champ fournit à Elasticsearch l’ID et le type du document parent, ce qui lui permet d’acheminer en interne les documents enfants vers la même partition que le document parent.

Elasticsearch vous permet d’effectuer des recherches à partir d’objets JSON complexes. Cela nécessite toutefois une compréhension approfondie de la structure des données pour pouvoir y effectuer des requêtes efficaces. Le modèle parent-enfant exploite plusieurs filtres pour simplifier la fonctionnalité de recherche :

Renvoie les documents parents dont les documents enfants correspondent à la requête.

Accepte un parent et renvoie les documents enfants auxquels les parents associés correspondent.

Récupère les informations pertinentes sur les enfants à partir du has_child requête.

La figure 2 montre comment utiliser le modèle parent-enfant pour démontrer les relations un-à-plusieurs. Les documents enfants peuvent être ajoutés/supprimés/mis à jour sans impact sur le parent. Il en va de même pour le document parent, qui peut être mis à jour sans réindexer les enfants.


elasticsearch-parent-enfant

Figure 2 : Modèle parent-enfant pour les relations un-à-plusieurs

Défis liés aux relations parents-enfants

  • Les requêtes sont plus coûteuses et gourmandes en mémoire en raison de l’opération de jointure.
  • Les constructions parent-enfant entraînent une surcharge, car ce sont des documents distincts qui doivent être joints au moment de la requête.
  • Il faut s’assurer que le parent et tous ses enfants existent sur la même partition.
  • Le stockage de documents avec des relations parent-enfant implique une complexité de mise en œuvre.

Conclusion

Choisir le bon Elasticsearch la modélisation des données la conception est essentielle pour les performances et la maintenabilité des applications. Lors de la conception de votre modèle de données dans Elasticsearch, il est important de noter les différents avantages et inconvénients de chacune des quatre méthodes de modélisation décrites ici.

Dans cet article, nous avons exploré comment les objets imbriqués et les relations parent-enfant permettent des opérations de jointure de type SQL dans Elasticsearch. Vous pouvez également implémenter une logique personnalisée dans votre application pour gérer les relations avec les jointures côté application. Pour les cas d’utilisation dans lesquels vous devez joindre plusieurs ensembles de données dans Elasticsearch, vous pouvez ingérer et charger ces deux ensembles de données dans l’index Elasticsearch pour permettre des requêtes performantes.

Prêt à l’emploi, Elasticsearch n’a pas de jointures comme dans une base de données SQL. Bien qu’il existe des solutions potentielles pour établir des relations dans vos documents, il est important d’être conscient des défis que présente chacune de ces approches.


Blogue du CTA Sequoia Capital

Utilisation des jointures SQL natives avec Rockset

Lorsqu’il est nécessaire de combiner plusieurs ensembles de données pour une analyse en temps réel, une base de données qui fournit des jointures SQL natives peut mieux gérer ce cas d’utilisation. Comme Elasticsearch, Rockset est utilisé comme couche d’indexation sur les données provenant de bases de données, de flux d’événements et de lacs de données, permettant une ingestion sans schéma à partir de ces sources. Contrairement à Elasticsearch, Rockset offre la possibilité de requête avec SQL complety compris les jointures, vous offrant ainsi une plus grande flexibilité dans la manière dont vous pouvez utiliser vos données.



LAISSER UN COMMENTAIRE

S'il vous plaît entrez votre commentaire!
S'il vous plaît entrez votre nom ici