Partilhar via

Modelagem de dados de gráfico com o Azure Cosmos DB para Apache Gremlin

  • Artigo

APLICA-SE A: Gremlin

Este artigo fornece recomendações para o uso de modelos de dados gráficos. Essas práticas recomendadas são vitais para garantir a escalabilidade e o desempenho de um sistema de banco de dados gráfico à medida que os dados evoluem. Um modelo de dados eficiente é especialmente importante para gráficos de grande escala.

Requisitos

O processo descrito neste guia baseia-se nos seguintes pressupostos:

  • As entidades no espaço-problema são identificadas. Essas entidades devem ser consumidas atomicamente para cada solicitação. Em outras palavras, o sistema de banco de dados não foi projetado para recuperar os dados de uma única entidade em várias solicitações de consulta.
  • Há uma compreensão dos requisitos de leitura e gravação para o sistema de banco de dados. Esses requisitos orientam as otimizações necessárias para o modelo de dados gráfico.
  • Os princípios do padrão de gráfico de propriedade Apache Tinkerpop são bem compreendidos.

Quando preciso de um banco de dados gráfico?

Uma solução de banco de dados gráfico pode ser usada de forma ideal se as entidades e relacionamentos em um domínio de dados tiverem qualquer uma das seguintes características:

  • As entidades estão altamente conectadas através de relações descritivas. O benefício nesse cenário é que os relacionamentos persistem no armazenamento.
  • Existem relações cíclicas ou entidades autorreferenciadas. Esse padrão geralmente é um desafio quando você usa bancos de dados relacionais ou de documentos.
  • Existem relações dinâmicas entre entidades. Esse padrão é especialmente aplicável a dados hierárquicos ou estruturados em árvore com muitos níveis.
  • Existem relações muitos-para-muitos entre entidades.
  • Há requisitos de escrita e leitura em entidades e relacionamentos.

Se os critérios acima forem atendidos, uma abordagem de banco de dados gráfico provavelmente fornecerá vantagens para a complexidade da consulta, a escalabilidade do modelo de dados e o desempenho da consulta.

O próximo passo é determinar se o gráfico será usado para fins analíticos ou transacionais. Se o gráfico se destina a ser usado para cargas de trabalho pesadas de computação e processamento de dados, vale a pena explorar o conector Cosmos DB Spark e a biblioteca GraphX.

Como usar objetos gráficos

O padrão de gráfico de propriedade Apache Tinkerpop define dois tipos de objetos: vértices e arestas.

A seguir estão as práticas recomendadas para as propriedades nos objetos de gráfico:

Object Propriedade Type Notas
Modelo de ID String Imposto exclusivamente por partição. Se um valor não for fornecido durante a inserção, um GUID gerado automaticamente será armazenado.
Modelo de Etiqueta String Esta propriedade é usada para definir o tipo de entidade que o vértice representa. Se um valor não for fornecido, um vértice de valor padrão será usado.
Modelo de Propriedades Corda, booleana, numérica Uma lista de propriedades separadas armazenadas como pares chave-valor em cada vértice.
Modelo de Chave de partição Corda, booleana, numérica Esta propriedade define onde o vértice e suas bordas de saída são armazenados. Leia mais sobre particionamento de gráficos.
Edge ID String Imposto exclusivamente por partição. Gerado automaticamente por padrão. As bordas geralmente não precisam ser recuperadas exclusivamente por um ID.
Edge Etiqueta String Esta propriedade é usada para definir o tipo de relação que dois vértices têm.
Edge Propriedades Corda, booleana, numérica Uma lista de propriedades separadas armazenadas como pares chave-valor em cada borda.

Nota

As bordas não exigem um valor de chave de partição, uma vez que o valor é atribuído automaticamente com base em seu vértice de origem. Saiba mais em Usando um gráfico particionado no Azure Cosmos DB.

Diretrizes de modelagem de entidade e relacionamento

