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á.
# 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.