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 instância do Amazon EC2 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, 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 vCPUs necessárias 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 de destino de consultas por segundo:
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 as /sparql/status APIs /gremlin/status/oc/status,, 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
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, uma r5.xlarge (4 vCPUs e 32 GiB de memória) tem o dobro das vCPUs e a memória de uma r5.large (2 vCPUs e 16 GiB de memória), e uma r5.2xlarge (8 vCPUs e 64 GiB de memória) tem o dobro das vCPUs e da memória de uma 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 EBS conectado ao NVMe em um tipo de instância r5d. 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 Gravitonr6g 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
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 taxa de memory-to-v CPU maior do que a r6g família r5 or. 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 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.
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 quantas vCPUs são necessárias para a aplicação, o Neptune Serverless permite que você defina limites inferior e superior na capacidade computacional (medida em unidades de capacidade do Neptune) para as instâncias no 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.
