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á.
# Práticas recomendadas: aproveitar ao máximo o Neptune
Veja algumas recomendações gerais para trabalhar com o Amazon Neptune. Use essas informações como referência para localizar rapidamente as recomendações para o uso do Amazon Neptune e maximizar o desempenho.
**Contents**
+ [Diretrizes operacionais básicas do Amazon Neptune](best-practices-general-basic.md)
+ [Práticas recomendadas de segurança para o Amazon Neptune](best-practices-general-security.md)
+ [Evitar classes de instância diferentes em um cluster](best-practices-general-basic.md#best-practices-loader-heterogeneous-instances)
+ [Evitar reinicializações repetidas durante o carregamento em massa](best-practices-general-basic.md#best-practices-loader-repeated-restarts)
+ [Habilitar o Índice OSGP se você tiver um grande número de predicados](best-practices-general-basic.md#best-practices-general-predicates)
+ [Evitar transações de longa execução quando possível](best-practices-general-basic.md#best-practices-general-long-running-transactions)
+ [Práticas recomendadas para o uso de métricas do Neptune](best-practices-general-metrics.md)
+ [Práticas recomendadas para ajustar as consultas do Neptune](best-practices-general-basic.md#best-practices-general-tuning)
+ [Balanceamento de carga entre réplicas de leitura](best-practices-general-basic.md#best-practices-general-loadbalance)
+ [Carregar com maior rapidez usando uma instância temporária maior](best-practices-general-basic.md#best-practices-loader-tempinstance)
+ [Redimensione a instância de gravador realizando o failover para uma réplica de leitura](best-practices-general-basic.md#best-practices-resize-instance)
+ [Tentar fazer upload novamente após um erro de interrupção de tarefa de pré-busca de dados](best-practices-general-basic.md#load-api-reference-status-interrupted)
+ [Práticas recomendadas gerais para usar o Gremlin com o Neptune](best-practices-gremlin.md)
+ [Configuração Heartbeat para Neptune Serverless](best-practices-gremlin-heartbeat-serverless.md)
+ [Estruturar consultas de upsert para aproveitar as vantagens do mecanismo do DFE](best-practices-gremlin.md#best-practices-gremlin-upserts)
+ [Testar o código do Gremlin no contexto em que você o implantará](best-practices-gremlin-console-glv-differences.md)
+ [Criação de gravações eficientes com multi-thread do Gremlin](best-practices-gremlin-multithreaded-writes.md)
+ [Redução de registros com o Creation Time Property](best-practices-gremlin-prune.md)
+ [Ao usar o método `datetime( )` para o Groovy Time Data](best-practices-gremlin-datetime.md)
+ [Uso da data e hora nativas para dados de data GLV](best-practices-gremlin-datetime-glv.md)
+ [Práticas recomendadas para usar o cliente Java do Gremlin com o Neptune](best-practices-gremlin-java-client.md)
+ [Reutilizar o objeto de cliente entre vários threads](best-practices-gremlin-java-reuse.md)
+ [Criar objetos separados do cliente Java do Gremlin para endpoints de leitura e gravação](best-practices-gremlin-java-separate.md)
+ [Adicionar vários endpoints de réplica de leitura a um grupo conexão Java do Gremlin](best-practices-gremlin-java-multiple.md)
+ [Fechar o cliente para evitar o limite de conexões](best-practices-gremlin-java-close-connections.md)
+ [Criar uma conexão após o failover](best-practices-gremlin-java-new-connection.md)
+ [Definir `maxInProcessPerConnection` e `maxSimultaneousUsagePerConnection` como o mesmo valor](best-practices-gremlin-java-maxes.md)
+ [Enviar consultas ao servidor como bytecode em vez de strings](best-practices-gremlin-java-bytecode.md)
+ [Sempre consuma completamente o ResultSet ou Iterator retornado por uma consulta](best-practices-gremlin-java-resultset.md)
+ [Adicionar em massa vértices e bordas em lotes](best-practices-gremlin-java-batch-add.md)
+ [Desativar o armazenamento em cache DNS no Java Virtual Machine](best-practices-gremlin-java-disable-dns-caching.md)
+ [Opcionalmente, definir tempos limite em um nível por consulta](best-practices-gremlin-java-per-query-timeout.md)
+ [Solução de problemas do `java.util.concurrent.TimeoutException`](best-practices-gremlin-java-exceptions-TimeoutException.md)
+ [Práticas recomendadas para o Neptune ao usar openCypher e Bolt](best-practices-opencypher.md)
+ [Criar uma conexão após o failover](best-practices-opencypher.md#best-practices-opencypher-renew-connection)
+ [Tratamento de conexões para aplicações de longa duração](best-practices-opencypher.md#best-practices-opencypher-long-connections)
+ [Manipulação de conexão para AWS Lambda](best-practices-opencypher.md#best-practices-opencypher-lambda-connections)
+ [Preferir direcionar para bordas bidirecionais nas consultas](best-practices-opencypher-directed-edges.md)
+ [O Neptune não é compatível com várias consultas simultâneas em uma transação.](best-practices-opencypher-multiple-queries.md)
+ [Fechar objetos de driver ao concluir](best-practices-opencypher-close-driver.md)
+ [Usar modos de transação explícitos para leitura e gravação](best-practices-opencypher-use-explicit-txs.md)
+ [Transações somente leitura](best-practices-opencypher-use-explicit-txs.md#best-practices-opencypher-read-txs)
+ [Transações de mutação](best-practices-opencypher-use-explicit-txs.md#best-practices-opencypher-mutation-txs)
+ [Lógica de novas tentativas para exceções](best-practices-opencypher-retry-logic.md)
+ [Definir várias propriedades de uma vez usando uma única cláusula SET](best-practices-content-0.md)
+ [Usar a cláusula SET para remover várias propriedades de uma só vez](best-practices-content-0.md#best-practices-content-1)
+ [Usar consultas parametrizadas](best-practices-content-2.md)
+ [Use mapas nivelados em vez de mapas aninhados na cláusula UNWIND](best-practices-content-3.md)
+ [Coloque nós mais restritivos no lado esquerdo em expressões de caminho de comprimento variável (VLP)](best-practices-content-4.md)
+ [Evitar verificações redundantes de rótulos de nó usando nomes de relacionamento granulares](best-practices-content-5.md)
+ [Especificar rótulos de borda sempre que possível](best-practices-content-6.md)
+ [Evitar usar a cláusula WITH quando possível](best-practices-content-7.md)
+ [Colocar filtros restritivos o mais cedo possível na consulta](best-practices-content-8.md)
+ [Verificar explicitamente se as propriedades existem](best-practices-content-9.md)
+ [Não usar o caminho nomeado (a menos que seja necessário)](best-practices-content-10.md)
+ [Evitar COLLECT(DISTINCT())](best-practices-content-11.md)
+ [Optar pela função de propriedades em vez da pesquisa de propriedades individuais ao recuperar todos os valores da propriedade](best-practices-content-12.md)
+ [Executar cálculos estáticos fora da consulta](best-practices-content-13.md)
+ [Agrupar entradas usando UNWIND em vez de declarações individuais](best-practices-content-14.md)
+ [Prefiro usar o personalizado IDs para nó/relacionamento](best-practices-content-15.md)
+ [Evitar fazer cálculos de \$1id na consulta](best-practices-content-16.md)
+ [Atualizar/mesclar vários nós](best-practices-merge-multiple-nodes.md)
+ [Práticas recomendadas para o Neptune ao usar SPARQL](best-practices-sparql.md)
+ [Como consultar todos os gráficos nomeados por padrão](best-practices-sparql-query.md)
+ [Como especificar um nome gráfico para carregamento](best-practices-sparql-graph.md)
+ [Como escolher entre FILTER, FILTER...IN e VALUES em suas consultas](best-practices-sparql-batch.md)
# Diretrizes operacionais básicas do Amazon Neptune
As diretrizes operacionais básicas a seguir devem ser seguidas ao trabalhar com o Neptune.
+ Entenda as instâncias de banco de dados do Neptune para que você possa dimensioná-las adequadamente de acordo com seus requisitos de desempenho e caso de uso. Consulte [Clusters e instâncias de banco de dados do Amazon Neptune](feature-overview-db-clusters.md).
+ Monitore o uso que você faz da CPU e da memória. Isso ajuda você a saber quando migrar para uma classe de instância de banco de dados com maior capacidade de memória ou CPU para alcançar o desempenho necessário nas consultas. Você pode configurar CloudWatch a Amazon para notificá-lo quando os padrões de uso mudarem ou quando você se aproximar da capacidade de sua implantação. Isso pode ajudá-lo a manter o desempenho e a disponibilidade do sistema. Consulte [Monitorar instâncias](feature-overview-db-clusters.md#feature-overview-monitoring-instances) e [Monitorar o Neptune](monitoring.md) para obter mais detalhes.
Como o Neptune tem seu próprio gerenciador de memória, é normal ver um uso relativamente baixo da memória, mesmo quando o uso da CPU é alto. Encontrar out-of-memory exceções ao executar consultas é o melhor indicador de que você precisa aumentar a memória liberável.
+ Ative os backups automáticos e defina a janela de backup para que ela ocorra em um momento conveniente.
+ Teste o failover da instância do banco de dados para entender quanto tempo o processo leva para seu caso de uso. Isso também ajuda a garantir que o aplicativo que acessa sua instância de banco de dados possa se conectar automaticamente à nova instância de banco de dados após o failover.
+ Se possível, execute o cliente e o cluster Neptune na mesma região e VPC, pois as conexões entre regiões com emparelhamento de VPC podem apresentar atrasos nos tempos de resposta de consulta. Para respostas de consulta em milissegundos de um único dígito, é necessário manter o cliente e o cluster do Neptune na mesma região e VPC.
+ Quando você cria uma instância de réplica de leitura, ela deve ser pelo menos tão grande quanto a instância de gravador principal. Isso ajuda a manter o atraso de replicação sob controle e evita reinicializações de réplicas. Consulte [Evitar classes de instância diferentes em um cluster](#best-practices-loader-heterogeneous-instances).
+ Antes de realizar a atualização para uma nova versão principal do mecanismo, teste a aplicação nela antes de fazer upgrade. Você pode fazer isso clonando o cluster de banco de dados para que o cluster clone execute a nova versão do mecanismo e, depois, testando a aplicação no clone.
+ Para facilitar os failovers, é ideal que todas as instâncias tenham o mesmo tamanho.
**Topics**
+ [Práticas recomendadas de segurança para o Amazon Neptune](best-practices-general-security.md)
+ [Evitar classes de instância diferentes em um cluster](#best-practices-loader-heterogeneous-instances)
+ [Evitar reinicializações repetidas durante o carregamento em massa](#best-practices-loader-repeated-restarts)
+ [Habilitar o Índice OSGP se você tiver um grande número de predicados](#best-practices-general-predicates)
+ [Evitar transações de longa execução quando possível](#best-practices-general-long-running-transactions)
+ [Práticas recomendadas para o uso de métricas do Neptune](best-practices-general-metrics.md)
+ [Práticas recomendadas para ajustar as consultas do Neptune](#best-practices-general-tuning)
+ [Balanceamento de carga entre réplicas de leitura](#best-practices-general-loadbalance)
+ [Carregar com maior rapidez usando uma instância temporária maior](#best-practices-loader-tempinstance)
+ [Redimensione a instância de gravador realizando o failover para uma réplica de leitura](#best-practices-resize-instance)
+ [Tentar fazer upload novamente após um erro de interrupção de tarefa de pré-busca de dados](#load-api-reference-status-interrupted)
# Práticas recomendadas de segurança para o Amazon Neptune
Use contas AWS Identity and Access Management (IAM) para controlar o acesso às ações da API Neptune. Controle ações que criam, modificam ou excluem recursos do Neptune (como instâncias de banco de dados, grupos de segurança, grupos de opções ou grupos de parâmetros) e ações administrativas comuns (como fazer backup e restaurar instâncias de banco de dados).
+ Use credenciais temporárias em vez de persistentes sempre que possível.
+ Atribua uma conta do IAM individual a cada pessoa que gerencia recursos do Amazon Relational Database Service (Amazon RDS). Nunca use usuários raiz AWS da conta para gerenciar os recursos do Neptune. Crie um usuário do IAM para todos os usuários, incluindo você mesmo.
+ Conceda a cada usuário o conjunto mínimo de permissões necessárias para realizar suas funções.
+ Use grupos do IAM para gerenciar efetivamente permissões para vários usuários.
+ Mude suas credenciais do IAM regularmente.
Para obter mais informações sobre o uso do IAM para acessar os recursos do Neptune, consulte [Proteger o banco de dados do Amazon Neptune](security.md). Para obter informações gerais sobre como trabalhar com o IAM, consulte [AWS Identity and Access Management](https://docs.aws.amazon.com/IAM/latest/UserGuide/Welcome.html) e [IAM Best Practices](https://docs.aws.amazon.com/IAM/latest/UserGuide/IAMBestPractices.html) no *Guia do usuário do IAM*.
## Evitar classes de instância diferentes em um cluster
Quando o cluster de banco de dados contém instâncias de classes diferentes, podem ocorrer problemas com o tempo. O problema mais comum é que uma pequena instância de leitor pode entrar em um ciclo de reinicializações repetidas devido ao atraso na replicação. Se um nó de leitor tiver uma configuração de classe de instância de banco de dados mais fraca do que a de uma instância de banco de dados de gravador, o volume de alterações poderá ser muito grande para o leitor se atualizar.
**Importante**
Para evitar reinicializações repetidas causadas pelo atraso na replicação, configure o cluster de banco de dados para que todas as instâncias tenham a mesma classe (tamanho) de instância.
Você pode ver o atraso entre a instância do gravador (a primária) e os leitores em seu cluster de banco de dados usando a `ClusterReplicaLag` métrica na Amazon CloudWatch. A métrica `VolumeWriteIOPs` também permite detectar picos de atividade de gravação no cluster que podem criar atrasos na replicação.
## Evitar reinicializações repetidas durante o carregamento em massa
Se você tiver um ciclo de reinicializações repetidas de réplica de leitura em virtude do atraso na replicação durante o carregamento em massa, é provável que as réplicas não consigam acompanhar o gravador no cluster de banco de dados.
Escale os leitores para serem maiores do que o gravador ou remova-os temporariamente durante o carregamento em massa e, depois, recrie-os após a conclusão.
## Habilitar o Índice OSGP se você tiver um grande número de predicados
Se o seu modelo de dados contiver um grande número de predicados distintos (mais de mil na maioria dos casos), o desempenho poderá ser degradado e os custos operacionais mais altos.
Se for esse o caso, você poderá melhorar o desempenho habilitando o [índice OSGP](feature-overview-storage-indexing.md#feature-overview-storage-indexing-osgp). Consulte [O índice OSGP](features-lab-mode.md#features-lab-mode-features-osgp-index).
## Evitar transações de longa execução quando possível
Transações de longa execução, somente leitura ou leitura e gravação, podem causar problemas inesperados dos seguintes tipos:
Uma transação de longa execução em uma instância de leitor ou em uma instância de gravador com gravações simultâneas pode ocasionar um grande acúmulo de diferentes versões de dados. Isso pode introduzir latências mais altas para consultas de leitura que filtrem uma grande parte dos resultados.
Em alguns casos, as versões acumuladas ao longo de horas podem fazer com que novas gravações sejam limitadas.
Uma transação de leitura e gravação de longa execução com muitas gravações também poderá causar problemas se a instância for reiniciada. Se uma instância for reiniciada a partir de um evento de manutenção ou de uma falha, todas as gravações não confirmadas serão revertidas. Essas operações de desfazer normalmente são executadas em segundo plano e não impedem que a instância volte a funcionar, mas qualquer nova gravação que entre em conflito com as operações que estão sendo revertidas falhará.
Por exemplo, se a mesma consulta for repetida após a conexão ter sido interrompida na execução anterior, ela poderá falhar quando a instância for reiniciada.
O tempo necessário para as operações de desfazer é proporcional ao tamanho das alterações envolvidas.
# Práticas recomendadas para o uso de métricas do Neptune
Para identificar problemas de desempenho causados por recursos insuficientes e outros gargalos comuns, é possível monitorar as métricas disponíveis para o cluster de banco de dados do Neptune.
Monitore as métricas de desempenho regularmente para coletar dados sobre os valores médio, máximo e mínimo de uma série de intervalos de tempo. Isso ajuda a identificar quando o desempenho está degradado. Usando esses dados, você pode definir CloudWatch alarmes da Amazon para limites métricos específicos para ser alertado se eles forem atingidos.
Quando você configura um novo cluster de banco de dados e a executa com uma carga de trabalho típica, tente captar os valores médio, máximo e mínimo de todas as métricas de desempenho em vários intervalos diferentes (por exemplo, uma hora, 24 horas, uma semana, duas semanas). Isso dá a você uma ideia do que é normal. Isso ajuda a obter comparações para as horas de operação de pico e fora de pico. Você pode usar essas informações para identificar quando o desempenho está ficando abaixo dos níveis padrão e definir alarmes corretamente.
Consulte [Monitorando Neptune usando a Amazon CloudWatch](cloudwatch.md) para obter informações sobre como visualizar métricas do Neptune.
Veja a seguir as métricas mais importantes para começar:
+ **BufferCacheHitRatio**— A porcentagem de solicitações atendidas pelo cache de buffer. As falhas de cache adicionam latência significativa à execução da consulta. Se a taxa de acertos do cache estiver abaixo de 99,9% e a latência for um problema na aplicação, pense em atualizar o tipo de instância para armazenar em cache mais dados na memória.
+ **Utilização da CPU**: porcentagem da capacidade de processamento computacional utilizada. Altos valores de consumo de CPU podem ser adequados, dependendo de seus objetivos de desempenho de consultas.
+ **Memória disponível**: quanta RAM está disponível na instância de banco de dados, em megabytes. O Neptune tem seu próprio gerenciador de memória, então essa métrica pode ser mais baixa do que você espera. Um bom sinal de que você deve considerar atualizar sua classe de instância para uma com mais RAM é se as consultas geralmente out-of-memory geram exceções.
A linha vermelha nas métricas da guia **Monitoring (Monitoramento)** é marcada em 75% para CPU e métricas de memória. Se o consumo de memória da instância cruzar essa linha com frequência, verifique sua carga de trabalho ou considere atualizar sua instância para melhorar o desempenho das consultas.
## Práticas recomendadas para ajustar as consultas do Neptune
Uma das melhores maneiras de melhorar o desempenho do Neptune é ajustar as consultas mais utilizadas e que requerem mais recursos para baixar o custo de execução delas.
Para obter informações sobre como ajustar as consultas do Gremlin, consulte [Dicas de consulta do Gremlin](gremlin-query-hints.md) e [Ajustar consultas do Gremlin](gremlin-traversal-tuning.md). Para obter informações sobre como ajustar consultas do SPARQL, consulte [Dicas de consulta do SPARQL](sparql-query-hints.md).
## Balanceamento de carga entre réplicas de leitura
O roteamento ida e volta do endpoint de leitor funciona alterando o host para o qual a entrada DNS aponta. O cliente deve criar uma nova conexão e resolver o registro DNS para obter uma conexão com uma nova réplica de leitura, porque WebSocket as conexões geralmente são mantidas ativas por longos períodos.
Para obter réplicas de leitura diferentes para solicitações sucessivas, certifique-se de que o cliente resolva a entrada de DNS sempre que se conectar. Isso pode exigir o fechamento da conexão e a reconexão ao endpoint de leitor.
Você também pode balancear a carga de solicitações entre réplicas de leitura conectando-se aos endpoints da instância explicitamente.
## Carregar com maior rapidez usando uma instância temporária maior
O desempenho do carregamento aumenta com tamanhos de instância maiores. Se não estiver usando um tipo de instância ampla, mas quer aumentar a velocidade de carregamento, você pode usar a instância ampla para carregar e então excluí-la.
**nota**
O procedimento a seguir é para um novo cluster. Se tiver um cluster existente, você pode adicionar uma nova instância maior e, em seguida, promovê-la para uma instância de Banco de Dados.
**Para carregar dados usando um tamanho de instância maior**
1. Crie um cluster com uma única instância `r5.12xlarge`. Esta instância é a principal instância de banco de dados.
1. Crie uma ou mais réplicas de leitura do mesmo tamanho (`r5.12xlarge`).
É possível criar as réplicas de leitura em um tamanho menor, mas se elas não forem grandes o suficiente para acompanhar as gravações feitas pela instância principal, talvez precisem ser reiniciadas com frequência. O tempo de inatividade resultante reduz drasticamente o desempenho.
1. No comando do carregador em massa, inclua `“parallelism” : “OVERSUBSCRIBE”` para indicar ao Neptune que use todos os recursos de CPU disponíveis para carregamento (consulte [Parâmetros de solicitação do carregador do Neptune](load-api-reference-load.md#load-api-reference-load-parameters)). A operação de carregamento prosseguirá o mais rápido possível, I/O o que geralmente requer de 60 a 70% dos recursos da CPU.
1. Carregue os dados usando o carregador do Neptune. O trabalho de carga é executado na instância de banco de dados principal.
1. Depois que os dados terminarem de carregar, certifique-se de reduzir todas as instâncias no cluster para o mesmo tipo de instância a fim de evitar cobranças adicionais e problemas repetidos de reinicialização (consulte [Evitar tamanhos de instância diferentes.](#best-practices-loader-heterogeneous-instances)).
## Redimensione a instância de gravador realizando o failover para uma réplica de leitura
A melhor maneira de redimensionar uma instância no cluster de banco de dados, incluindo a instância de gravador, é criar ou modificar uma instância de réplica de leitura para que ela tenha o tamanho desejado e, depois, fazer o failover deliberadamente para essa réplica de leitura. O tempo de inatividade observado pela aplicação é apenas o tempo necessário para alterar o endereço IP do gravador, que deve ser de cerca de três a cinco segundos.
A API de gerenciamento do Neptune usada para fazer failover deliberadamente da instância de gravador atual para uma instância de réplica de leitura é [FailoverDBCluster](api-clusters.md#FailoverDBCluster). Se você estiver usando o cliente Java do Gremlin, talvez seja necessário criar um objeto Client após o failover para obter o novo endereço IP, conforme mencionado [aqui](best-practices-gremlin-java-new-connection.md).
Altere todas as instâncias para o mesmo tamanho a fim de evitar um ciclo de reinicializações repetidas, conforme mencionado abaixo.
## Tentar fazer upload novamente após um erro de interrupção de tarefa de pré-busca de dados
Ocasionalmente, quando você estiver carregando dados no Neptune usando o carregador em massa, poderá ocorrer um status `LOAD_FAILED`, com uma mensagem `PARSING_ERROR` e `Data prefetch task interrupted` relatadas em resposta a uma solicitação de informações detalhadas, como:
```
"errorLogs" : [
{
"errorCode" : "PARSING_ERROR",
"errorMessage" : "Data prefetch task interrupted: Data prefetch task for 11467 failed",
"fileName" : "s3://amzn-s3-demo-bucket/some-source-file",
"recordNum" : 0
}
]
```
Se você encontrar esse erro, basta executar novamente a solicitação de upload em massa.
O erro ocorre quando há uma interrupção temporária que normalmente não foi causada por sua solicitação ou seus dados e, geralmente, ele pode ser resolvido executando a solicitação de upload em massa novamente.
Se você estiver usando as configurações padrão, ou seja, `"mode":"AUTO"` e `"failOnError":"TRUE"`, o carregador ignorará os arquivos que ele já tiver carregado com êxito e retomará o carregamento de arquivos que ainda não tinha carregado quando a interrupção ocorreu.
# Práticas recomendadas gerais para usar o Gremlin com o Neptune
Siga estas recomendações ao usar a linguagem de percurso de grafos Gremlin com o Neptune. Para obter informações sobre como usar o Gremlin com Neptune, consulte [Acessar o grafo do Neptune com o Gremlin](access-graph-gremlin.md).
**Importante**
Foi feita uma alteração na TinkerPop versão 3.4.11 que melhora a exatidão de como as consultas são processadas, mas, no momento, às vezes pode afetar seriamente o desempenho das consultas.
Por exemplo, uma consulta desse tipo pode apresentar uma lentidão significativa:
```
g.V().hasLabel('airport').
order().
by(out().count(),desc).
limit(10).
out()
```
Os vértices após a etapa limite agora são buscados de uma forma não ideal devido à alteração 3.4.11. TinkerPop Para evitar isso, é possível modificar a consulta adicionando a etapa barrier() a qualquer momento após `order().by()`. Por exemplo:
```
g.V().hasLabel('airport').
order().
by(out().count(),desc).
limit(10).
barrier().
out()
```
TinkerPop [3.4.11 foi habilitado na versão 1.0.5.0 do motor Neptune.](engine-releases-1.0.5.0.md)
**Topics**
+ [Configuração Heartbeat para Neptune Serverless](best-practices-gremlin-heartbeat-serverless.md)
+ [Estruturar consultas de upsert para aproveitar as vantagens do mecanismo do DFE](#best-practices-gremlin-upserts)
+ [Testar o código do Gremlin no contexto em que você o implantará](best-practices-gremlin-console-glv-differences.md)
+ [Criação de gravações eficientes com multi-thread do Gremlin](best-practices-gremlin-multithreaded-writes.md)
+ [Redução de registros com o Creation Time Property](best-practices-gremlin-prune.md)
+ [Ao usar o método `datetime( )` para o Groovy Time Data](best-practices-gremlin-datetime.md)
+ [Uso da data e hora nativas para dados de data GLV](best-practices-gremlin-datetime-glv.md)
# Configuração Heartbeat para Neptune Serverless
Ao usar WebSocket clientes Gremlin com o Neptune Serverless, você precisa configurar o intervalo de ping do cliente de forma adequada para manter conexões estáveis durante eventos de escalabilidade. O cliente Gremlin usa WebSocket conexões e envia pings periódicos para verificar se a conexão está ativa. O cliente espera uma resposta do servidor dentro do intervalo de ping. Se o servidor não responder, o cliente fechará automaticamente a conexão.
**Para instâncias provisionadas pelo **Neptune**, recomendamos definir o intervalo de ping para 5 segundos.** Para clusters **Neptune Serverless**, recomendamos definir o intervalo de ping para **pelo menos 20** segundos para acomodar possíveis atrasos durante as operações de escalabilidade. Esse parâmetro controla quanto tempo o cliente espera entre as gravações no servidor antes de enviar um ping para verificar se a conexão ainda está ativa.
A configuração desse parâmetro varia de acordo com a implementação do cliente:
**Configuração do cliente Java**
Para o cliente Java TinkerPop Gremlin, configure o `keepAliveInterval` parâmetro:
```
Cluster.Builder builder = Cluster.build()
.addContactPoint(endpoint)
.keepAliveInterval(20000); // Configure ping interval in milliseconds
```
Para obter mais detalhes sobre a configuração do driver Java, consulte a [ TinkerPop documentação do Java](https://tinkerpop.apache.org/docs/current/reference/#gremlin-java-configuration).
**Configuração do Go Client**
Para o cliente Gremlin Go, configure o `KeepAliveInterval` parâmetro:
```
rc, err := driver.NewDriverRemoteConnection(endpoint,
func(settings *driver.DriverRemoteConnectionSettings) {
settings.TraversalSource = "g"
settings.AuthInfo = auth
settings.KeepAliveInterval = 20 * time.Second // Configure ping interval
...
})
```
Para obter mais detalhes sobre a configuração do driver Go, consulte a [ TinkerPop documentação do Go](https://tinkerpop.apache.org/docs/current/reference/#gremlin-go-configuration).
**JavaScriptConfiguração do cliente /Node.js**
Para o cliente Gremlin JavaScript /Node.js, configure o `pingInterval` parâmetro:
```
const gremlin = require('gremlin');
const DriverRemoteConnection = gremlin.driver.DriverRemoteConnection;
const connection = new DriverRemoteConnection(endpoint, {
traversalSource: 'g',
pingInterval: 20000 // Configure ping interval in milliseconds
});
```
Para obter mais detalhes sobre a configuração do JavaScript driver, consulte a [JavaScript TinkerPop documentação](https://tinkerpop.apache.org/docs/current/reference/#gremlin-javascript-configuration).
**Configuração do cliente Python**
Para o cliente Python Gremlin, o intervalo de ping normalmente é gerenciado na camada de transporte. Consulte a documentação específica de implementação de transporte para ver as opções de configuração:
```
from gremlin_python.driver.driver_remote_connection import DriverRemoteConnection
g = traversal().with_remote(
DriverRemoteConnection('wss://your-neptune-endpoint:your-neptune-port/gremlin','g',
transport_factory=lambda: AiohttpTransport(read_timeout=60,
write_timeout=20,
heartbeat=20, // Configure heartbeat
call_from_event_loop=True,
max_content_length=100*1024*1024,
ssl_options=ssl.create_default_context(Purpose.CLIENT_AUTH))))
```
[Para obter mais detalhes sobre a configuração do driver do Python, consulte a documentação do Python. TinkerPop ](https://tinkerpop.apache.org/docs/current/reference/#gremlin-python-configuration)
Essa configuração garante que seu cliente mantenha a estabilidade da conexão durante os eventos de escalabilidade do Neptune Serverless, evitando fechamentos de conexão desnecessários e melhorando a confiabilidade do aplicativo.
## Estruturar consultas de upsert para aproveitar as vantagens do mecanismo do DFE
[Criar surtos eficientes com as etapas `mergeV()` e `mergeE()` do Gremlin.](gremlin-efficient-upserts.md) explica como estruturar consultas de upsert para usar o mecanismo do DFE da forma mais eficaz possível.
# Testar o código do Gremlin no contexto em que você o implantará
No Gremlin, há várias maneiras de os clientes enviarem consultas ao servidor: usando WebSocket o Bytecode GLV ou por meio do console do Gremlin usando scripts baseados em strings.
É importante reconhecer que a execução da consulta do Gremlin pode ser diferente dependendo de como você envia a consulta. Uma consulta que gere um resultado vazio pode ser tratada como bem-sucedida se enviada no modo Bytecode, mas com falha se enviada no modo script. Por exemplo, se você incluir `next()` em uma consulta no modo script, ela será enviada para `next()` o servidor, mas o uso do cliente geralmente ByteCode processa a consulta por si só. `next()` No primeiro caso, a consulta falhará se nenhum resultado for encontrado, mas no segundo, a consulta será bem-sucedida independentemente de o conjunto de resultados estar vazio ou não.
Se você desenvolver e testar o código em um contexto (por exemplo, o console do Gremlin, que geralmente envia consultas em formato de texto), mas depois implanta o código em um contexto diferente (por exemplo, por meio do driver do Java usando Bytecode), você pode ter problemas com o código apresentando comportamentos diferentes na produção e no ambiente de desenvolvimento.
**Importante**
Teste o código do Gremlin no contexto do GLV em que ele será implantado, para evitar resultados inesperados.
# Criação de gravações eficientes com multi-thread do Gremlin
Há algumas diretrizes para carregamento de dados com multi-thread para o Neptune usando o Gremlin.
Se possível, atribua a cada thread um conjunto de vértices ou bordas a serem inseridos ou modificados que não colidam. Por exemplo, o thread abrange o intervalo de IDs de 1 a 50.000, o thread 2 abrange o intervalo de IDs de 50.001 a 100.000, etc. Isso reduz a chance de atingir uma `ConcurrentModificationException`. Para melhor segurança, coloque um bloco `try/catch` em torno de todas as gravações. Se ocorrer uma falha em qualquer uma delas, você poderá repeti-las depois de um breve atraso.
O agrupamento de gravações em lotes de 50 a 100 (vértices ou bordas) geralmente funciona bem. Se você tiver uma grande quantidade de propriedades sendo adicionadas para cada vértice, um número mais próximo de 50 do que de 100 poderá ser a melhor opção. Alguma experimentação é útil. Portanto, para gravações em lote, você pode usar algo como o seguinte:
```
g.addV(‘test’).property(id,’1’).as(‘a’).
addV(‘test’).property(id,’2’).
addE(‘friend’).to(‘a’).
```
Isso é, então, repetido em cada operação em lote.
O uso de lotes é significativamente mais eficiente do que a adição de um vértice ou borda por Gremlin de ida e volta para o servidor.
Se você estiver usando um cliente de Variante da linguagem Gremlin (GLV), crie um lote de forma programática primeiro criando uma travessia. Em seguida, adicione a ele e, por fim, itere sobre ele; por exemplo:
```
t.addV(‘test’).property(id,’1’).as(‘a’)
t.addV(‘test’).property(id,’2’)
t.addE(‘friend’).to(‘a’)
t.iterate()
```
É melhor usar o cliente da variante de linguagem do Gremlin, se possível. No entanto, você pode fazer algo parecido com um cliente que envia consultas como strings de texto concatenando as strings para criar um lote.
Se você estiver usando uma das bibliotecas do cliente de Gremlin em vez de HTTP básico para consultas, os threads deverão compartilhar o mesmo cliente, cluster ou grupo de conexões. Pode ser necessário ajustar as configurações para obter o melhor throughput possível, configurações como o tamanho do grupo de conexões e o número de threads de operador que o cliente do Gremlin usa.
# Redução de registros com o Creation Time Property
É possível remover os registros de tabela ao armazenar a hora de criação como uma propriedade em vértices e removê-los periodicamente.
Caso precise armazenar dados para uma vida útil específica e então removê-la do gráfico (tempo de vida do vértice), você pode armazenar uma propriedade time stamp na criação do vértice. Em seguida, você pode periodicamente emitir uma consulta do `drop()` para todos os vértices que foram criados antes de um certo período, por exemplo:
```
g.V().has(“timestamp”, lt(datetime('2018-10-11')))
```
# Ao usar o método `datetime( )` para o Groovy Time Data
O Neptune oferece o método `datetime` para especificar datas e horas para consultas enviadas na variante Gremlin **Groovy**. Isso inclui o Gremlin Console, strings de texto usando a API REST HTTP, e qualquer outra serialização que usa o Groovy.
**Importante**
Isso se aplica *somente* a métodos onde você envia a consulta Gremlin como uma *string de texto*. Se você estiver usando uma Variante da Linguagem Gremlin, deverá usar as classes e funções de data nativa para o idioma. Para obter mais informações, consulte a próxima sessão, [Uso da data e hora nativas para dados de data GLV](best-practices-gremlin-datetime-glv.md).
Começar com TinkerPop `3.5.2` (introduzido na [versão 1.1.1.0 do motor Neptune](engine-releases-1.1.1.0.md)) `datetime` é parte integrante do. TinkerPop
Você pode usar o método do `datetime` para armazenar e comparar datas:
```
g.V('3').property('date',datetime('2001-02-08'))
```
```
g.V().has('date',gt(datetime('2000-01-01')))
```
# Uso da data e hora nativas para dados de data GLV
Se estiver usando uma Variante da Linguagem Gremlin (GLV, Gremlin Language Variant), você deve usar as classes e funções de data e hora nativas fornecidas pela linguagem de programação para dados de tempo do Gremlin.
As TinkerPop bibliotecas oficiais são todas bibliotecas Gremlin Language Variant.
+ [Go](https://tinkerpop.apache.org/docs/current/reference/#gremlin-go)
+ [Java](https://tinkerpop.apache.org/docs/current/reference/#gremlin-java)
+ [Javascript](https://tinkerpop.apache.org/docs/current/reference/#gremlin-javascript)
+ [.NET](https://tinkerpop.apache.org/docs/current/reference/#gremlin-dotnet)
+ [Python](https://tinkerpop.apache.org/docs/current/reference/#gremlin-python)
**Importante**
Esta página se aplica somente às bibliotecas de Variante da Linguagem Gremlin (GLV). Se estiver usando um método para enviar a consulta do Gremlin como sequência de texto, você deve usar a função datetime() do Gremlin. Isso inclui o console do Gremlin, sequências de texto usando a API REST HTTP ou envio direto de sequências de caracteres Gremlin por meio dos drivers.
**Go**
Veja a seguir um exemplo parcial no Go que cria uma propriedade única chamada “date” para o vértice com um ID de “3”. Isso define o valor para ser uma data gerada usando a função Go. time.Now().
```
import ( "time" )
g.V('3').property('date', time.Now()).next();
```
Para ver um exemplo completo de conexão com o Neptune usando Go, consulte [Usar um cliente Go para se conectar a uma instância de banco de dados do Neptune](https://docs.aws.amazon.com//neptune/latest/userguide/access-graph-gremlin-go.html).
**Java**
Veja a seguir um exemplo parcial em Java que cria uma propriedade única chamada '`date`' para o vértice com um ID do '`3`'. Isso define o valor a ser uma data gerada usando o construtor do `Date()` Java.
```
import java.util.date
g.V('3').property('date', new Date()).next();
```
Para ver um exemplo completo de como se conectar ao Neptune usando Java, consulte [Usar o cliente do Java para conectar-se a uma instância de banco de dados do Neptune](access-graph-gremlin-java.md).
**Node.js (JavaScript)**
A seguir está um exemplo parcial em JavaScript que cria uma única propriedade chamada '`date`' para o vértice com um ID de '`3`'. Isso define o valor a ser uma data gerada usando o construtor do `Date()` Node.js.
```
g.V('3').property('date', new Date()).next()
```
Para ver um exemplo completo de como se conectar ao Neptune usando Node.js, consulte [Usar o Node.js para conectar-se a uma instância de banco de dados do Neptune](access-graph-gremlin-node-js.md).
**.NET (C\$1)**
Veja a seguir um exemplo parcial em C\$1 que cria uma propriedade única chamada '`date`' para o vértice com um ID do '`3`'. Isso define o valor a ser uma data gerada usando a propriedade do `DateTime.UtcNow` .NET.
```
Using System;
g.V('3').property('date', DateTime.UtcNow).next()
```
Para ver um exemplo completo de como se conectar ao Neptune usando C\$1, consulte [Usar .NET para conectar-se a uma instância de banco de dados do Neptune](access-graph-gremlin-dotnet.md).
**Python**
Veja a seguir um exemplo parcial em Python que cria uma propriedade única chamada '`date`' para o vértice com um ID do '`3`'. Isso define o valor a ser uma data gerada usando o método do `datetime.now()` Python.
```
import datetime
g.V('3').property('date',datetime.datetime.now()).next()
```
Para ver um exemplo completo de como se conectar ao Neptune usando Python, consulte [Usar o Python para conectar-se a uma instância de banco de dados do Neptune](access-graph-gremlin-python.md).
# Práticas recomendadas para usar o cliente Java do Gremlin com o Neptune
Siga essas recomendações ao usar o cliente Gremlin Java com o Neptune. Essas melhores práticas ajudam você a otimizar o desempenho, gerenciar conexões de forma eficaz e evitar armadilhas comuns ao trabalhar com o driver Java.
Para obter informações sobre como configurar intervalos de pulsação para o Neptune Serverless, consulte. [Configuração Heartbeat para Neptune Serverless](best-practices-gremlin-heartbeat-serverless.md)
**Topics**
+ [Reutilizar o objeto de cliente entre vários threads](best-practices-gremlin-java-reuse.md)
+ [Criar objetos separados do cliente Java do Gremlin para endpoints de leitura e gravação](best-practices-gremlin-java-separate.md)
+ [Adicionar vários endpoints de réplica de leitura a um grupo conexão Java do Gremlin](best-practices-gremlin-java-multiple.md)
+ [Fechar o cliente para evitar o limite de conexões](best-practices-gremlin-java-close-connections.md)
+ [Criar uma conexão após o failover](best-practices-gremlin-java-new-connection.md)
+ [Definir `maxInProcessPerConnection` e `maxSimultaneousUsagePerConnection` como o mesmo valor](best-practices-gremlin-java-maxes.md)
+ [Enviar consultas ao servidor como bytecode em vez de strings](best-practices-gremlin-java-bytecode.md)
+ [Sempre consuma completamente o ResultSet ou Iterator retornado por uma consulta](best-practices-gremlin-java-resultset.md)
+ [Adicionar em massa vértices e bordas em lotes](best-practices-gremlin-java-batch-add.md)
+ [Desativar o armazenamento em cache DNS no Java Virtual Machine](best-practices-gremlin-java-disable-dns-caching.md)
+ [Opcionalmente, definir tempos limite em um nível por consulta](best-practices-gremlin-java-per-query-timeout.md)
+ [Solução de problemas do `java.util.concurrent.TimeoutException`](best-practices-gremlin-java-exceptions-TimeoutException.md)
# Reutilizar o objeto de cliente entre vários threads
Reutilize o mesmo objeto de cliente (ou `GraphTraversalSource`) em vários threads. Ou seja, crie uma instância compartilhada de uma classe `org.apache.tinkerpop.gremlin.driver.Client` em seu aplicativo, em vez de fazê-lo em cada thread. O objeto `Client` é seguro para threads, e a sobrecarga de inicializá-lo é considerável.
Isso também se aplica a `GraphTraversalSource`, que cria um objeto `Client` internamente. Por exemplo, o código a seguir cria um novo objeto `Client` a ser instanciado:
```
import static org.apache.tinkerpop.gremlin.process.traversal.AnonymousTraversalSource.traversal;
/////
GraphTraversalSource traversal = traversal()
.withRemote(DriverRemoteConnection.using(cluster));
```
# Criar objetos separados do cliente Java do Gremlin para endpoints de leitura e gravação
É possível aumentar o desempenho ao executar somente gravações no endpoint de gravação e leitura em um ou mais endpoints somente leitura.
```
Client readerClient = Cluster.build("https://reader-endpoint")
...
.connect()
Client writerClient = Cluster.build("https://writer-endpoint")
...
.connect()
```
# Adicionar vários endpoints de réplica de leitura a um grupo conexão Java do Gremlin
Ao criar um objeto `Cluster` do Gremlin Java, você pode usar o método `.addContactPoint()` para adicionar várias instâncias de réplica de leitura aos pontos de contato do grupo de conexão.
```
Cluster.Builder readerBuilder = Cluster.build()
.port(8182)
.minConnectionPoolSize(…)
.maxConnectionPoolSize(…)
………
.addContactPoint("reader-endpoint-1")
.addContactPoint("reader-endpoint-2")
```
# Fechar o cliente para evitar o limite de conexões
É importante fechar o cliente quando terminar de usá-lo para garantir que as WebSocket conexões sejam fechadas pelo servidor e que todos os recursos associados às conexões sejam liberados. Isso ocorrerá automaticamente se você fechar o cluster usando `Cluster.close( )`, porque `client.close( )` depois será chamado internamente.
Se o cliente não estiver fechado corretamente, o Neptune encerrará todas as conexões WebSocket ociosas após 20 a 25 minutos. No entanto, se você não fechar explicitamente WebSocket as conexões ao terminar de usá-las e o número de conexões ativas atingir o [limite de conexões WebSocket simultâneas](limits.md#limits-websockets), conexões adicionais serão recusadas com um código de `429` erro HTTP. Nesse ponto, você deve reiniciar a instância do Neptune para fechar as conexões.
A orientação de chamar `cluster.close()` não se aplica às funções Java do AWS Lambda . Para obter mais detalhes, consulte [Gerenciar conexões do WebSocket do Gremlin em funções do AWS Lambda](lambda-functions-websocket-connections.md).
# Criar uma conexão após o failover
No caso de failover, o Gremlin Driver pode continuar a se conectar ao gravador antigo porque o nome do DNS do cluster foi resolvido para um endereço IP. Se isso acontecer, crie um novo objeto `Client` após o failover.
# Definir `maxInProcessPerConnection` e `maxSimultaneousUsagePerConnection` como o mesmo valor
Tanto os parâmetros `maxInProcessPerConnection` quanto os `maxSimultaneousUsagePerConnection` parâmetros estão relacionados ao número máximo de consultas simultâneas que você pode enviar em uma única WebSocket conexão. Internamente, esses parâmetros são correlacionados, e a modificação de um deles sem o outro pode fazer com que um cliente receba um tempo limite ao tentar obter uma conexão do grupo de conexões do cliente.
Recomendamos manter os valores em andamento e de uso simultâneo mínimos padrão e definir `maxInProcessPerConnection` e `maxSimultaneousUsagePerConnection` como o mesmo valor.
O valor para definir esses parâmetros é uma função de complexidade de consulta e o modelo de dados. Um caso de uso em que a consulta retorna uma grande quantidade de dados exigiria mais largura de banda de conexão por consulta e, portanto, deve ter valores inferiores para os parâmetros e um valor mais alto para `maxConnectionPoolSize`.
Por outro lado, em um caso em que a consulta retorna uma menor quantidade de dados, `maxInProcessPerConnection` e `maxSimultaneousUsagePerConnection` devem ser definidos como um valor maior que `maxConnectionPoolSize`.
# Enviar consultas ao servidor como bytecode em vez de strings
Há vantagens de usar bytecode em vez de string ao enviar consultas:
+ **Obter a sintaxe de consulta inválida com antecedência: ** o uso da variante de bytecode permite detectar sintaxe de consulta inválida na fase de compilação. Se você usar a variação com base em string, só detectará a sintaxe inválida quando a consulta for enviada ao servidor e um erro for gerado.
+ **Evite penalidades de desempenho com base em strings:** [qualquer envio de consulta com base em string, seja usando WebSockets HTTP, resulta em um vértice separado, o que implica que o objeto Vertex consiste no ID, no rótulo e em todas as propriedades associadas ao vértice (consulte Propriedades dos elementos).](http://tinkerpop.apache.org/docs/current/reference/#_properties_of_elements)
Isso pode ocasionar computação desnecessária no servidor em casos em que as propriedades não são necessárias. Por exemplo, se o cliente estiver interessado em obter o vértice com o ID "hakuna\$11" usando a consulta, `g.V("hakuna#1")`. Se a consulta for enviada como um envio baseado em string, o servidor poderá gastar tempo recuperando o ID, o rótulo e todas as propriedades para esse vértice. Se a consulta for enviada como um envio de bytecode, o servidor apenas gastará tempo recuperando o ID e o rótulo do vértice.
Em outras palavras, em vez de enviar uma consulta da seguinte maneira:
```
final Cluster cluster = Cluster.build("localhost")
.port(8182)
.maxInProcessPerConnection(32)
.maxSimultaneousUsagePerConnection(32)
.serializer(Serializers.GRAPHBINARY_V1D0)
.create();
try {
final Client client = cluster.connect();
List results = client.submit("g.V().has('name','pumba').out('friendOf').id()").all().get();
System.out.println(verticesWithNamePumba);
} finally {
cluster.close();
}
```
Em vez disso, envie a consulta usando bytecode, como:
```
final Cluster cluster = Cluster.build("localhost")
.port(8182)
.maxInProcessPerConnection(32)
.maxSimultaneousUsagePerConnection(32)
.serializer(Serializers.GRAPHBINARY_V1D0)
.create();
try {
final GraphTraversalSource g = traversal().withRemote(DriverRemoteConnection.using(cluster));
List