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á.
# Escolher os tipos de instância para o Amazon Neptune
O Amazon Neptune oferece vários tamanhos e famílias de instâncias diferentes que oferecem recursos distintos, adequados a diferentes workloads de grafos. Esta seção tem como objetivo ajudar você a escolher o melhor tipo de instância para suas necessidades.
Para conhecer os preços de cada tipo de instância nessas famílias, consulte a [página Preços do Neptune](https://aws.amazon.com/neptune/pricing/).
## Visão geral da alocação de recursos da instância
Cada tipo e tamanho de instância do Amazon EC2 usado no Neptune oferece uma quantidade definida de computação (v) e memória do sistema. CPUs O armazenamento primário do Neptune é externo às instâncias de banco de dados em um cluster, o que permite que a capacidade de computação e armazenamento sejam escalados de forma independente um do outro.
Esta seção se concentra em como os recursos computacionais podem ser escalados e nas diferenças entre cada uma das várias famílias de instâncias.
Em todas as famílias de instâncias, os recursos de vCPU são alocados para oferecer compatibilidade com dois (2) threads de execução de consultas por vCPU. Essa compatibilidade é determinada pelo tamanho da instância. Ao determinar o tamanho adequado de uma instância de banco de dados Neptune específica, é necessário considerar a possível simultaneidade da aplicação e a latência média das consultas. Você pode estimar o número de v CPUs necessário da seguinte forma, em que a latência é medida como a latência média da consulta em segundos e a simultaneidade é medida como o número alvo de consultas por segundo:
```
vCPUs = (latency x concurrency) / 2
```
**nota**
As consultas SPARQL, openCypher e de leitura do Gremlin que usam o mecanismo de consulta DFE podem, em determinadas circunstâncias, usar mais de um thread de execução por consulta. Ao dimensionar inicialmente o cluster de banco de dados, comece com a suposição de que cada consulta consumirá um único thread de execução por execução e aumente a escala verticalmente se você observar uma pressão de retorno na fila de consultas. Isso pode ser observado usando o`/gremlin/status`,`/oc/status`, ou `/sparql/status` APIs, ou também pode ser observado usando a `MainRequestsPendingRequestsQueue` CloudWatch métrica.
A memória do sistema em cada instância é dividida em duas alocações principais: cache do grupo do buffer e memória do thread de execução da consulta.
Aproximadamente dois terços da memória disponível em uma instância são alocados para o cache do grupo de buffer. O cache do grupo de buffer é usado para armazenar em cache os componentes do grafo usados mais recentemente para acesso mais rápido às consultas que acessam repetidamente esses componentes. Instâncias com uma quantidade maior de memória do sistema têm caches maiores de grupo de buffer que podem armazenar mais do grafo localmente. Um usuário pode ajustar a quantidade adequada de cache do pool de buffer monitorando as métricas de acertos e erros do cache de buffer disponíveis em. CloudWatch
Convém aumentar o tamanho da instância se a taxa de acerto do cache cair abaixo de 99,9% por um período consistente. Isso sugere que o grupo de buffer não é grande o suficiente e que o mecanismo precisa buscar dados do volume de armazenamento subjacente com frequência maior do que é eficiente.
O terço restante da memória do sistema é distribuído uniformemente entre os threads de execução de consulta, com alguma memória restante para o sistema operacional e um pequeno grupo dinâmico para os threads usarem conforme necessário. A memória disponível para cada thread aumenta ligeiramente de um tamanho de instância para o próximo até um tipo de instância `8xl`, tamanho em que a memória alocada por thread atinge o máximo.
A hora de adicionar mais memória de thread é quando você encontra um `OutOfMemoryException` (OOM). As exceções de OOM ocorrem quando um thread precisa de mais do que a memória máxima alocada para ele (não é o mesmo que a instância inteira ficar sem memória).
## Tipos de instância `t3` e `t4g`
A família de instâncias `t3` e `t4g` oferece uma opção de baixo custo para começar a usar um banco de dados de grafos e também para desenvolvimento e teste iniciais. Essas instâncias são elegíveis para a oferta de [nível gratuito do Neptune](https://aws.amazon.com/neptune/free-trial/), que permite que novos clientes usem o Neptune sem nenhum custo nas primeiras 750 horas de instância usadas em uma conta AWS independente ou acumuladas AWS em uma organização com faturamento consolidado (conta do pagador).
As instâncias `t3` e `t4g` são oferecidas somente na configuração de tamanho médio (`t3.medium` e `t4g.medium`).
Elas não se destinam ao uso em um ambiente de produção.
Como essas instâncias têm recursos muito restritos, elas não são recomendadas para testar o tempo de execução da consulta nem o desempenho geral do banco de dados. Para avaliar o desempenho da consulta, faça a atualização para as outras famílias de instância.
## Família `r4` de tipos de instância
*OBSOLETA*: a família `r4` era oferecida quando o Neptune foi lançado em 2018, mas agora os tipos de instância mais novos oferecem preço/desempenho muito melhores. A partir da versão [1.1.0.0](engine-releases-1.1.0.0.md) do mecanismo, o Neptune não é mais compatível com tipos de instância `r4`.
## Família `r5` de tipos de instância
A família `r5` contém tipos de instância otimizada para memória que funcionam bem para a maioria dos casos de uso de grafos. A família `r5` contém tipos de instância de `r5.large` a `r5.24xlarge`. Elas são escaladas linearmente no desempenho computacional à medida que você aumenta de tamanho. Por exemplo, an `r5.xlarge` (4 v CPUs e 32GiB de memória) tem o dobro de v CPUs e memória de an `r5.large` (2 v CPUs e 16GiB de memória), e an `r5.2xlarge` (8 v CPUs e 64GiB de memória) tem o dobro de v e memória de an. CPUs `r5.xlarge` Você pode esperar que o desempenho da consulta seja escalado diretamente com a capacidade computacional até o tipo de instância `r5.12xlarge`.
A família de instâncias `r5` tem uma arquitetura de CPU Intel de 2 soquetes. A `r5.12xlarge` e tipos menores usam um único soquete e a memória do sistema pertencente a esse processador de soquete único. Os tipos `r5.16xlarge` e `r5.24xlarge` usam os dois soquetes e a memória disponível. Como há alguma sobrecarga de gerenciamento de memória necessária entre dois processadores físicos em uma arquitetura de 2 soquetes, os ganhos de desempenho ao aumentar a escala verticalmente de um tipo de instância `r5.12xlarge` para `r5.16xlarge` ou `r5.24xlarge` instância não são tão lineares quanto os obtidos ao aumentar a escala verticalmente em tamanhos menores.
## Família `r5d` de tipos de instância
O Neptune tem um [atributo de cache de pesquisa](feature-overview-lookup-cache.md) que pode ser usado para melhorar o desempenho de consultas que precisam buscar e gerar um grande número de valores de propriedades e literais. Esse atributo é usado principalmente por clientes com consultas que precisam gerar vários atributos. O cache de pesquisa aumenta o desempenho dessas consultas ao buscar esses valores de atributos localmente, em vez de pesquisar cada um deles repetidamente no armazenamento indexado do Neptune.
O cache de pesquisa é implementado usando um volume do EBS NVMe anexado em um tipo de `r5d` instância. Ele é habilitado usando o grupo de parâmetros de um cluster. À medida que os dados são obtidos do armazenamento indexado do Neptune, os valores das propriedades e os literais RDF são armazenados em cache nesse volume. NVMe
Se você não precisar do atributo de cache de pesquisa, use um tipo de instância `r5` padrão em vez de um `r5d`, para evitar o custo mais alto da `r5d`.
A família `r5d` tem tipos de instância nos mesmos tamanhos da família `r5`, de `r5d.large` a `r5d.24xlarge`.
## Família `r6g` de tipos de instância
AWS desenvolveu seu próprio processador baseado em ARM chamado [Graviton](https://aws.amazon.com/ec2/graviton/), que oferece melhor desempenho price/performance do que os equivalentes Intel e AMD. A família `r6g` usa o processador Graviton2. Em nossos testes, o processador Graviton2 oferece desempenho de 10% a 20% melhor para consultas de grafos no estilo OLTP (restritas). No entanto, consultas OLAP maiores podem ter um desempenho um pouco inferior com os processadores Graviton2 do que com as com processadores Intel, devido ao desempenho um pouco inferior de paginação na memória.
Também é importante observar que a família `r6g` tem uma arquitetura de soquete único, o que significa que o desempenho é escalado linearmente com a capacidade computacional de uma `r6g.large` para uma `r6g.16xlarge` (o maior tipo da família).
## Família `r6i` de tipos de instância
As [instâncias R6i da Amazon](https://aws.amazon.com/ec2/instance-types/r6i/) são alimentadas por processadores escaláveis Intel Xeon de 3ª geração (codinome Ice Lake) e são ideais para workloads com uso intenso de memória. Como regra, elas oferecem desempenho de preço de computação até 15% melhor e largura de banda de memória até 20% maior por vCPU do que tipos de instância R5 comparáveis.
## Família `x2g` de tipos de instância
Alguns casos de uso de grafos apresentam melhor desempenho quando as instâncias têm caches de grupo de buffer maiores. A família `x2g` foi lançada para oferecer maior compatibilidade com esses casos de uso. A `x2g` família tem uma memory-to-vCPU proporção maior do que a `r6g` família `r5` ou. As instâncias `x2g` também usam o processador Graviton2 e têm muitas das mesmas características de desempenho dos tipos de instância `r6g`, além de um cache maior de grupo de buffer.
Se você estiver usando um tipo de instância `r5` ou `r6g` com baixa utilização da CPU e uma alta taxa de perda de cache do grupo de buffer, tente usar a família `x2g`. Dessa forma, você obterá a memória adicional de que precisa sem pagar por mais capacidade de CPU.
## Família `x2iezn` de tipos de instância
A `x2iezn` família fornece instâncias otimizadas para memória alimentadas por processadores escaláveis Intel Xeon com desempenho de alta frequência. Essas instâncias oferecem uma alta memory-to-vCPU taxa (32 GiB por vCPU), o que as torna adequadas para cargas de trabalho gráficas com uso intenso de memória que se beneficiam do alto desempenho de um único thread.
Os principais recursos incluem até 4,5 frequências turbo de GHz todos os núcleos e disponibilidade em tamanhos de 2xlarge a 12xlarge.
## Família `x2iedn` de tipos de instância
A `x2iedn` família fornece instâncias otimizadas para memória com armazenamento NVMe SSD local. Essas instâncias combinam alta capacidade de memória (32 GiB por vCPU) com armazenamento local rápido, tornando-as ideais para cargas de trabalho gráficas que se beneficiam tanto de grandes caches na memória quanto de cache de disco local de alto desempenho.
Equipadas com processadores escaláveis Intel Xeon de 3ª geração, essas instâncias estão disponíveis em tamanhos de xlarge a 32xlarge e são otimizadas para bancos de dados gráficos de grande escala que exigem desempenho de memória e armazenamento.
## Família `r8g` de tipos de instância
A `r8g` família contém tipos de instância otimizados para memória, equipados com processadores AWS Graviton4. Essas instâncias oferecem melhorias significativas de desempenho em relação às gerações anteriores, tornando-as adequadas para workloads de grafos com uso intenso de memória. As instâncias r8g oferecem um desempenho aproximadamente 15 a 20% melhor para consultas de grafos em comparação às instâncias r7g.
A `r8g` família usa uma plataforma de dois soquetes. Os tipos de `r8g.large` instância são `r8g.24xlarge` executados em um único soquete, o que significa que o desempenho é escalonado linearmente com a capacidade computacional em toda essa faixa. O `r8g.48xlarge` usa os dois soquetes e é o maior tipo de instância da família; assim como em outras famílias de soquetes duplos, os ganhos de desempenho ao escalar de `r8g.24xlarge` até `r8g.48xlarge` podem não ser perfeitamente lineares devido à sobrecarga de gerenciamento de memória entre soquetes.
As principais características da família `r8g` incluem:
+ Equipado com processadores AWS Graviton4 baseados em ARM
+ Maior largura de banda de memória por vCPU em comparação com as gerações anteriores
+ Excelente price/performance proporção para consultas gráficas (restritas) no estilo OLTP e cargas de trabalho analíticas no estilo OLAP
+ Recursos aprimorados de gerenciamento de memória que beneficiam percursos complexos de grafos
A família `r8g` é ideal para workloads de produção que exigem alta capacidade de memória e desempenho consistente. Eles são particularmente eficazes em aplicações com altos requisitos de simultaneidade de consultas.
## Família `r7g` de tipos de instância
A `r7g` família usa o processador AWS Graviton3, que oferece melhor desempenho do que as instâncias price/performance anteriores baseadas em Graviton2. Nos testes, o processador Graviton3 oferece desempenho de 25 a 30% melhor para consultas de grafos no estilo OLTP em comparação com instâncias r6g.
Assim como a família `r6g`, a família `r7g` tem arquitetura de soquete único, o que significa que é escalada linearmente com capacidade computacional de uma `r7g.large` para uma `r7g.16xlarge` (o maior tipo da família).
As principais características da família `r7g` incluem:
+ Equipado com processadores AWS Graviton3 baseados em ARM
+ Melhor desempenho de paginação na memória em comparação com o r6g, beneficiando workloads OLTP e OLAP
+ Eficiência aprimorada do cache do grupo de buffer
+ Menor latência para operações com uso intenso de memória
A família `r7g` é adequada para ambientes de produção com padrões de consulta variados e é particularmente eficaz para workloads que se beneficiam de maior largura de banda de memória.
## Família `r7i` de tipos de instância
A família `r7i` tem tecnologia de processadores escaláveis Intel Xeon de 4ª geração (codinome Sapphire Rapids) e oferece melhorias significativas em relação às instâncias r6i. Essas instâncias oferecem uma computação aproximadamente 15% melhor price/performance e uma largura de banda de memória até 20% maior por vCPU do que os tipos de instância r6i comparáveis.
A família de instâncias `r7i` tem uma arquitetura de CPU Intel de dois soquetes, semelhante à família `r5`. A `r7i.12xlarge` e tipos menores usam um único soquete e a memória do sistema pertencente a esse processador de soquete único. Os tipos `r7i.16xlarge` e `r7i.24xlarge` usam os dois soquetes e a memória disponível. Como há alguma sobrecarga de gerenciamento de memória necessária entre dois processadores físicos em uma arquitetura de 2 soquetes, os ganhos de desempenho ao aumentar a escala verticalmente de um tipo de instância `r7i.12xlarge` para `r7i.16xlarge` ou `r7i.24xlarge` instância não são tão lineares quanto os obtidos ao aumentar a escala verticalmente em tamanhos menores.
As principais características da família `r7i` incluem:
+ Processadores Intel Xeon escaláveis de quarta geração
+ Desempenho dimensionado linearmente com capacidade computacional de até r7i.12xlarge
+ Gerenciamento aprimorado de memória entre processadores físicos na arquitetura de dois soquetes
+ Desempenho aprimorado para operações de grafos com uso intenso de memória
Para todas essas famílias de instâncias, você pode estimar o número de v CPUs necessário usando a mesma fórmula mencionada anteriormente:
```
vCPUs = (latency x concurrency) / 2
```
Em que a latência é medida como a latência média da consulta em segundos e a simultaneidade é medida como o número de destino de consultas por segundo.
## Tipo de instância `serverless`
O atributo [Neptune Serverless](neptune-serverless.md) pode escalar o tamanho da instância dinamicamente com base nas necessidades de recursos de uma workload. Em vez de calcular quantos v CPUs são necessários para seu aplicativo, o Neptune Serverless permite que [você defina limites inferior e superior na capacidade computacional](neptune-serverless-capacity-scaling.md) (medida em Neptune Capacity Units) para as instâncias em seu cluster de banco de dados. Workloads com utilização variável podem ser otimizadas em termos de custo usando instâncias sem servidor em vez de provisionadas.
É possível configurar instâncias provisionadas e sem servidor no mesmo cluster de banco de dados para obter uma configuração ideal de custo-desempenho.