Diretrizes operacionais básicas do Amazon Neptune - Amazon Neptune
Evitar tamanhos de instância diferentes.Evitar reinicializações em massaSe você tiver muitos predicados.Transações de longa execuçãoAjuste das consultasBalanceamento de cargaUsar uma instância temporáriaRedimensionar uma instânciaErro de interrupção da tarefa

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.

  • 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 e Monitorar o Neptune 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.

  • 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.

Tópicos

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. Consulte O índice OSGP.

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 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 e Ajustar consultas do Gremlin. Para obter informações sobre como ajustar consultas do SPARQL, consulte Dicas de consulta do SPARQL.

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.

  2. 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.

  3. 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). A operação de carregamento prosseguirá tão rápido quanto a E/S permitir, o que geralmente requer de 60% a 70% dos recursos da CPU.

  4. Carregue os dados usando o carregador do Neptune. O trabalho de carga é executado na instância de banco de dados principal.

  5. 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.).

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 é Failover DBCluster. 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.

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.