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 o tipo certo de instância de banco de dados do 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 vCPUs () 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, CPU os recursos v são alocados para dar suporte a dois (2) threads de execução de consultas por v. CPU 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 vCPUs 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:
nota
SPARQLconsultas, consultas e openCypher consultas de leitura do Gremlin que usam o mecanismo de DFE consulta podem, sob certas circunstâncias, usar mais de um encadeamento 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). OOMexceções ocorrem quando um thread precisa de mais do que a memória máxima alocada para ele (isso 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
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
DEPRECATED— A r4
família foi 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, um r5.xlarge
(4 vCPUs e 32 GiB de memória) tem o dobro da memória vCPUs e de um r5.large
(2 vCPUs e 16 GiB de memória), e um r5.2xlarge
(8 vCPUs e 64 GiB de memória) tem o dobro da memória e de um. vCPUs 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 r5
instâncias tem uma arquitetura Intel CPU 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 EBS volume 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 RDF e literais das propriedades 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 ARM baseado chamado Gravitonr6g
usa o processador Graviton2. Em nossos testes, o processador Graviton2 oferece desempenho 10 a 20% melhor para consultas gráficas de OLTP estilo (restritas). Consultas maiores, OLAP no entanto, podem ter um desempenho um pouco menor com os processadores Graviton2 do que com as da Intel, devido ao desempenho um pouco menor 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
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-v CPU 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ê usa um tipo r5
de r6g
instância com baixa CPU utilização 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 CPU capacidade.
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 vCPUs 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.