Modelagem de dados no Elasticsearch: usando consultas aninhadas e relacionamentos pai-filho

A modelagem de dados no Elasticsearch não é tão óbvia quanto ao lidar com bancos de dados relacionais. Ao contrário dos bancos de dados relacionais tradicionais que dependem de normalização de dados e junções SQL, o Elasticsearch requer abordagens alternativas para gerenciar relacionamentos.

Existem quatro soluções alternativas comuns para gerenciar relacionamentos no Elasticsearch:

• Junções do lado do aplicativo

• Desnormalização de dados

• Tipos de campos aninhados e consultas aninhadas

• Relacionamentos pai-filho

  
  

Neste blog, discutiremos como você pode projetar seu modelo de dados para lidar com relacionamentos usando o tipo de campo aninhado e relacionamentos pai-filho. Abordaremos a arquitetura, as implicações de desempenho e os casos de uso dessas duas técnicas.

Tipos de campos aninhados e consultas aninhadas

Elasticsearch oferece suporte a estruturas aninhadas, onde objetos podem conter outros objetos. Os tipos de campos aninhados são objetos JSON no documento principal, que podem ter seus próprios campos e tipos distintos. Esses objetos aninhados são tratados como documentos ocultos separados que só podem ser acessados por meio de uma consulta aninhada.

Os tipos de campos aninhados são adequados para relacionamentos em que a integridade dos dados, o acoplamento próximo e a estrutura hierárquica são importantes. Estes incluem relacionamentos um-para-um e um-para-muitos, onde existe uma entidade principal. Por exemplo, representar uma pessoa e seus vários endereços e números de telefone em um único documento.

Com tipos de campo aninhados, o Elasticsearch armazena o documento inteiro, bem como objetos pai e aninhados, em um único bloco e segmento Lucene. Isso pode resultar em velocidades de consulta mais rápidas, pois o relacionamento está contido em um documento.

Exemplo de tipo de campo aninhado e consulta aninhada

Vejamos um exemplo de postagem de blog com comentários. Queremos aninhar os comentários abaixo da postagem do blog para que possam ser facilmente consultados juntos no mesmo documento.

GITHUB JULIE-MILLS

 { "post_id": "1", "title": "Introduction to Elasticsearch Data Modeling", "content": "Exploring various data modeling options in Elasticsearch.", "comments": [ { "comment_id": "101", "text": "Great overview of data modeling!" }, { "comment_id": "102", "text": "Looking forward to more content." } ] }

Benefícios dos tipos de campos aninhados e consultas aninhadas

Os benefícios dos relacionamentos de objetos aninhados incluem:

• Os dados são armazenados no mesmo bloco e segmento Lucene: armazenar objetos aninhados no mesmo bloco e segmento Lucene leva a consultas mais rápidas porque os dados são colocados.
• Integridade dos dados: como os relacionamentos são mantidos no mesmo documento, pode garantir a precisão nas consultas aninhadas.
• Modelo de dados de documento: fácil para desenvolvedores familiarizados com o modelo de dados NoSQL, onde você consulta documentos e dados aninhados neles.

Desvantagens dos tipos de campos aninhados e consultas aninhadas

• Ineficiência de atualização : atualizações, inserções e exclusões em qualquer parte de um documento com objetos aninhados exigem a reindexação de todo o documento, o que pode consumir muita memória, especialmente se os documentos forem grandes ou as atualizações forem frequentes.

  
  

• Desempenho de consulta com campos aninhados grandes : se você tiver documentos com campos aninhados particularmente grandes, isso pode ter implicações no desempenho. Isso ocorre porque a solicitação de pesquisa recupera o documento inteiro.

  
  

• Vários níveis de aninhamento podem se tornar complexos : a execução de consultas em estruturas aninhadas com vários níveis ainda pode se tornar complexa. Isso ocorre porque as consultas podem envolver consultas aninhadas dentro de consultas aninhadas, resultando em código menos legível.

Relacionamentos Pai-Filho

No mapeamento pai-filho, os documentos são organizados em tipos pai e filho. Cada documento filho tem uma associação direta com um documento pai. Esse relacionamento é estabelecido por meio de um valor de campo específico no documento filho que corresponde ao ID do pai. O modelo pai-filho adota uma abordagem descentralizada onde os documentos pai e filho existem de forma independente.

As junções pai-filho são adequadas para relacionamentos um-para-muitos ou muitos-para-muitos entre entidades. Imagine uma aplicação onde pretende criar relações entre empresas e contactos e pretende procurar empresas e contactos, bem como contactos de empresas específicas.

