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 do desempenho é um processo incremental e contínuo do seguinte:

• Confirmando os requisitos de negócios

• Medindo o desempenho da carga de trabalho

• Identificação de componentes com baixo desempenho

• Ajustando os componentes para atender às necessidades de sua empresa

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

O pilar de eficiência de desempenho se concentra nas seguintes áreas principais:

• Modelagem gráfica

• Otimização de consultas

• Dimensionamento correto do cluster

• Otimização de gravação

Entenda a modelagem gráfica

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 gráfico, escolha LPG. Se você quiser federar dados em clusters do Neptune ou em outros armazenamentos gráficos triplos, escolha RDF.

Se você estiver criando um aplicativo de software como serviço (SaaS) ou um aplicativo que exija multilocação, considere incorporar a separação lógica de locatários em seu modelo de dados em vez de ter um inquilino para cada cluster. Para obter esse tipo de design, você pode usar gráficos nomeados e estratégias de rotulagem do SPARQL, como prefixar identificadores de clientes em rótulos ou adicionar pares de valores-chave de propriedades representando identificadores de inquilinos. Certifique-se de que sua camada de cliente injete esses valores para manter essa separação lógica.

O desempenho de suas consultas depende do número de objetos gráficos (nós, bordas, propriedades) que precisam ser avaliados no processamento de sua consulta. Dessa forma, o modelo gráfico pode ter um impacto significativo no desempenho do seu aplicativo. 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 desempenho, considere pré-calcular partes do gráfico, 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 (onde a maioria dos nós tem contagens de arestas 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 registros de consultas lentas 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 Acessar 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 de GLP. Se o desempenho for uma das principais preocupações, considere usar as duas linguagens de forma intercambiável, pois uma pode ter um desempenho 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 o desempenho 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 o gráfico inteiro. Para suas cargas de trabalho de consultas analíticas, considere usar o AWS SDK para 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 arestas distintas em um gráfico se tornar grande, a estratégia de acesso padrão do Neptune pode se tornar ineficiente. As consultas a seguir podem se tornar bastante ineficientes:

• Consultas que navegam para trás pelas bordas quando nenhum rótulo de borda é fornecido.

• Cláusulas que usam esse mesmo padrão internamente, como .both() no Gremlin, ou cláusulas que eliminam nós em qualquer linguagem (o que exige a eliminação das bordas de entrada sem o conhecimento dos rótulos).

• Consultas que acessam valores de propriedades sem especificar rótulos de propriedades. Essas consultas podem se tornar bastante ineficientes. Se isso corresponder ao seu padrão de uso, considere ativar o índice OSGP (objeto, assunto, gráfico, predicado).

Use o registro de consultas lentas 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 índice, o que pode aumentar os custos de E/S. 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 o seguinte:

• Os nós com um número anormalmente alto de bordas em comparação com o nó médio no gráfico (por exemplo, milhares em comparação com dezenas) podem adicionar complexidade computacional e, portanto, maior latência e maior consumo de recursos. Determine se esses nós estão modelados corretamente ou se os padrões de acesso podem ser aprimorados para reduzir o número de bordas que devem ser percorridas.

• As consultas não otimizadas conterão um aviso de que etapas específicas não estão otimizadas. Reescrever essas consultas para usar etapas otimizadas pode melhorar o desempenho.

• Filtros redundantes podem causar pesquisas de índice desnecessárias. Da mesma forma, padrões redundantes podem causar pesquisas de índice duplicadas que podem ser otimizadas melhorando a consulta (veja Index Operations - Duplication ratio na saída do perfil).

• Alguns idiomas, como o Gremlin, não têm valores numéricos fortemente digitados e, em vez disso, usam a promoção de tipos. Por exemplo, se o valor for 55, Neptune procurará valores que sejam inteiros, longos, flutuantes e outros tipos numéricos equivalentes a 55. Isso resulta em operações adicionais. Se você souber que seus tipos coincidem com antecedência, você pode evitar isso usando uma dica de consulta.

• Seu modelo gráfico pode impactar muito o desempenho. Considere reduzir o número de objetos que precisam ser avaliados usando rótulos mais granulares ou pré-calculando atalhos para caminhos lineares de vários saltos.

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

Clusters do tamanho certo

Dimensione seu cluster de acordo com seus requisitos de simultaneidade e taxa de transferência. 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 segmentos 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 por cento 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 gráfico inteiro; 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 a latência e os custos de E/S.

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

Ao usar o auto-scaling 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 oferecem suporte a vários casos de uso e cargas de trabalho diferentes. Considere instâncias provisionadas sem servidor para os seguintes cenários:

• Sua carga de trabalho flutua com frequência ao longo do dia.

• Você criou um novo aplicativo e não tem certeza de qual será o tamanho da carga de trabalho.

• Você está realizando desenvolvimento e testes.

É 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 carga de trabalho for muito pesada por apenas algumas horas por dia e quase zero no resto do dia ou se sua carga de trabalho flutuar significativamente ao longo do dia.

Otimize gravações

Para otimizar as gravações, considere o seguinte:

• O Neptune Bulk Loader é a maneira ideal de carregar inicialmente seu banco de dados ou anexar dados existentes. O carregador Neptune não é transacional e não pode excluir dados, portanto, não o use se esses forem seus requisitos.

• As atualizações transacionais podem ser feitas usando os idiomas de consulta compatíveis. Para otimizar as operações de E/S de gravação, grave dados em lotes de 50 a 100 objetos por confirmação. Um objeto é um nó, uma borda ou uma propriedade em um nó ou borda no GLP, ou um armazenamento triplo ou um quádruplo no RDF..

• Todas as operações de gravação do Neptune são de thread único para cada conexão. Ao enviar uma grande quantidade de dados para Neptune, considere ter várias conexões paralelas, cada uma gravando dados. Quando você escolhe uma instância provisionada pelo Neptune, o tamanho da instância é associado a um número de v. CPUs O Neptune cria dois threads de banco de dados para cada vCPU na instância, então comece com o dobro do número de CPUs v ao testar a paralelização ideal.  As instâncias sem servidor escalam o número de v CPUs a uma taxa de aproximadamente uma para cada 4. NCUs

• Planeje e gerencie com ConcurrentModificationExceptionseficiência todos os processos de gravação, mesmo que apenas uma única conexão esteja gravando dados a qualquer momento. Projete seus clientes para que sejam confiáveis quando ConcurrentModificationExceptions ocorrerem.

• Se você quiser excluir todos os seus dados, considere usar a API de reinicialização rápida em vez de emitir consultas de exclusão simultâneas. O último levará muito mais tempo e terá um custo substancial de E/S em comparação com o anterior.

• Se você quiser excluir a maioria dos seus dados, considere exportar os dados que deseja manter usando o neptune-export para carregar os dados em um novo cluster. Em seguida, exclua o cluster original.