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

Escolha de 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.

Visão geral da alocação de recursos da instância

Cada tipo e tamanho de EC2 instância da Amazon usados no Neptune oferece uma quantidade definida de computação (CPUsv) e memória do sistema. 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=(latencyxconcurrency)/2

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, 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 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 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, 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 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 nossos tipos r5 de r6g instância com baixa utilização da CPU e uma alta taxa de perda de cache do buffer pool, tente usar a família em vez disso. x2g Dessa forma, você obterá a memória adicional de que precisa sem pagar por mais capacidade de CPU.

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 cargas de trabalho gráficas com uso intenso de memória. As instâncias r8g oferecem um desempenho aproximadamente 15 a 20% melhor para consultas gráficas em comparação com as instâncias r7g.

A r8g família tem uma arquitetura de soquete único, o que significa que o desempenho é dimensionado linearmente com a capacidade computacional de um r8g.large para um r8g.16xlarge (o maior tipo da família).

As principais características da r8g família incluem:

A r8g família é ideal para cargas de trabalho de produção que exigem alta capacidade de memória e desempenho consistente. Eles são particularmente eficazes para aplicativos 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 um desempenho 25 a 30% melhor para consultas gráficas no estilo OLTP em comparação com instâncias r6g.

Assim como a r6g família, a r7g família tem uma arquitetura de soquete único, o que significa que o desempenho é dimensionado linearmente com a capacidade computacional de um r7g.large a um r7g.16xlarge (o maior tipo da família).

As principais características da r7g família incluem:

A r7g família é adequada para ambientes de produção com padrões de consulta variados e é particularmente eficaz para cargas de trabalho que se beneficiam da maior largura de banda de memória.

Família r7i de tipos de instância

A r7i família é alimentada por 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 r7i instâncias tem uma arquitetura de CPU Intel de 2 soquetes, semelhante à r5 família. 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 r7i família incluem:

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=(latencyxconcurrency)/2

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

Tipo de instância serverless

O atributo Neptune Serverless 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 (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.