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 dados do Neo4j para o Neptune
Ao realizar uma migração do Neo4j para o Amazon Neptune, a migração dos dados é uma etapa importante do processo. Há várias abordagens para migrar dados. A abordagem correta é determinada pelas necessidades da aplicação, pelo tamanho dos dados e pelo tipo de migração desejada. No entanto, muitas dessas migrações exigem a avaliação das mesmas considerações, das quais várias são destacadas abaixo.
nota
Consulte Migração de um banco de dados gráfico Neo4j para Neptune com um utilitário totalmente automatizado
Avaliar a migração de dados do Neo4j para o Neptune
A primeira etapa ao avaliar qualquer migração de dados é determinar como você migrará os dados. As opções dependem da arquitetura da aplicação que está sendo migrada, do tamanho dos dados e das necessidades de disponibilidade durante a migração. Em geral, as migrações tendem a se enquadrar em uma das duas categorias: on-line ou off-line.
As migrações off-line tendem a ser as mais simples de realizar, porque a aplicação não aceita tráfego de leitura ou gravação durante a migração. Depois que a aplicação parar de aceitar tráfego, os dados poderão ser exportados, otimizados, importados e a aplicação testada antes de ser reabilitada.
As migrações on-line são mais complexas, pois a aplicação ainda precisa aceitar tráfego de leitura e gravação enquanto os dados estão sendo migrados. As necessidades exatas de cada migração on-line podem ser diferentes, mas geralmente a arquitetura seria semelhante à seguinte:
Um feed de alterações contínuas no banco de dados precisa ser habilitado no Neo4j configurando os fluxos do Neo4j como fonte para um cluster do Kafka
. Depois que isso for concluído, uma exportação do sistema em execução poderá ser feita, seguindo as instruções em Exportar dados do Neo4j ao migrar para o Neptune e o horário indicado para correlação posterior com o tópico do Kafka.
Os dados exportados são então importados para o Neptune, seguindo as instruções em Importar dados do Neo4j ao migrar para o Neptune.
Os dados alterados dos fluxos do Kafka podem então ser copiados no cluster do Neptune usando uma arquitetura semelhante à descrita em Writing to Amazon Neptune from Amazon Kinesis Data Streams
. Observe que a replicação das alterações pode ser executada paralelamente para validar a arquitetura e o desempenho da nova aplicação. Depois que a migração de dados for validada, o tráfego da aplicação poderá ser redirecionado para o cluster do Neptune e a instância do Neo4j poderá ser desativada.
Otimizações de modelos de dados para migrar do Neo4j para o Neptune
Tanto o Neptune quanto o Neo4j são compatíveis com grafos de propriedades rotulados (LPG). No entanto, o Neptune tem algumas diferenças de arquitetura e modelo de dados que você pode aproveitar para otimizar o desempenho:
Otimizando o nó e a borda IDs
O Neo4j gera automaticamente números longos. IDs Usando o Cypher, é possível se referir aos nós por ID, mas isso geralmente é desencorajado priorizando-se a pesquisa de nós por uma propriedade indexada.
O Neptune permite que você forneça sua própria base de cordas para IDs vértices e arestas. Se você não fornecer a sua própria IDs, o Neptune gera automaticamente representações de UUIDs cordas para novas arestas e vértices.
Se você migrar dados do Neo4j para o Netuno exportando do Neo4j e depois importando em massa para o Netuno, poderá preservar os do Neo4j. IDs Os valores numéricos gerados pelo Neo4j podem atuar como fornecidos pelo usuário ao IDs importar para o Neptune, onde são representados como strings em vez de valores numéricos.
No entanto, há circunstâncias em que convém promover uma propriedade de vértice para se tornar um ID de vértice. Assim como pesquisar um nó usando uma propriedade indexada é a maneira mais rápida de encontrar um nó no Neo4j, pesquisar um vértice por ID é a maneira mais rápida de encontrar um vértice no Neptune. Portanto, se você puder identificar uma propriedade de vértice adequada que contenha valores exclusivos, pense em substituir o ~id do vértice pelo valor da propriedade indicada nos arquivos CSV de carregamento em massa. Se você fizer isso, também precisará reescrever todos os valores correspondentes de borda ~from e ~to nos arquivos CSV.
Restrições do esquema ao migrar dados do Neo4j para o Neptune
No Neptune, a única restrição do esquema disponível é a exclusividade do ID de um nó ou uma borda. As aplicações que precisam aproveitar uma restrição de exclusividade são incentivadas a analisar essa abordagem para obter uma restrição de exclusividade por meio da especificação do ID do nó ou da borda. Se a aplicação usou várias colunas como restrição de exclusividade, o ID pode ser definido como uma combinação desses valores. Por exemplo, id=123, code='SEA' pode ser representado como ID='123_SEA' para obter uma restrição de exclusividade complexa.
Otimização da direção da borda ao migrar dados do Neo4j para o Neptune
Quando nós, bordas ou propriedades são adicionados ao Neptune, eles são automaticamente indexados de três maneiras diferentes, com um quarto índice opcional. Devido à forma como o Neptune cria e usa os índices, as consultas que seguem as bordas de saída são mais eficientes do que as que usam bordas de entrada. Em termos do modelo de armazenamento de dados de grafos do Neptune, essas são pesquisas baseadas em assuntos que usam o índice SPOG.
Se, ao migrar o modelo de dados e consultas para o Neptune, você descobrir que as consultas mais importantes dependem de percorrer bordas de entrada onde há um alto grau de fanout, pense em alterar o modelo para que esses percursos sigam as bordas de saída, principalmente quando você não pode especificar quais rótulos de borda percorrer. Para fazer isso, inverta a direção das bordas relevantes e atualize os rótulos das bordas para refletir a semântica dessa mudança de direção. Por exemplo, você pode alterar:
person_A — parent_of — person_B to: person_B — child_of — person_A
Para fazer essa alteração em um arquivo CSV de borda de carregamento em massa, basta trocar os cabeçalhos das colunas ~from e ~to e atualizar os valores da coluna ~label.
Como alternativa à inversão da direção das bordas, você pode habilitar um quarto índice do Neptune, o índice OSGP, que torna o percurso das bordas de entrada ou as pesquisas baseadas em objetos muito mais eficiente. No entanto, habilitar esse quarto índice reduzirá as taxas de inserção e exigirá mais armazenamento.
Otimização da filtragem ao migrar dados do Neo4j para o Neptune
O Neptune é otimizado para funcionar melhor quando as propriedades são filtradas para a propriedade mais seletiva disponível. Quando vários filtros são usados, o conjunto de itens correspondentes é encontrado para cada um e, depois, a sobreposição de todos os conjuntos correspondentes é calculada. Quando possível, combinar várias propriedades em uma única propriedade minimiza o número de pesquisas de índice e diminui a latência de uma consulta.
Por exemplo, essa consulta usa duas pesquisas de índice e uma junção:
MATCH (n) WHERE n.first_name='John' AND n.last_name='Doe' RETURN n
Essa consulta recupera as mesmas informações usando uma única pesquisa de índice:
MATCH (n) WHERE n.name='John Doe' RETURN n
O Neptune é compatível com tipos de dados diferentes dos do Neo4j.
Mapeamentos de tipo de dados do Neo4j em tipos de dados compatíveis com o Neptune
-
Lógico:
BooleanAssocie no Neptune a
Boolou aBoolean. -
Numérico:
NumberAssocie no Neptune ao mais restrito dos seguintes tipos do openCypher no Neptune que pode aceitar todos os valores da propriedade numérica em questão:
Byte Short Integer Long Float Double -
Texto:
StringAssocie no Neptune a
String. -
Ponto no tempo:
Date Time LocalTime DateTime LocalDateTimeAssocie no Neptune a
Datecomo UTC, usando um dos seguintes formatos ISO-8601 aceitos pelo Neptune:yyyy-MM-dd yyyy-MM-ddTHH:mm yyyy-MM-ddTHH:mm:ss yyyy-MM-ddTHH:mm:ssZ -
Duração do tempo:
DurationAssocie no Neptune a um valor numérico para aritmética de datas, se necessário.
-
Espacial:
PointAssocie no Neptune a valores numéricos de componentes, cada um dos quais se torna uma propriedade separada, ou expresse como um valor de string a ser interpretado pela aplicação cliente. Observe que a integração de pesquisa de texto completo do Neptune OpenSearch permite indexar propriedades de geolocalização.
Migrar propriedades de vários valores do Neo4j ao Neptune
O Neo4j permite que listas homogêneas de tipos simples
O Neptune, no entanto, permite apenas cardinalidade definida ou única para propriedades de vértice e cardinalidade única para propriedades de borda em dados de grafos de propriedades. Como resultado, não há migração direta de propriedades da lista de nós do Neo4j que contenham valores duplicados para as propriedades dos vértices de Neptune nem das propriedades da lista de relacionamentos do Neo4j para as propriedades da borda do Neptune.
Algumas estratégias possíveis para migrar propriedades de nós de vários valores do Neo4j com valores duplicados para o Neptune são as seguintes:
Descarte os valores duplicados e converta a propriedade do nó do Neo4j de vários valores em uma propriedade de vértice do Neptune de cardinalidade definida. Observe que o conjunto do Neptune pode não refletir a ordem dos itens na propriedade de vários valores do Neo4j original.
Converta a propriedade de nó do Neo4j de vários valores em uma representação de string de uma lista formatada em JSON em uma propriedade de string de vértice do Neptune.
Extraia cada um dos valores de propriedade de vários valores em um vértice separado com uma propriedade de valor e conecte esses vértices ao vértice pai usando uma borda rotulada com o nome da propriedade.
Da mesma forma, estratégias possíveis para migrar propriedades de relacionamento de vários valores do Neo4j para o Neptune são as seguintes:
Converta a propriedade de relacionamento do Neo4j de vários valores em uma representação de string de uma lista formatada em JSON em uma propriedade de string de borda do Neptune.
Refatore o relacionamento do Neo4j em bordas do Neptune de entrada e de saída conectadas a um vértice intermediário. Extraia cada um dos valores de propriedade de vários valores em um vértice separado com uma propriedade de valor e conecte esses vértices a esse vértice intermediário usando uma borda rotulada com o nome da propriedade.
Observe que uma representação de string de uma lista formatada em JSON é opaca para a linguagem de consulta openCypher, embora o openCypher inclua um predicado CONTAINS que permite pesquisas simples dentro de valores de string.
Exportar dados do Neo4j ao migrar para o Neptune
Ao exportar dados do Neo4j, use os procedimentos APOC para exportar para CSV
Também é possível exportar dados diretamente para o Amazon S3 usando os vários procedimentos APOC. A exportação para um bucket do Amazon S3 está desabilitada por padrão, mas pode ser habilitada usando os procedimentos destacados em Exporting to Amazon S3
Importar dados do Neo4j ao migrar para o Neptune
É possível importar dados para o Neptune usando o carregador em massa do Neptune ou usando a lógica da aplicação em uma linguagem de consulta compatível, como openCypher.
O carregador em massa do Neptune é a abordagem preferencial para importar grandes quantidades de dados, pois oferece desempenho de importação otimizado caso você siga as práticas recomendadas. O carregador em massa é compatível com dois formatos CSV diferentes, para os quais os dados exportados do Neo4j podem ser convertidos usando os utilitários de código aberto mencionados acima na seção Exportar dados.
Você também pode usar o openCypher para importar dados com lógica personalizada para análise, transformação e importação. É possível enviar as consultas do openCypher por meio do endpoint HTTPS (o que é recomendado) ou usando o driver bolt.
