Modelação de dados de gráficos com o Azure Cosmos DB para Apache Gremlin

APLICA-SE A: Gremlin

Este artigo fornece recomendações para a utilização de modelos de dados de gráficos. Estas melhores práticas são vitais para garantir a escalabilidade e o desempenho de um sistema de bases de dados de grafos à medida que os dados evoluem. Um modelo de dados eficiente é especialmente importante para gráficos em grande escala.

Requisitos

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

  • As entidades no espaço de problemas são identificadas. Estas entidades destinam-se a ser consumidas atomicamente para cada pedido. Por outras palavras, o sistema de bases de dados não foi concebido para obter os dados de uma única entidade em vários pedidos de consulta.
  • Existe uma compreensão dos requisitos de leitura e escrita para o sistema de bases de dados. Estes requisitos orientam as otimizações necessárias para o modelo de dados de gráficos.
  • Os princípios do padrão do gráfico de propriedades do Apache Tinkerpop são bem compreendidos.

Quando preciso de uma base de dados de gráficos?

Uma solução de base de dados de grafos pode ser utilizada da melhor forma se as entidades e as relações num domínio de dados tiverem qualquer uma das seguintes características:

  • As entidades estão altamente ligadas através de relações descritivas. O benefício neste cenário é que as relações persistem no armazenamento.
  • Existem relações cíclicas ou entidades auto-referenciadas. Este padrão é, muitas vezes, um desafio quando utiliza bases de dados relacionais ou de documentos.
  • Existem relações dinâmicas em evolução entre entidades. Este padrão é especialmente aplicável a dados hierárquicos ou estruturados em árvores com muitos níveis.
  • Existem relações muitos-para-muitos entre entidades.
  • Existem requisitos de escrita e leitura nas entidades e nas relações.

Se os critérios acima forem cumpridos, é provável que uma abordagem de base de dados de gráficos proporcione vantagens para a complexidade das consultas, a escalabilidade do modelo de dados e o desempenho das consultas.

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

Como utilizar objetos de grafos

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

Seguem-se as melhores práticas para as propriedades nos objetos de grafos:

Objeto Propriedade Tipo Notas
Vértice ID String Imposto exclusivamente por partição. Se um valor não for fornecido após a inserção, é armazenado um GUID gerado automaticamente.
Vértice Etiqueta String Esta propriedade é utilizada para definir o tipo de entidade que o vértice representa. Se não for fornecido um valor, é utilizado um vértice de valor predefinido.
Vértice Propriedades Cadeia, booleana, numérica Uma lista de propriedades separadas armazenadas como pares chave-valor em cada vértice.
Vértice Chave de partição Cadeia, booleana, numérica Esta propriedade define onde o vértice e as respetivas arestas de saída são armazenados. Leia mais sobre a criação de partições de grafos.
Microsoft Edge ID String Imposto exclusivamente por partição. Gerado automaticamente por predefinição. Normalmente, as arestas não precisam de ser obtidas exclusivamente por um ID.
Microsoft Edge Etiqueta String Esta propriedade é utilizada para definir o tipo de relação que dois vértices têm.
Microsoft Edge Propriedades Cadeia, booleana, numérica Uma lista de propriedades separadas armazenadas como pares chave-valor em cada aresta.

Nota

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

Diretrizes de modelação de entidades e relações

As diretrizes seguintes ajudam-no a abordar a modelação de dados para uma base de dados de gráficos do Azure Cosmos DB para Apache Gremlin . Estas diretrizes partem do princípio de que existe uma definição existente de um domínio de dados e consultas para o mesmo.

Nota

Os passos seguintes são apresentados como recomendações. Deve avaliar e testar o modelo final antes de o considerar como preparado para produção. Além disso, as recomendações são específicas da implementação da API do Gremlin do Azure Cosmos DB.

Modelação de vértices e propriedades

O primeiro passo para um modelo de dados de grafos é mapear todas as entidades identificadas para um objeto de vértice. Um mapeamento um-para-um de todas as entidades para vértices deve ser um passo inicial e estar sujeito a alterações.

Uma armadilha comum é mapear propriedades de uma única entidade como vértices separados. Considere o exemplo seguinte, em que a mesma entidade é representada de duas formas diferentes:

  • Propriedades baseadas em vértice: nesta abordagem, a entidade utiliza três vértices separados e duas arestas para descrever as respetivas propriedades. Embora esta abordagem possa reduzir a redundância, aumenta a complexidade do modelo. Um aumento da complexidade do modelo pode resultar numa latência adicional, complexidade de consultas e custos de computação. Este modelo também pode apresentar desafios na criação de partições.

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

  • Vértices incorporados em propriedades: esta abordagem tira partido da lista de pares chave-valor para representar todas as propriedades da entidade dentro de um vértice. Esta abordagem reduz a complexidade dos modelos, o que leva a consultas mais simples e percursos mais económicos.

    Diagrama do vértice luis do diagrama anterior com o ID, a etiqueta e as propriedades.

Nota

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

Geralmente, o padrão de vértices incorporados em propriedades fornece uma abordagem mais eficaz e dimensionável. A abordagem predefinida para um novo modelo de dados de grafos deve gravitar para este padrão.

No entanto, existem cenários em que referenciar uma propriedade pode proporcionar vantagens. Por exemplo, se a propriedade referenciada for atualizada com frequência. Utilize um vértice separado para representar uma propriedade que está em constante alteração para minimizar a quantidade de operações de escrita necessárias para a atualização.

Modelos de relações com direções de limite

Depois de modelar os vértices, as arestas podem ser adicionadas para denotar as relações entre os mesmos. O primeiro aspeto que tem de ser avaliado é a direção da relação.

Os objetos edge têm uma direção predefinida que é seguida por um percurso ao utilizar as out() funções ou outE() . A utilização desta direção natural resulta numa operação eficiente, uma vez que todos os vértices são armazenados com as arestas de saída.

No entanto, percorrer na direção oposta de uma extremidade, utilizando a in() função, resulta sempre numa consulta entre partições. Saiba mais sobre a criação de partições de grafos. Se for necessário atravessar constantemente com a in() função, recomenda-se que adicione arestas em ambas as direções.

Pode determinar a direção da extremidade com os .to() predicados ou .from() com o .addE() passo Gremlin. Em alternativa, utilize a biblioteca do executor em massa para a API do Gremlin.

Nota

Os objetos edge têm uma direção por predefinição.

Etiquetas de relação

A utilização de etiquetas de relações descritivas pode melhorar a eficiência das operações de resolução do edge. Pode aplicar este padrão das seguintes formas:

  • Utilize termos não genéricos para etiquetar uma relação.
  • Associe a etiqueta do vértice de origem à etiqueta do vértice de destino ao nome da relação.

Diagrama de exemplos de etiquetagem de relações.

Quanto mais específica for a etiqueta que o percurso utiliza para filtrar as arestas, melhor. Esta decisão também pode ter um efeito significativo no custo da consulta. Pode avaliar o custo da consulta em qualquer altura com o passo executionProfile.

Passos seguintes