O Elasticsearch melhora o desempenho das junções pai-filho, monitorando quais pais estão conectados a quais filhos e fazendo com que ambas as entidades residam no mesmo fragmento. Ao localizar a operação de junção, o Elasticsearch evita a necessidade de comunicação extensa entre fragmentos, o que pode ser um gargalo de desempenho.

Exemplo de relacionamento entre pais e filhos

Vejamos o exemplo de um relacionamento pai-filho para postagens e comentários de blog. Cada postagem do blog, ou seja, dos pais, pode ter vários comentários, ou seja, dos filhos. Para criar o relacionamento pai-filho, vamos indexar os dados da seguinte forma:

 PUT my-index-000001 { "mappings": { "properties": { "post_id": { "type": "keyword" }, "post_id": { "type": "join", "relations": { "post": "comment" } } } } }

Um documento pai seria uma postagem parecida com esta:

 { "post_id": "1", "title": "Introduction to Elasticsearch Data Modeling", "content": "Exploring various data modeling options in Elasticsearch." }

O documento filho seria então um comentário que contém o post_id vinculando-o ao seu pai.

 { "comment_id": "101", "text": "Great overview of data modeling!", "post_id": "1" }

Benefícios do relacionamento entre pais e filhos

Os benefícios da modelagem pai-filho incluem:

• Assemelha-se ao modelo de dados relacional : nos relacionamentos pai-filho, os documentos pai e filho são separados e vinculados por um ID pai exclusivo. Essa configuração está mais próxima de um modelo de banco de dados relacional e pode ser mais intuitiva para quem está familiarizado com tais conceitos.

  
  

• Eficiência de atualização : os documentos filhos podem ser adicionados, modificados ou excluídos sem afetar o documento pai ou outros documentos filhos. Isto é particularmente benéfico ao lidar com um grande número de documentos secundários que requerem atualizações frequentes. Observe que associar um documento filho a um pai diferente é um processo mais complexo, pois o novo pai pode estar em outro fragmento.

  
  

• Mais adequado para filhos heterogêneos : como os documentos filhos são armazenados separadamente, eles podem ser mais eficientes em termos de memória e armazenamento, especialmente nos casos em que há muitos documentos filhos com diferenças significativas de tamanho.

Desvantagens do relacionamento entre pais e filhos

As desvantagens do relacionamento entre pais e filhos incluem:

• Consultas caras e lentas : unir documentos em índices separados adiciona trabalho computacional durante a execução da consulta, impactando novamente o desempenho. O Elasticsearch observa que as consultas pai-filho podem ser de 5 a 10 vezes mais lentas do que consultar objetos aninhados.

  
  

• Sobrecarga de mapeamento : os relacionamentos pai-filho podem consumir mais memória e recursos de cache. O Elasticsearch mantém um mapa de relacionamentos pai-filho, que pode crescer muito e consumir memória significativa, especialmente com um grande volume de documentos.

  
  

• Gerenciamento do tamanho do fragmento : como os documentos pai e filho residem no mesmo fragmento, há um risco potencial de distribuição desigual de dados no cluster. Alguns fragmentos podem ficar significativamente maiores que outros, especialmente se houver documentos pai com muitos filhos. Isso pode levar a desafios no gerenciamento e no dimensionamento do cluster Elasticsearch .

  
  

• Reindexação e manutenção de cluster : se você precisar reindexar dados ou alterar a estratégia de fragmentação , o relacionamento pai-filho pode complicar esse processo. Você precisará garantir que a integridade do relacionamento seja mantida durante tais operações. As tarefas rotineiras de manutenção de cluster, como rebalanceamento de fragmentos ou atualizações de nós, podem se tornar mais complexas. Deve-se tomar cuidado especial para garantir que as relações entre pais e filhos não sejam perturbadas durante esses processos.

  
  

Elastic , a empresa por trás do Elasticsearch, sempre recomendará que você faça junções no lado do aplicativo, desnormalização de dados e/ou objetos aninhados antes de seguir o caminho dos relacionamentos pai-filho.

Comparação de recursos de consultas aninhadas e relacionamentos pai-filho

A tabela abaixo fornece uma recapitulação das características dos tipos de campos aninhados e consultas e relacionamentos pai-filho para comparar as abordagens de modelagem de dados lado a lado.

Alternativas ao Elasticsearch para modelagem de relacionamento

