Elasticsearch est un moteur de recherche et d'analyse open source distribué basé sur , construit à l'aide d'Apache Lucene pour 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. JSON Prise sans vergogne : 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. Rockset 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 plusieurs 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. Gérer votre modèle de données dans Elasticsearch Il existe quatre approches courantes pour gérer les données dans Elasticsearch : Dénormalisation Jointures côté application Objets imbriqués 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. 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 parent-enfant exploitent le afin de séparer complètement les objets ayant 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. type de données de jointure 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 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. _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 : requête has_child Renvoie les documents parents dont les documents enfants correspondent à la requête. requête has_parent Accepte un parent et renvoie les documents enfants auxquels les parents associés correspondent. requête inner_hits Récupère les informations pertinentes sur les enfants à partir de la requête . has_child 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. 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 la bonne conception Elasticsearch est essentiel 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. de modélisation de données 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. Utilisation des jointures SQL natives avec Rockset Lorsqu'il est nécessaire de combiner plusieurs ensembles de données pour des analyses en temps réel, une base de données fournissant 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é d' , y compris des jointures, vous offrant ainsi une plus grande flexibilité dans la manière dont vous pouvez utiliser vos données. effectuer des requêtes avec des fonctionnalités SQL complètes Également publié . ici