As diretrizes a seguir ajudam você a abordar a modelagem de dados para um banco de dados gráfico do Azure Cosmos DB for Apache Gremlin . Essas diretrizes pressupõem que existe uma definição existente de um domínio de dados e consultas para ele.

Nota

As etapas a seguir são apresentadas como recomendações. Você deve avaliar e testar o modelo final antes de considerá-lo pronto para produção. Além disso, as recomendações são específicas para a implementação da API Gremlin do Azure Cosmos DB.

Modelação de vértices e propriedades

A primeira etapa para um modelo de dados de gráfico é mapear cada entidade identificada para um objeto de vértice. Um mapeamento um-para-um de todas as entidades para vértices deve ser um passo inicial e sujeito a alterações.

Uma armadilha comum é mapear propriedades de uma única entidade como vértices separados. Considere o exemplo a seguir, onde a mesma entidade é representada de duas maneiras diferentes:

  • Propriedades baseadas em vértice: Nesta abordagem, a entidade usa três vértices separados e duas arestas para descrever suas propriedades. Embora essa abordagem possa reduzir a redundância, ela aumenta a complexidade do modelo. Um aumento na complexidade do modelo pode resultar em latência adicional, complexidade de consulta e custo de computação. Este modelo também pode apresentar desafios no particionamento.

    Diagrama de modelo de entidade com vértices para propriedades.

  • Vértices incorporados à propriedade: essa abordagem aproveita a lista de pares chave-valor para representar todas as propriedades da entidade dentro de um vértice. Essa abordagem reduz a complexidade do modelo, o que leva a consultas mais simples e a travessias mais econômicas.

    Diagrama do vértice de Luis do diagrama anterior com ID, rótulo e propriedades.

Nota

Os diagramas anteriores mostram um modelo de gráfico simplificado que compara apenas as duas maneiras de dividir as propriedades da entidade.

O padrão de vértices embutidos na propriedade geralmente fornece uma abordagem mais eficiente e escalável. A abordagem padrão para um novo modelo de dados de gráfico deve gravitar em direção a esse padrão.

No entanto, há cenários em que referenciar uma propriedade pode oferecer vantagens. Por exemplo, se a propriedade referenciada for atualizada com frequência. Use um vértice separado para representar uma propriedade que está mudando constantemente para minimizar a quantidade de operações de gravação que a atualização exige.

Modelos de relacionamento com direções de borda

Depois que os vértices são modelados, as arestas podem ser adicionadas para denotar as relações entre eles. O primeiro aspeto que precisa ser avaliado é o rumo da relação.

Os objetos de borda têm uma direção padrão que é seguida por uma travessia ao usar as out() funções or outE() . Usando esta direção natural resulta em uma operação eficiente, uma vez que todos os vértices são armazenados com suas bordas de saída.

No entanto, percorrer na direção oposta de uma borda, usando a in() função, sempre resulta em uma consulta de partição cruzada. Saiba mais sobre particionamento de gráficos. Se houver a necessidade de percorrer constantemente usando a in() função, recomenda-se adicionar bordas em ambas as direções.

Você pode determinar a direção da borda usando os .to() predicados ou .from() com a .addE() etapa Gremlin. Ou usando a biblioteca de executores em massa para a API Gremlin.

Nota

Os objetos de borda têm uma direção por padrão.

Rótulos de relacionamento

O uso de rótulos de relacionamento descritivos pode melhorar a eficiência das operações de resolução de borda. Você pode aplicar esse padrão das seguintes maneiras:

  • Use termos não genéricos para rotular uma relação.
  • Associe o rótulo do vértice de origem ao rótulo do vértice de destino com o nome da relação.

Diagrama de exemplos de rotulagem de relacionamentos.

Quanto mais específico for o rótulo que o traversor utilizar para filtrar as arestas, melhor. Essa decisão também pode ter um efeito significativo no custo da consulta. Você pode avaliar o custo da consulta a qualquer momento usando a etapa executionProfile.

Próximos passos