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á.
Diferenças arquitetônicas entre o Neptune e o Neo4j
Quando os clientes consideram pela primeira vez migrar um aplicativo do Neo4j para o Neptune, geralmente é tentador fazer uma comparação com base no tamanho da instância. like-to-like No entanto, as arquiteturas do Neo4j e do Neptune têm diferenças fundamentais. O Neo4j é baseado em uma all-in-one abordagem em que o carregamento de dados, os dadosETL, as consultas de aplicativos, o armazenamento de dados e as operações de gerenciamento acontecem no mesmo conjunto de recursos computacionais, como instâncias. EC2
O Neptune, por outro lado, é OLTP um banco de dados gráfico focado em que a arquitetura separa as responsabilidades e onde os recursos são dissociados para que possam ser escalados de forma dinâmica e independente.
Ao migrar do Neo4j para o Neptune, determine os requisitos de durabilidade, disponibilidade e escalabilidade dos dados da aplicação. A arquitetura de cluster do Neptune simplifica o design de aplicações que exigem alta durabilidade, disponibilidade e escalabilidade. Com uma compreensão da arquitetura de cluster do Neptune, é possível então projetar uma topologia de cluster do Neptune para atender a esses requisitos.
Arquitetura de cluster do Neo4j
Muitas aplicações de produção usam o agrupamento causal
Os servidores centrais oferecem durabilidade de dados e tolerância a falhas replicando dados com o protocolo Raft.
As réplicas de leitura usam o envio de logs de transações para replicar dados de forma assíncrona para workloads de alta taxa de throughput de leitura.
Cada instância em um cluster, seja servidor central ou réplica de leitura, contém uma cópia completa dos dados de grafos.
Arquitetura do cluster do Neptune
Um cluster do Neptune é composto por uma instância de gravador principal e até 15 instâncias de réplica de leitura. Todas as instâncias no cluster compartilham o mesmo serviço de armazenamento distribuído subjacente que é separado das instâncias.
A instância de gravador principal coordena todas as operações de gravação no banco de dados e é escalável verticalmente para oferecer suporte flexível para diferentes workloads de gravação. Ela também é compatível com operações de leitura.
-
As instâncias de réplica de leitura são compatíveis com operações de leitura do volume de armazenamento subjacente e permitem que você escale horizontalmente para suportar altas workloads de leitura. Elas também oferecem alta disponibilidade servindo como destinos de failover para a instância principal.
nota
Para workloads de gravação pesadas, é melhor escalar as instâncias da réplica de leitura para o mesmo tamanho da instância de gravador, a fim de garantir que os leitores possam permanecer consistentes com as alterações dos dados.
O volume de armazenamento subjacente escala a capacidade de armazenamento automaticamente à medida que os dados no banco de dados aumentam, até 128 tebibytes (TiB) de armazenamento.
Os tamanhos das instâncias são dinâmicos e independentes. Enquanto o cluster estiver em execução, todas as instâncias poderão ser redimensionadas e as réplicas de leitura poderão ser adicionadas ou removidas.
O atributo Neptune Serverless pode aumentar e reduzir verticalmente a escala da capacidade computacional de modo automático à medida que a demanda aumenta e diminui. Isso não só pode diminuir a sobrecarga administrativa, mas também permite configurar o banco de dados para lidar com grandes picos de demanda sem prejudicar o desempenho nem exigir provisionamento excessivo.
É possível interromper um cluster de banco de dados por até sete dias.
O Neptune também é compatível com o ajuste de escala automático, para ajustar automaticamente os tamanhos das instâncias de leitor com base na workload.
Usando o atributo de banco de dados global do Neptune, é possível espelhar um cluster em até cinco outras regiões.
O Neptune também é tolerante a falhas por design:
O volume do cluster que fornece armazenamento de dados para todas as instâncias no cluster abrange várias zonas de disponibilidade (AZs) em uma única Região da AWS. Cada AZ contém uma cópia completa dos dados do cluster.
Se a instância principal ficar indisponível, o Neptune automaticamente fará failover para uma réplica de leitura existente sem perda de dados, normalmente em menos de trinta segundos. Se não houver réplicas de leitura existentes no cluster, o Neptune provisionará automaticamente uma nova instância principal: novamente, sem perda de dados.
O que tudo isso significa é que, ao migrar de um cluster causal do Neo4j para o Neptune, você não precisa arquitetar a topologia do cluster explicitamente para obter alta durabilidade e alta disponibilidade dos dados. Isso permite dimensionar o cluster para as workloads de leitura e gravação esperadas e todos os requisitos de maior disponibilidade que você possa ter, de apenas algumas maneiras:
Para escalar as operações de leitura, adicione instâncias de réplica de leitura ou habilite a funcionalidade Neptune Serverless.
Para melhorar a disponibilidade, distribua a instância primária e leia as réplicas em seu cluster em várias zonas de disponibilidade (AZs).
Para reduzir o tempo de failover, provisione pelo menos uma instância de réplica de leitura que possa servir como destino de failover para a principal. É possível determinar a ordem em que as instâncias de réplica de leitura são promovidas à instância principal após uma falha, atribuindo uma prioridade a cada réplica. É uma prática recomendada garantir que um destino de failover tenha uma classe de instância capaz de lidar com a workload de gravação da aplicação se for promovido para principal.