Embora o Elasticsearch forneça diversas soluções alternativas para junções no estilo SQL , incluindo consultas aninhadas e relacionamentos pai-filho, está estabelecido que esses modelos não são bem dimensionados. Ao projetar aplicativos em escala, pode fazer sentido considerar uma abordagem alternativa com recursos nativos de junção SQL, Rockset .

Rockset é um banco de dados de pesquisa e análise projetado para pesquisa SQL, agregações e junções em quaisquer dados, incluindo dados JSON profundamente aninhados. À medida que os dados são transmitidos para o Rockset, eles são codificados nas principais estruturas de dados do banco de dados usadas para armazenar e indexar os dados para recuperação rápida. Rockset indexa os dados de uma forma que permite consultas rápidas, incluindo junções, usando seu otimizador de consulta baseado em SQL. Como resultado, não há necessidade de modelagem de dados inicial para dar suporte a junções SQL.

Um dos desafios do Elasticsearch é como preservar o relacionamento de maneira eficiente quando os dados são atualizados. Um dos motivos é que o Elasticsearch é construído no Apache Lucene, que armazena dados em segmentos imutáveis, fazendo com que todos os documentos precisem ser reindexados. Rockset usa RocksDB, um armazenamento de valor-chave de código aberto da Meta e construído para mutações de dados, para poder oferecer suporte eficiente a atualizações em nível de campo sem a necessidade de reindexar documentos inteiros.

Comparando Elasticsearch e Rockset usando um exemplo do mundo real

Vamos comparar a abordagem de relacionamento pai-filho no Elasticsearch com uma consulta SQL no Rockset.

No exemplo de relacionamento pai-filho acima, modelamos postagens com vários comentários criando dois tipos de documentos:

• postagens ou o tipo de documento pai

• comentários ou os tipos de documento filho

  
  

Usamos um identificador exclusivo, o ID pai, para estabelecer a relação entre os documentos pai e filho. No momento da consulta, usamos o Elasticsearch DSL para recuperar comentários de uma postagem específica.

No Rockset, os dados contendo postagens seriam armazenados em uma coleção, uma tabela no mundo relacional, enquanto os dados contendo comentários seriam armazenados em uma coleção separada. No momento da consulta, juntaríamos os dados usando uma consulta SQL.

Aqui estão as duas abordagens lado a lado:

Relacionamentos pai-filho no Elasticsearch

 POST /blog/posts/1 { "title": "Elasticsearch Modeling", "content": "A post about data modeling in Elasticsearch" } POST /blog/comments/2?parent=1 { "text": "Great post!" } POST /blog/comments/3?parent=1 { "text": "I learned a lot from this." }

Para recuperar uma postagem pelo título e todos os seus comentários, você precisaria criar uma consulta conforme a seguir.

 GET /posts/_search { "query": { "bool": { "must": [ { "match": { "title": "Exploring Elasticsearch Models" } } ] } }, "inner_hits": { "_source": ["text"], "name": "comments", "path": "comments" } }

SQL no Rockset

Para consultar esses dados, você só precisa escrever uma consulta SQL simples.

 SELECT p.title, p.content, c.text FROM posts p JOIN comments c ON p.post_id = c.post_id WHERE p.post_id = 1;

Se você tiver vários conjuntos de dados que precisam ser unidos para sua aplicação, o Rockset é mais simples e escalável que o Elasticsearch. Também simplifica as operações, pois você não precisa remodelar seus dados, gerenciar atualizações ou reindexar operações.

Gerenciando relacionamentos no Elasticsearch

Este blog forneceu uma visão geral dos tipos de campos aninhados e das consultas aninhadas, além dos relacionamentos pai-filho no Elasticsearch com o objetivo de ajudar você a determinar a melhor abordagem de modelagem de dados para sua carga de trabalho.

Os tipos de campos aninhados e consultas são úteis para relacionamentos um-para-um ou um-para-muitos, onde o relacionamento é mantido em um único documento. Esta é considerada uma abordagem mais simples e escalonável para gerenciamento de relacionamento.

O modelo de relacionamento pai-filho é mais adequado para relacionamentos um-para-muitos e muitos-para-muitos, mas apresenta maior complexidade, especialmente porque os relacionamentos precisam estar contidos em um fragmento específico.

Se um dos principais requisitos da sua aplicação for modelar relacionamentos, pode fazer sentido considerar o Rockset. Rockset simplifica a modelagem de dados e oferece uma abordagem mais escalável para gerenciamento de relacionamento usando junções SQL. Você pode comparar e contrastar o desempenho do Elasticsearch e do Rockset iniciando hoje uma avaliação gratuita com US$ 300 em créditos.