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

Pilar Otimização de custos

O pilar de otimização de custos do AWS Well-Architected Framework se concentra em evitar custos desnecessários. As recomendações a seguir podem ajudar você a atender aos princípios de design de otimização de custos e às práticas recomendadas de arquitetura do Amazon Neptune.

O pilar de otimização de custos foca as seguintes áreas principais:

Entender os padrões de uso e os serviços necessários

O Neptune é uma boa opção para sua workload se seu modelo de dados tiver uma estrutura gráfica perceptível e suas consultas precisarem explorar relacionamentos e percorrer vários saltos. Um banco de dados de grafos não é um bom ajuste para os seguintes padrões:

Considere se o uso de vários bancos de dados com propósito específico em conjunto para padrões de acesso específicos pode atender a todas as suas necessidades. Por exemplo:

Entenda os custos associados aos serviços que interagem e complementam o Neptune, incluindo o seguinte:

Selecionar recursos com atenção ao custo

Os preços do Neptune são baseados no custo por hora da instância (ou nas unidades de computação do Neptune consumidas sem servidor), na E/S de dados e no uso do armazenamento. As instâncias representam, em média, 85% do custo total, portanto, o dimensionamento correto pode ter implicações de custo significativas. A melhor maneira de dimensionar corretamente as instâncias é testar a performance da aplicação em várias instâncias e comparar os seguintes fatores:

Os custos das instâncias são escalados linearmente com o tamanho na mesma família de instâncias. O custo por hora da instância db.r6i.2xlarge é o dobro do da instância db.r6i.xlarge, e também tem o dobro da alocação de recursos. A instância db.r6i.24xlarge é 24 vezes o custo por hora da instância db.r6i.xlarge.

Estime o número de consultas simultâneas que o sistema pode processar. Você pode ter entre zero e quinze réplicas de leitura para processar consultas somente para leitura. Se seus requisitos variarem de acordo com a hora do dia, da semana ou do mês, você poderá usar várias instâncias menores para escalar de acordo com uma programação. Cada vCPU em uma instância fornece dois threads para lidar com consultas simultâneas. Três réplicas de db.r6i.xlarge de leitura, com 4 vCPUs cada, podem lidar com 24 consultas simultâneas.

Se, em vez disso, seu volume de tráfego for medido em consultas por segundo (QPS), você deverá experimentar para determinar a latência média de suas consultas. O número de consultas por segundo que um cluster do Neptune pode suportar é igual a vCPU × 2 × (1 second/average query latency). Por exemplo, se você tiver 4 vCPUs e uma latência de consulta de 100 milissegundos (0,1 segundo), QPS = 4 × 2 × (1s/0.1s) = 80 queries per second.

As instâncias provisionadas são mais baratas do que as sem servidor para workloads contínuas, estáveis e previsíveis. A tecnologia sem servidor oferece oportunidades para otimizar custos quando você tem uma workload que exige um uso muito alto por apenas algumas horas por dia (por exemplo, db.r6i.4xlarge) e, em seguida, quase nenhum tráfego pelo restante do dia (por exemplo, 1 unidade de computação Neptune). Uma instância sem servidor que aumenta a escala verticalmente por algumas horas e depois diminui será mais barata do que usar uma instância provisionada db.r6i.4xlarge o dia todo.

Considere fazer o upgrade para o Neptune 1.4.5.0 ou posterior e r8g utilizar instâncias para obter uma melhor taxa de transferência de leitura e gravação a um custo menor do que as instâncias de gerações mais antigas, como ou. r7g r6g Para obter mais informações, veja uma relação preço-desempenho de consultas de gravação 4,7 vezes melhor com instâncias AWS Graviton4 R8g usando o Amazon Neptune v1.4.5 (postagem no blog).AWS

Os clusters do Neptune são criados por padrão com armazenamento padrão (se você criar usando o console, o padrão será I/O-optimized storage). With I/O-optimized storage, you pay a slightly higher cost for storage and instances, but there are no I/O costs. This leads to more predictable recurring costs, but if your I/O usage is generally low, it may be more cost efficient to utilize standard storage. If you intend to load a lot of data initially, you can optimize cost by choosing I/O selecionar o armazenamento otimizado, realizar o carregamento inicial de dados e, em seguida, alternar para o armazenamento padrão. O tipo de armazenamento afeta somente o modelo de cobrança e não tem nenhuma diferença técnica na configuração do cluster ou da instância de banco de dados Neptune. Você pode alterar o tipo de armazenamento uma vez a cada 30 dias. Depois de 30 dias, verifique seus custos detalhados do Neptune e use a página de preços do Neptune para calcular se seus custos teriam sido maiores usando -optimization. I/O-optimized storage. If they would have been, continue to use standard storage, otherwise switch back to I/O

Escolher a melhor configuração de instância do Neptune para sua workload

Se você criou o seu Conta da AWS antes de 15 de julho de 2025, pode usar o nível AWS gratuito para fazer experiências de nível básico com o Neptune. As 750 horas gratuitas de uso das instâncias db.t3.medium e db.t4g.medium são suficientes para que você tenha uma boa compreensão do Neptune em baixa escala. Seu cluster permanecerá após o término do período de teste gratuito, embora você seja cobrado pelo uso a partir desse momento.

