As traduções são geradas por tradução automática. Em caso de conflito entre o conteúdo da tradução e da versão original em inglês, a versão em inglês prevalecerá.

Pilar Eficiência de performance

O pilar de eficiência de desempenho do AWS Well-Architected Framework se concentra em como otimizar o desempenho ao ingerir ou consultar dados. A otimização da performance é um processo incremental e contínuo do seguinte:

O pilar de eficiência de performance fornece diretrizes específicas para casos de uso que podem ajudar a identificar o modelo de dados de grafos e as linguagens de consulta corretos a serem usados. Também inclui as práticas recomendadas a serem seguidas ao ingerir e consumir dados do Amazon Neptune.

O pilar de eficiência de performance foca estas áreas principais:

Compreensão da modelagem de grafos

Entenda a diferença entre os modelos Labeled Property Graph (LPG) e Resource Description Framework (RDF). Na maioria dos casos, é uma questão de preferência. No entanto, existem vários casos de uso em que um modelo é mais adequado do que o outro. Se você precisar de conhecimento do caminho que conecta dois nós em seu grafo, escolha LPG. Se você quiser federar dados em clusters do Neptune ou em outros armazenamentos triplos de grafos, escolha RDF.

Se você estiver criando um aplicação de software como serviço (SaaS) ou uma aplicação que exija multilocação, considere incorporar a separação lógica de locatários em seu modelo de dados em vez de ter um locatário para cada cluster. Para obter esse tipo de design, você pode usar grafos nomeados e estratégias de rotulagem do SPARQL, como prefixar identificadores de clientes em rótulos ou adicionar pares de chave/valor de propriedades representando identificadores de locatários. Certifique-se de que sua camada de cliente injete esses valores para manter essa separação lógica. Para obter mais informações sobre recomendações de multilocação, consulte Orientação de multilocação para executar bancos de dados Amazon ISVs Neptune.

A performance de suas consultas depende do número de objetos de grafos (nós, bordas, propriedades) que precisam ser avaliados no processamento de sua consulta. Dessa forma, o modelo de grafo pode ter um impacto significativo na performance da aplicação. Use rótulos granulares sempre que possível e armazene somente as propriedades necessárias para obter a determinação ou a filtragem do caminho. Para obter maior performance, considere pré-calcular partes do grafo, como criar nós de resumo ou bordas mais diretas conectando caminhos comuns.

Tente evitar navegar por nós que tenham um número anormalmente alto de bordas com o mesmo rótulo. Esses nós geralmente têm milhares de bordas (em que a maioria dos nós tem contagens de bordas na casa das dezenas). O resultado é uma complexidade muito maior de computação e dados. Esses nós podem não ser problemáticos em alguns padrões de consulta, mas recomendamos modelar seus dados de forma diferente para evitá-los, especialmente se você navegar pelo nó como uma etapa intermediária. Você pode usar os logs slow-query para ajudar a identificar consultas que navegam por esses nós. Você provavelmente observará métricas de latência e acesso a dados muito maiores do que seus padrões de consulta comuns, especialmente se usar o modo de depuração.

Use um nó determinístico IDs para nós e bordas se seu caso de uso oferecer suporte a isso, em vez de usar o Neptune para atribuir valores de GUID aleatórios para. IDs O acesso a nós por ID é o método mais eficiente.

Otimizar consultas

As linguagens openCypher e Gremlin podem ser usadas de forma intercambiável em modelos LPG. Se a performance for uma das principais preocupações, considere usar as duas linguagens de forma intercambiável, pois uma pode ter uma dperformance melhor do que a outra para padrões de consulta específicos.

O Neptune está em processo de conversão para seu mecanismo de consulta alternativo (DFE). O openCypher é executado somente no DFE, mas as consultas Gremlin e SPARQL podem ser configuradas opcionalmente para execução no DFE usando anotações de consulta. Considere testar suas consultas com o DFE ativado e comparar a performance do seu padrão de consulta quando não estiver usando o DFE.

O Neptune é otimizado para consultas do tipo transacional que começam em um único nó ou conjunto de nós e se espalham a partir daí, em vez de consultas analíticas que avaliam todo o grafo. Para suas cargas de trabalho de consultas analíticas, use o Neptune Analytics. O Neptune Analytics é a escolha ideal para cargas de trabalho investigatórias, exploratórias ou de ciência de dados que exigem iteração rápida para processamento de dados, analítico e algorítmico. Ele também pode realizar uma pesquisa vetorial em dados gráficos e carregar dados diretamente da sua instância de banco de dados Neptune. Se o Neptune Analytics não atender às suas necessidades, você também pode AWS considerar o SDK for Pandas ou usar o neptune-export combinado com o Amazon EMR. AWS Glue

