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

Melhores práticas operacionais para ISVs

Muitas das diretrizes desta seção são as melhores práticas para todos os clientes, mas elas têm um significado adicional para ISVs.

Atualize seu cluster Neptune com as versões mais recentes

Nas notas de lançamento do Amazon Neptune, você pode ver que cada versão traz várias correções de erros, melhorias de desempenho e novos recursos. Mantenha seus clusters do Neptune na versão mais recente, tanto quanto possível.

Se você encontrar um bug não descoberto anteriormente em sua carga de trabalho e seu cluster estiver na versão mais recente, os engenheiros do Neptune poderão criar um patch privado para seu cluster (se necessário e você quiser). O patch pode durar até a próxima versão, quando essa correção estará disponível ao público em geral. Para ajudar a atualizar seus clusters para a versão mais recente, use a solução Neptune Blue/Green.

Use deltas em vez de excluir e substituir para ingestão de dados

Você pode usar várias técnicas para ingerir ou gravar dados em Neptune. Muitos clientes tentam simplificar a ingestão de dados excluindo e reinserindo o gráfico sempre que uma alteração é recebida no feed. Eles podem adicionar uma last-modified propriedade a cada nó e verificar periodicamente os nós que não foram modificados desde uma data especificada e excluí-los. Embora essas técnicas simplifiquem o processo de ingestão de dados, elas têm implicações de longo prazo na saúde e na escalabilidade do seu cluster Neptune.

Primeiro, Neptune usa a codificação de strings no dicionário. A menos que você especifique explicitamente os IDs nós e bordas, o Neptune gera um GUID representado como uma string para o ID e armazena essa string no dicionário. Se você estiver constantemente excluindo e adicionando objetos, o gerado automaticamente IDs causará inchaço no dicionário.

Em segundo lugar, Netuno se expande para ingerir cerca de 120 K objetos por segundo, no máximo. Se você excluir e adicionar objetos continuamente, consumirá grande parte dessa largura de banda em objetos que basicamente não estão mudando. Isso limita o número de inquilinos que você pode hospedar em um cluster, exige instâncias de gravação maiores nos clusters e exige mais I/O operações. Todos esses fatores aumentam seus custos.

É altamente recomendável que você desenvolva uma forma de calcular o verdadeiro delta do que foi alterado em vez de usar os métodos delete e add. No entanto, algumas fontes de dados não são propícias para isso (por exemplo, chamadas de API que retornam o estado atual ou eventos que não rastreiam exatamente o que mudou). Se sua fonte de dados bruta não for propícia à identificação de alterações, use seus processos de extração, transformação e carregamento (ETL) para calcular o delta. Por exemplo, você pode manter instantâneos de cada captura de dados anterior no formato Parquet, usar AWS Glue para calcular as diferenças entre esses instantâneos e enviar somente as diferenças para Netuno.

Modele como os custos do Neptune evoluirão com seus inquilinos

Se você usa um modelo de silo, pool ou híbrido, seus custos de nuvem aumentarão de acordo com o tamanho de seus inquilinos. Os locatários que exigem mais conexões simultâneas precisam de instâncias maiores ou mais réplicas de leitura do que aqueles com menos conexões simultâneas. O mesmo se aplica aos locatários que exigem uma ingestão de dados mais rápida.

Os três componentes do custo do cluster Neptune são tamanho (e número) da instância, tamanho dos dados (GB/mês) I/O e operações (por milhão). Embora esses custos geralmente sejam específicos da carga de trabalho, eles escalam de acordo com o tamanho e o volume de dados e podem ser medidos usando AWS ferramentas. Acompanhe e entenda as economias de escala em relação aos principais indicadores do tamanho de seus inquilinos, incluindo como seus tamanhos variam ao longo do tempo. Se a imprevisibilidade de suas I/O cobranças afetar suas margens, considere escolher o armazenamento Neptune I/O Optimized para obter um custo mais previsível.

Dimensione seus clusters de acordo com a demanda do cliente

Não existe uma fórmula testada ou comprovada para dimensionar corretamente o tamanho da instância do Neptune. A documentação do Neptune fornece orientação, mas há muitas variáveis para recomendar um mapeamento direto. Essas variáveis incluem, mas não estão limitadas ao seguinte:

Planeje testes para determinar o tamanho ideal para suas cargas de trabalho e perfis de inquilinos. Em geral, recomendamos o uso de instâncias provisionadas para eficiência de custos e previsibilidade. Se suas metas de experiência do cliente priorizam a escalabilidade ideal em relação aos custos, considere usar instâncias Neptune Serverless para garantir uma experiência mais consistente, independentemente das flutuações da carga de trabalho.

Se as cargas de trabalho de leitura do locatário tiverem uma variabilidade significativa em seus altos e baixos, combine as instâncias do Neptune Serverless com o auto-scaling do Neptune.  Geralmente, leva de 10 a 15 minutos para que uma nova réplica de leitura fique on-line depois de inicializada. Isso significa que o auto-scaling sozinho pode lidar com mudanças prolongadas no tráfego, mas não é suficiente para alterar rapidamente os picos de atividade. Ao combinar o escalonamento automático do Neptune Serverless e do Neptune, você pode aumentar ou reduzir as instâncias e escalar o número de réplicas de leitura para dentro e para fora.

Se seus locatários tiverem perfis de carga de trabalho ou contratos de nível de serviço (SLAs) significativamente diferentes, considere usar endpoints personalizados e réplicas de leitura dedicadas para direcionar o tráfego para instâncias otimizadas para esse tráfego. A otimização pode incluir um tamanho diferente da instância, padrões de consulta específicos ou pré-aquecimento do cache do buffer.