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á.
Migração de aplicações do Neo4j para o Neptune
Depois de migrar os dados do Neo4j para o Neptune, a próxima etapa é migrar a aplicação em si. Assim como acontece com os dados, há várias abordagens para migrar a aplicação com base nas ferramentas utilizadas, nos requisitos, nas diferenças de arquitetura, etc. Nesse processo, em geral, é necessário pensar nos fatores descritos abaixo.
Migrar conexões ao transferir dados do Neo4j para o Neptune
Se, no momento, você não usa os drivers Bolt ou gostaria de usar uma alternativa, pode se conectar ao endpoint HTTPS, que concede acesso total aos dados exibidos.
Se você tiver uma aplicação que use o protocolo Bolt, poderá migrar essas conexões com o Neptune e permitir que as aplicações se conectem usando os mesmos drivers utilizados no Neo4j. Para se conectar ao Neptune, talvez seja necessário fazer uma ou mais das seguintes alterações na aplicação:
O URL e a porta precisarão ser atualizados para usar os endpoints e a porta do cluster (o padrão é 8182).
O Neptune exige que todas as conexões usem SSL, então é necessário especificar para cada conexão que ela está criptografada.
O Neptune gerencia a autenticação por meio da atribuição de políticas e perfis do IAM. As políticas e os perfis do IAM oferecem um nível extremamente flexível de gerenciamento de usuários na aplicação, por isso é importante ler e entender as informações na Visão geral do IAM antes de configurar o cluster.
As conexões de parafusos se comportam de maneira diferente de várias maneiras no Neptune e no Neo4j, conforme explicado em Comportamento da conexão do Bolt no Neptune.
É possível encontrar mais informações e sugestões em Práticas recomendadas de Neptune: usar e aparafusar openCypher .
Há exemplos de código de linguagens comumente usadas, como Java, Python, .NET e NodeJS, e de cenários de conexão, como o uso da autenticação do IAM, em Usando o protocolo Bolt para fazer openCypher consultas ao Neptune.
Direcionar consultas para instâncias de cluster ao migrar do Neo4j para o Neptune
As aplicações cliente do Neo4j usam um driver de roteamento
Ao migrar uma aplicação cliente para o Neptune, use os endpoints do Neptune para direcionar consultas com eficiência para uma instância apropriada no cluster:
Todas as conexões com o Neptune devem usar
bolt://em vez debolt+routing://neo4j://ou o URL.O endpoint de cluster conecta-se à instância principal atual do cluster. Use o endpoint de cluster para direcionar solicitações de gravação para a principal.
O endpoint de leitor distribui conexões entre instâncias de réplica de leitura no cluster. Se você tiver um cluster de instância única sem instâncias de réplica de leitura, o endpoint de leitor se conectará à instância principal, que é compatível com operações de gravação. Se o cluster contiver uma ou mais instâncias de réplica de leitura, o envio de uma solicitação de gravação para o endpoint de leitor gerará uma exceção.
Cada instância no cluster também pode ter o próprio endpoint de instância. Use um endpoint de instância se a aplicação cliente precisar enviar uma solicitação a uma instância específica no cluster.
Para obter mais informações, consulte Considerações sobre endpoint do Neptune.
Consistência de dados no Neptune
Ao usar clusters causais do Neo4j, as réplicas de leitura acabam sendo consistentes com os servidores centrais, mas as aplicações cliente podem garantir a consistência causal usando o encadeamento causal
No Neptune, as instâncias de réplica de leitura acabam sendo consistentes com o gravador, com um atraso na réplica geralmente inferior a cem milissegundos. No entanto, até que uma alteração seja replicada, as atualizações nas bordas e nos vértices existentes e as adições de novas bordas e vértices não ficam visíveis em uma instância de réplica. Portanto, se a aplicação precisar de consistência imediata no Neptune lendo cada gravação, use o endpoint de cluster para a operação de leitura após gravação. Esse é o único momento de usar o endpoint de cluster para operações de leitura. Em todas as outras circunstâncias, use o endpoint de leitor para leituras.
Migrar consultas do Neo4j para o Neptune
Embora o suporte para openCypher
Conforme abordado em Otimizações do modelo de dados acima, pode haver modificações no modelo de dados que você precise fazer para criar um modelo de dados de grafos otimizado para o Neptune o que, por sua vez, exigirá alterações nas consultas e nos testes.
O Neo4j oferece uma série de extensões de linguagem específicas do Cypher que não estão incluídas na especificação do openCypher implementada pelo Neptune. Dependendo do caso de uso e do atributo utilizado, pode haver soluções alternativas na linguagem openCypher, no uso da linguagem Gremlin ou por meio de outros mecanismos, conforme descrito em Reescrevendo consultas Cypher para serem executadas no Neptune openCypher .
As aplicações geralmente usam outros componentes de middleware para interagir com o banco de dados, em vez dos próprios drivers do Bolt. Confira Compatibilidade do Neptune com o Neo4j para ver se as ferramentas ou o middleware que você está usando são compatíveis.
No caso de um failover, o driver do Bolt pode continuar se conectando à instância de gravador ou de leitor anterior porque o endpoint de cluster fornecido à conexão foi resolvido para um endereço IP. O tratamento adequado de erros na aplicação deve resolver isso, conforme descrito em Criar uma conexão após o failover.
-
Quando as transações são canceladas devido a conflitos não resolvidos ou a tempos limite de espera de bloqueio, o Neptune responde com uma
ConcurrentModificationException. Para obter mais informações, consulte Códigos de erro do mecanismo. Como melhor prática, os clientes sempre devem capturar e lidar com essas exceções.A
ConcurrentModificationExceptionocorre ocasionalmente quando vários encadeamentos ou várias aplicações estão gravando no sistema simultaneamente. Devido aos níveis de isolamento de transações, esses conflitos às vezes podem ser inevitáveis. O Neptune é compatível com a execução de consultas do Gremlin e do openCypher nos mesmos dados. Isso significa que, em algumas situações, talvez seja necessário pensar no uso do Gremlin, com os recursos de consulta mais poderosos, para realizar algumas das funcionalidades das consultas.
Conforme abordado em Provisionar infraestrutura acima, cada aplicação deve passar por um exercício de dimensionamento correto para garantir que o número de instâncias, os tamanhos das instâncias e a topologia do cluster sejam otimizados para a workload específica da aplicação.
As considerações abordadas aqui para migrar a aplicação são as mais comuns, mas não se trata de uma lista completa. Cada aplicação é exclusiva. Em caso de mais dúvidas, entre em contato com o AWS Support ou entre em contato com a equipe de sua conta.
Migrar atributos e ferramentas específicos do Neo4j
O Neo4j tem uma série de atributos e complementos personalizados com funcionalidades nas quais a aplicação pode confiar. Ao avaliar a necessidade de migrar essa funcionalidade, geralmente é útil investigar se existe uma abordagem melhor na AWS para concretizar o mesmo objetivo. Considerando as diferenças de arquitetura entre o Neo4j e o Neptune, muitas vezes é possível encontrar alternativas eficazes que utilizem outros serviços ou integrações da AWS.
Consulte Compatibilidade do Neptune com o Neo4j para obter uma lista de atributos específicos do Neo4j e soluções alternativas sugeridas.
