A modelagem de dados no 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. Elasticsearch 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 : 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. Ineficiência de atualização atualizações, inserções e exclusões : 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. Desempenho de consulta com campos aninhados grandes : 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. Vários níveis de aninhamento podem se tornar complexos 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: : 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. Assemelha-se ao modelo de dados relacional : 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. Eficiência de atualização : 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. Mais adequado para filhos heterogêneos Desvantagens do relacionamento entre pais e filhos As desvantagens do relacionamento entre pais e filhos incluem: : unir documentos em índices separados adiciona trabalho computacional durante a execução da consulta, impactando novamente o desempenho. observa que as consultas pai-filho podem ser de 5 a 10 vezes mais lentas do que consultar objetos aninhados. Consultas caras e lentas O Elasticsearch : 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. Sobrecarga de mapeamento : 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 . Gerenciamento do tamanho do fragmento no dimensionamento do cluster Elasticsearch : se você precisar , 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. Reindexação e manutenção de cluster reindexar dados ou alterar a estratégia de fragmentação , 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. Elastic 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. Tipos de campos aninhados e consultas aninhadas Relacionamentos pai-filho Definição Aninha um objeto dentro de outro objeto Vincula documentos pai e filho Relacionamentos Um para um, um para muitos Um para muitos, muitos para muitos Velocidade de consulta Geralmente mais rápido que os relacionamentos pai-filho, pois os dados são armazenados no mesmo bloco e segmento Geralmente 5 a 10 vezes mais lento que objetos aninhados, pois os documentos pai e filho são unidos no momento da consulta. Flexibilidade de consulta Menos flexível que consultas pai-filho, pois limita o escopo da consulta dentro dos limites de cada objeto aninhado Oferece mais flexibilidade na consulta, pois os documentos pai ou filho podem ser consultados juntos ou separadamente Atualizações de dados A atualização de objetos aninhados exigia a reindexação de todo o documento A atualização de documentos secundários é mais fácil, pois não exige que todos os documentos sejam reindexados Gerenciamento Gerenciamento mais simples, pois tudo está contido em um único documento Mais complexo de gerenciar devido à indexação separada e à manutenção de relacionamentos entre documentos pai e filho Casos de uso Armazene e consulte dados complexos com vários níveis de hierarquia Relacionamentos onde há poucos pais e muitos filhos, como produtos e análises de produtos Alternativas ao Elasticsearch para modelagem de relacionamento Embora o Elasticsearch forneça diversas soluções alternativas para , 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, . junções no estilo 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 no Rockset. consulta SQL 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 com US$ 300 em créditos. iniciando hoje uma avaliação gratuita
