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á.
Preparar-se para migrar do Neo4j para o Neptune
Abordagens da migração
Ao migrar uma aplicação Neo4j para o Neptune, recomendamos uma das duas estratégias: reformulação da plataforma ou refatoração/rearquitetura. Para obter mais informações sobre estratégias de migração, consulte 6 Strategies for Migrating Applications to the Cloud
A abordagem de reformulação da plataforma, às vezes chamada de lift-tinker-and-shift, envolve as seguintes etapas:
Identifique os casos de uso que a aplicação pretende satisfazer.
Modifique o modelo de dados de grafos e a arquitetura de aplicações existentes para melhor atender a essas necessidades de workload usando os recursos do Neptune.
Determine como migrar dados, consultas e outras partes da aplicação de origem para o modelo e a arquitetura de destino.
Essa abordagem retroativa permite migrar a aplicação para o tipo de solução do Neptune que você pode criar se esse fosse um projeto totalmente novo.
A abordagem de refatoração, por outro lado, envolve:
Identificar os componentes da implementação existente, incluindo infraestrutura, dados, consultas e recursos de aplicações.
Encontrar equivalentes no Neptune que possam ser usados para criar uma implementação comparável.
Essa abordagem progressiva busca trocar uma implementação por outra.
Na prática, é provável que você adote uma combinação dessas duas abordagens. É possível começar com um caso de uso, projetar a arquitetura do Neptune de destino, mas depois recorrer à implementação existente do Neo4j para identificar restrições e invariantes que você precisará manter. Por exemplo, talvez você precise continuar a integração com outros sistemas externos ou continuar oferecendo APIs específicas aos consumidores da aplicação de grafos. Com essas informações, é possível determinar quais dados já existem para serem migrados para o modelo de destino e quais devem ser obtidos em outro lugar.
Em outros pontos, você pode começar analisando uma parte específica da implementação do Neo4j como a melhor fonte de informações sobre o trabalho que a aplicação se destina a realizar. Esse tipo de arqueologia na aplicação existente pode ajudar a definir um caso de uso que você pode depois projetar para usar os recursos do Neptune.
Se você estiver criando uma aplicação usando o Neptune ou migrando uma aplicação existente do Neo4j, recomendamos trabalhar retroativamente a partir dos casos de uso para criar um modelo de dados, um conjunto de consultas e uma arquitetura de aplicações que atenda às necessidades empresariais.
Diferenças arquitetônicas entre o Neptune e o Neo4j
Quando os clientes consideram pela primeira vez migrar uma aplicação do Neo4j para o Neptune, geralmente é tentador fazer uma comparação do tipo “igual para igual” com base no tamanho da instância. No entanto, as arquiteturas do Neo4j e do Neptune têm diferenças fundamentais. O Neo4j é baseado em uma abordagem completa em que o carregamento de dados, o ETL de dados, as consultas de aplicações, o armazenamento de dados e as operações de gerenciamento acontecem no mesmo conjunto de recursos computacionais, como instâncias do EC2.
O Neptune, por outro lado, é um banco de dados de grafos focado em OLTP 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 oferece armazenamento de dados para todas as instâncias do 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 principal e as réplicas de leitura no 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.
Diferenças de armazenamento de dados entre o Neptune e o Neo4j
O Neptune usa um modelo de dados de grafos baseado em um modelo quádruplo nativo. Ao migrar os dados para o Neptune, há algumas diferenças na arquitetura do modelo de dados e da camada de armazenamento que você deve conhecer para fazer o melhor uso do armazenamento compartilhado distribuído e escalável que o Neptune oferece:
-
O Neptune não usa nenhum esquema explicitamente definido nem restrições. Ele permite que você adicione nós, bordas e propriedades dinamicamente sem precisar definir o esquema com antecedência. O Neptune não limita os valores e os tipos de dados armazenados, exceto conforme indicado em Limites do Neptune. Como parte da arquitetura de armazenamento do Neptune, os dados também são indexados automaticamente de forma a lidar com muitos dos padrões de acesso mais comuns. Essa arquitetura de armazenamento elimina a sobrecarga operacional da criação e do gerenciamento do esquema do banco de dados e da otimização do índice.
O Neptune oferece uma arquitetura exclusiva de armazenamento distribuído e compartilhado que é escalada automaticamente em blocos de 10 GB à medida que as necessidades de armazenamento do banco de dados aumentam, até 128 tebibytes (TiB). Essa camada de armazenamento é confiável, durável e tolerante a falhas, com dados copiados seis vezes, duas vezes em cada uma das três zonas de disponibilidade. Por padrão, ele oferece a todos os clusters do Neptune uma camada de armazenamento de dados altamente disponível e tolerante a falhas. A arquitetura de armazenamento do Neptune reduz os custos e elimina a necessidade de provisionar ou provisionar em excesso o armazenamento para lidar com o crescimento futuro dos dados.
Antes de migrar os dados para o Neptune, é bom conhecer o modelo de dados de grafos de propriedades e a semântica das transações do Neptune.
Diferenças operacionais entre o Neptune e o Neo4j
O Neptune é um serviço totalmente gerenciado que automatiza muitas das tarefas operacionais normais que você precisaria realizar ao usar bancos de dados on-premises ou autogerenciados, como Neo4j Enterprise ou Community Edition:
Backups automatizados: o Neptune faz backup automático do volume do cluster e retém o backup por um período de retenção especificado por você (de um a 35 dias). Esses backups são contínuos e incrementais para que você possa restaurar rapidamente em qualquer ponto do período de retenção. Quando os dados do backup estão sendo gravados, não há nenhum impacto sobre a performance ou interrupção de serviço do banco de dados.
Snapshots manuais: o Neptune permite que você faça um snapshot do volume de armazenamento do cluster de banco de dados para fazer backup de todo o cluster de banco de dados. Esse tipo de snapshot pode então ser usado para restaurar o banco de dados, fazer uma cópia dele e compartilhá-lo entre contas.
Clonagem: o Neptune é compatível com um atributo de clonagem que permite criar clones econômicos de um banco de dados com rapidez. Os clones usam um protocolo “copy-on-write” para exigir apenas um mínimo de espaço adicional depois de criados. A clonagem de banco de dados é uma forma eficaz de testar novos atributos ou atualizações do Neptune sem interromper o cluster de origem.
-
Monitoramento: o Neptune oferece vários métodos para monitorar o desempenho e o uso do cluster, incluindo:
Status da instância
Integração com o Amazon CloudWatch e AWS CloudTrail
Recursos de log de auditoria
Notificações de eventos
Marcação
-
Segurança: o Neptune oferece um ambiente seguro por padrão. Um cluster reside em uma VPC privada que oferece isolamento de rede de outros recursos. Todo o tráfego é criptografado via SSL e todos os dados são criptografados em repouso usando AWS KMS.
Além disso, o Neptune se integra ao AWS Identity and Access Management (IAM) para oferecer autenticação. Ao especificar as chaves de condição do IAM, é possível usar as políticas do IAM para oferecer controle de acesso refinado sobre as ações de dados.
Diferenças de ferramentas e integração entre o Neptune e o Neo4j
O Neptune tem uma arquitetura para integrações e ferramentas diferente do Neo4j, o que pode afetar a arquitetura da aplicação. O Neptune usa os recursos computacionais do cluster para processar consultas, mas aproveita outros serviços da AWS de primeira classe para funcionalidades como pesquisa de texto completo (usando OpenSearch), ETL (usando Glue), etc. Para obter uma lista completa dessas integrações, consulte Integrações do Neptune.