As db.t4g.medium instâncias db.t3.medium e são boas para ambientes de desenvolvimento de baixo custo em que você não está usando o OpenCypher, o Graph Explorer ou várias integrações generativas de IA. Essas instâncias têm uma RAM-to-vCPU proporção menor (2:1) do que as instâncias R familiares (8:1) ou as instâncias X familiares (16:1). Essa taxa reduzida impede o uso de estatísticas do mecanismo DFE que permitem o desempenho do OpenCypher, as integrações do GenAI (para informar o LLM sobre o esquema gráfico) e o Graph Explorer. Os perfis de desempenho podem diferir significativamente ao usar instâncias T familiares, especialmente para as cargas de trabalho mencionadas anteriormente. Essas instâncias também podem aumentar a ocorrência de OutOfMemoryExceptions quando as consultas navegam por uma parte significativa do gráfico. Para determinar se a última condição pode ser afetada, verifique a BufferCacheHitRatio CloudWatch métrica.

É altamente desaconselhável fazer qualquer teste de desempenho ou carga com instâncias T familiares, pois você pode ter resultados inconsistentes que não são indicativos de um ambiente de produção.

As instâncias provisionadas oferecem a melhor combinação de custo e performance quando sua workload é razoavelmente estável e previsível. Escolha o tamanho da instância com base na simultaneidade de solicitações necessária e na complexidade da consulta. Uma maior simultaneidade requer mais v. CPUs Uma maior complexidade de consulta requer mais RAM. Use a MainRequestQueuePendingRequests CloudWatch métrica para determinar o impacto da primeira (maior que zero representa mais solicitações simultâneas do que podem ser tratadas). Use a BufferCacheHitRatio CloudWatch métrica para determinar o impacto da última. Uma proporção que geralmente cai abaixo de 99,9% sugere que não há RAM suficiente para conter a parte funcional do grafo que está sendo avaliado, o que resulta em trocas de cache mais frequentes. Se a família R de instâncias fornecer simultaneidade suficiente, mas não memória RAM suficiente, considere experimentar a X família de instâncias.

Os casos de uso ideais para instâncias sem servidor estão descritos na documentação do Neptune. Se você não tiver certeza se provisionado ou sem servidor é o melhor para você, e o custo é sua principal preocupação, teste sua carga de trabalho sem servidor para determinar o número de NCUs usados e comparar o custo de provisioned () com serverless (). N hours × hourly provisioned cost sum of NCUs × hourly cost per NCU Se você não tiver certeza sobre a instância de provisionamento de tamanho equivalente, uma NCU equivale a aproximadamente 2 GB de RAM e a vCPU e a rede associadas. Se sua instância provisionada for da r6i família, a proporção será de 1 vCPU por 8 GB de RAM, ou 4 NCUs, junto com a rede associada. A calculadora de preços do Amazon Neptune também fornece uma comparação para ajudá-lo a decidir sua configuração de custo ideal.

Ao usar a tecnologia sem servidor para instâncias primárias e de réplica, lembre-se de que as réplicas de leitura nos níveis de promoção 0 e 1 serão escaladas de acordo com a instância do gravador para que sejam escaladas adequadamente se ocorrer um evento de failover. NCUs Defina seus limites de NCU para essas instâncias com base em quais de suas instâncias, do gravador ou do leitor, recebem mais tráfego.

Em ambientes em que o cluster não é necessário 24 horas por dia, 7 dias por semana, considere escrever scripts que desativarão as instâncias do Neptune quando não estiverem em uso, e que as iniciarão novamente antes de serem usadas. As instâncias do Neptune serão reiniciadas automaticamente a cada sete dias para garantir que as atualizações de manutenção necessárias sejam aplicadas. Se você pretende deixar as instâncias desativadas por longos períodos, use um script semanal para desligá-las novamente.

Armazenamento e transferência de dados do tamanho certo

Consultas mais eficientes (por exemplo, consultas que precisam tocar menos nós, bordas e propriedades no gráfico) exigem menos I/O transferência e, potencialmente, podem usar instâncias menores porque é necessário menos cache de buffer. Use o perfil ou explique os endpoints da sua linguagem de consulta para otimizá-la, e considere otimizar seu modelo de grafo para a performance da consulta.

O Neptune usa codificação de dicionário em strings grandes, e esse dicionário é otimizado para performance, não eficiência. Se você tiver cadeias de caracteres grandes BLOBs, JSON ou que mudam com frequência, considere armazená-las fora do Neptune no Amazon S3, no Amazon DynamoDB ou no Amazon DocumentDB e armazene somente uma referência dentro do nó do Neptune.

Em alguns casos, escolher um tamanho de instância maior pode ser mais barato. Se seus I/O custos forem muito altos devido a uma baixaBufferCacheHitRatio, é possível que o cache de buffer maior reduza significativamente esse custo. Isso porque todos os dados caberiam no cache em vez de serem frequentemente trocados do armazenamento e incorrerem na I/O taxa de transferência.

Neptune usa clonagem copy-on-write. Ao clonar para dividir um grafo em vários fragmentos, pode ser mais eficiente não excluir os dados indesejados no cluster clonado, pois isso envolverá a criação de novas páginas de dados, resultando em maiores custos de armazenamento. Os dados que não foram alterados antes do evento de clonagem existirão em uma única página de dados compartilhada entre os dois clusters e serão cobrados somente por essa cópia única.

Não habilite o índice OSGP nem use instâncias R5d, a menos que você tenha testado para confirmar que elas fazem uma diferença substancial em sua workload. Ambos foram projetados para cenários que ocorrem raramente e podem aumentar seus custos com ganhos mínimos ou inexistentes.