Para identificar ineficiências e gargalos em seus modelos e consultas, use o profile e explain APIs para cada linguagem de consulta para obter explicações detalhadas sobre o plano de consulta e as métricas de consulta. Para obter mais informações, consulte Perfil do Gremlin, Explicação do openCypher e Explicação do SPARQL.

Entenda seus padrões de consulta. Se o número de bordas distintas em um grafo ficar grande, a estratégia de acesso padrão do Neptune poderá se tornar ineficiente. As consultas a seguir podem se tornar bastante ineficientes:

Use o registro em log slow-query para identificar consultas lentas. Consultas lentas podem ser causadas por planos de consulta não otimizados ou por um número desnecessariamente grande de pesquisas de índices, o que pode aumentar os custos. I/O A explicação e o perfil dos endpoints do Neptune para Gremlin, SPARQL ou openCypher podem ajudar você a entender por que essas consultas são lentas. As causas podem incluir as seguintes:

Se a otimização de consultas por si só não permitir que você atinja seus requisitos de performance, considere usar uma variedade de técnicas de armazenamento em cache com o Neptune para atingir esses requisitos.

O desempenho do Neptune está melhorando continuamente a cada versão. Revise as notas de lançamento para ver os detalhes das melhorias em cada versão. Considere planejar atualizações regulares em seu cluster de banco de dados Neptune para ajudar a alcançar o desempenho ideal. As versões mais recentes também oferecem suporte a instâncias mais novas. Considere fazer o upgrade para a versão 1.4.5.0 ou posterior para poder utilizar as instâncias. r8g Para obter mais informações sobre como isso pode melhorar o desempenho da sua carga de trabalho, consulte Preço-desempenho de consultas de gravação 4,7 vezes melhor com instâncias AWS Graviton4 R8g usando o Amazon Neptune v1.4.5.

Dimensionar corretamente os clusters

Dimensione seu cluster de acordo com seus requisitos de simultaneidade e throughput. O número de consultas simultâneas que podem ser processadas por cada instância no cluster é igual a duas vezes o número de virtual CPUs (vCPUs) nessa instância. Consultas adicionais que chegam enquanto todos os threads de trabalho estão ocupados são colocadas em uma fila do lado do servidor. Essas consultas são tratadas first-in-first-out (FIFO) quando os threads de trabalho são disponibilizados. A CloudWatch métrica da MainRequestQueuePendingRequests Amazon mostra a profundidade atual da fila para cada instância. Se esse valor estiver frequentemente acima de zero, considere escolher uma instância com mais CPUs v. Se a profundidade da fila exceder 8.192, o Neptune retornará um erro. ThrottlingException

Aproximadamente 65% da RAM de cada instância é reservada para o cache de buffer. O cache do buffer contém o conjunto de dados de trabalho (não o grafo todo; apenas os dados que estão sendo consultados). Para determinar qual porcentagem de dados está sendo obtida do cache de buffer em vez do armazenamento, monitore a CloudWatch métrica. BufferCacheHitRatio Se essa métrica geralmente cai abaixo de 99,9%, considere tentar uma instância com mais memória para determinar se ela diminui sua latência e seus custos. I/O

As réplicas de leitura não precisam ter o mesmo tamanho da sua instância do gravador. No entanto, workloads pesadas de gravação podem fazer com que réplicas menores fiquem atrasadas e sejam reinicializadas, pois não conseguem acompanhar a replicação. Por isso, recomendamos criar réplicas iguais ou maiores que a instância do gravador.

Ao usar o ajuste de escala automático para suas réplicas de leitura, lembre-se de que pode levar até 15 minutos para colocar uma nova réplica de leitura on-line. Quando o tráfego do cliente aumenta de forma rápida, mas previsível, considere usar a escalabilidade programada para definir um número mínimo de réplicas de leitura mais alto para considerar esse tempo de inicialização.

As instâncias sem servidor são compatíveis com diversos casos de uso e workloads. Considere instâncias provisionadas sem servidor para os seguintes cenários:

É importante observar que as instâncias sem servidor são mais caras do que as instâncias provisionadas equivalentes com base em um dólar por GB de RAM. Cada instância sem servidor consiste em 2 GB de RAM junto com a vCPU e a rede associadas. Faça uma análise de custos entre suas opções para evitar contas inesperadas. Em geral, você economizará custos sem servidor somente quando sua workload for muito pesada por apenas algumas horas por dia e quase zero no resto do dia, ou se sua workload flutuar significativamente ao longo do dia.

Utilize a calculadora de preços do Amazon Neptune para ajudar a avaliar a configuração correta do seu cluster com base em fatores queries-per-second como requisitos (QPS).

Otimizar as gravações

Para otimizar gravações, considere o seguinte: