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 preço/desempenho 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.

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.