Migração fácil: do banco de dados relacional para o MongoDB com o MongoDB Relational Migrator
Avalie esse Tutorial
Definir o processo de migração de dados de um banco de dados relacional para o MongoDB sempre foi uma tarefa complexa. Alguns optaram por uma abordagem personalizada, adotando soluções personalizadas, como scripts, enquanto outros preferiram usar ferramentas de terceiros.
É nesse contexto que o Relational Migrator entra em ação, resolvendo a complexidade dessa transição de um relational database para o MongoDB com a mesma naturalidade com que o sol funde a nuvem.
No contexto de um banco de dados relacional para o projeto de migração do MongoDB, surgem várias questões — por exemplo:
- Qual ferramenta você deve usar para melhor realizar essa migração?
- Como esse processo de migração pode ser otimizado em termos de tempo para um banco de dados de tamanho médio/grande?
- Como os dados precisarão ser modelados no MongoDB?
- Quanto tempo/recursos serão necessários para reestruturar as queries SQL para o MQL?
Considere a seguinte arquitetura, como exemplo:
Apresentamos uma primeira abordagem, que não fará uso do Relational Migrator, mas usará uma ferramenta de terceiros para orquestrar a migração dentro dessa arquitetura: Logstash.
Faremos observações e definimos quais podem ser as limitações desta ferramenta.
O Logstash é um canal de processamento de dados gratuito e aberto do lado do servidor que ingere dados de várias fontes, os transforma e os envia para seu estoque " favorito. "
Essa ferramenta atinge o objetivo de forma eficaz, executando dinamicamente as seguintes operações:
- Ingestão de dados da fonte — PostgreSQL
- Transformação de dados — Logstash
- Distribuição dos dados transformados para o destino — MongoDB
Ótimo! Portanto, será possível migrar dados e se beneficiar da alta flexibilidade em sua transformação, e também assumimos prazos relativamente curtos porque fizemos alguns ajustes muito bons, mas diferentes pipelines precisarão ser definidos manualmente.
Vamos concretizar com um exemplo o que temos dito a nós mesmos até agora, considerando o seguinte esquema:
matrícula | Nome | sobrenome | data de nascimento | endereço | Telefone | |
---|---|---|---|---|---|---|
1 | Mario | Rossi | 1990-05-15 | Via Roma, 123 | mario.rossi@email.com | 123-456-7890 |
2 | Laura | Bianchi | 1992-08-22 | Via Garibaldi, 56 | laura.b@email.com | 987-654-3210 |
3 | Giuseppe | Verdi | 1991-03-10 | Via Dante, 78 | giuseppe.verdi@email | 555-123-4567 |
4 | Sofia | Conti | 1993-11-30 | Via Milano, 45 | sofia.conti@email.com | 333-555-9999 |
5 | Alessia | Moretti | 1992-06-18 | Via Firenze, 7 | alessia.more@email.com | 111-222-3333 |
6 | Luca | Ferrari | 1994-09-25 | Via Venezia, 21 | luca.f@email.com | 444-777-8888 |
7 | Marta | Romano | 1990-02-03 | Via Bologna, 34 | marta.rom@email.com | 999-888-7777 |
8 | Marco | Galli | 1993-07-12 | Via Genova, 56 | marco.galli@email.com | 666-333-1111 |
9 | Elena | Piazza | 1995-04-09 | Via Torino, 78 | elena.p@email.com | 222-999-4444 |
10 | Andrea | Mancini | 1991-12-28 | Via Padova, 12 | andrea.m@email.com | 777-111-5555 |
Tabela de inscrição:
ID de inscrição | matrícula de alunos | código do curso | inscriçãodate |
---|---|---|---|
11 | 1 | CS101 | 2023-01-15 |
12 | 2 | LI301 | 2023-02-02 |
13 | 3 | MA201 | 2023-03-10 |
14 | 1 | CH401 | 2023-04-05 |
15 | 4 | CS101 | 2023-04-15 |
16 | 5 | PH501 | 2023-05-20 |
17 | 6 | EC601 | 2023-06-08 |
18 | 7 | HI701 | 2023-07-12 |
19 | 8 | EN801 | 2023-08-05 |
20 | 9 | MU901 | 2023-09-01 |
Tabela de cursos:
Código do curso | nome do curso | Créditos. | departamento |
---|---|---|---|
CS101 | Informatica | 4 | Informatica |
MA201 | Matemática | 3 | Matemática |
LI301 | Idioma Italiano | 5 | cartas |
CH401 | Química | 4 | Química |
PH501 | Física | 4 | Física |
EC601 | Economia | 5 | Economia |
HI701 | Histórico | 3 | Histórico |
EN801 | English | 4 | Idiomas |
MU901 | Música | 2 | Música |
GE1001 | Geografia | 3 | Geografia |
Nosso objetivo, com base em uma análise feita anteriormente, é modelar todas essas tabelas em um único documento. Portanto, prosseguiremos definindo, para o Logstash, o pipeline que consistirá na definição de:
- Estágio de entrada: informará os parâmetros básicos para conexão com o PostgreSQL como o driver, a string de conexão, o usuário, a senha e o comando
- Estágio de filtro: definirá como os dados devem ser modelados
- Etapa de saída: relatará os parâmetros básicos para se conectar ao MongoDB como uma string de conexão, banco de dados e coleção
Isso nos permitirá gerar documentos de acordo com a especificação desejada:
1 input { 2 jdbc { 3 jdbc_driver_library => "/usr/share/logstash/logstash-core/lib/jars/postgresql-42.7.0.jar" 4 jdbc_driver_class => "org.postgresql.Driver" 5 jdbc_connection_string => "jdbc:postgresql://postgresql.test.com:5432/formigration?sslmode=disable" 6 jdbc_user => "migratoruser" 7 jdbc_password => "test" 8 statement => "SELECT * 9 FROM enrollment INNER JOIN student ON student.matriculation=enrollment.studentmatriculation 10 INNER JOIN course ON course.coursecode=enrollment.coursecode 11 ORDER BY student.matriculation" 12 } 13 } 14 15 filter { 16 aggregate { 17 task_id => "%{matriculation}" 18 code => " 19 map['matriculation'] = event.get('matriculation') 20 map['address'] = event.get('address') 21 map['birthdate'] = event.get('birthdate') 22 map['email'] = event.get('email') 23 map['name'] = event.get('name') 24 map['phone'] = event.get('phone') 25 map['surname'] = event.get('surname') 26 map['enrollments'] ||= [] 27 map['enrollments'] << {'enrollmentid' => event.get('enrollmentid'), 'studentmatriculation' => event.get('studentmatriculation'), 'coursecode' => event.get('coursecode'), 'enrollmentdate' => event.get('enrollmentdate'), 'course' => {'coursecode' => event.get('coursecode'), 'coursename' => event.get('coursename'), 'credits'=> event.get('credits'), 'department' => event.get('department')} } 28 event.cancel() 29 " 30 push_previous_map_as_event => true 31 } 32 } 33 34 output { 35 mongodb { 36 uri => "mongodb://mongodbstandalone.test.com:27017/test" 37 database => "test" 38 collection => "test_migration" 39 isodate => true 40 } 41 }
E o resultado será o seguinte:
Isso resulta nos dados modelados como documentos, mas também é necessário chamar atenção para alguns pontos:
- Quanto tempo/recursos serão necessários para reestruturar queries SQL em MQL?
- Quanto esforço foi necessário para modelar a parte do filtro?
- Nenhum dado pode ser gravado na origem durante a migração, caso contrário, a consistência dos dados será perdida.
- Também será útil definir uma solução personalizada para validação de dados.
Além disso, deve-se observar que o Logstash não permite a migração direta de dados para o cluster MongoDB de destino. É necessário passar por uma máquina intermediária e, em seguida, executar um despejo/restauração do MongoDB autônomo para o cluster MongoDB Atlas de destino, o que introduzirá esforço adicional na migração.
Referindo-se à última parte deste processo de migração, é apropriado perguntar:
Os clientes estariam dispostos a investir recursos econômicos adicionais em um servidor bridge? (Talvez possa haver restrições orçamentárias).
Tendo feito várias considerações sobre essa arquitetura, podemos passar a discutir a próxima arquitetura.
Vamos considerar esta outra arquitetura:
Para orquestrar a migração dentro dessa arquitetura, optamos por adotar o Relational Migrator, o produto oficial do MongoDB. Mas o que é o Relational Migrator?
O Relational Migrator do MongoDB é uma ferramenta para ajudá-lo a migrar volumes de trabalho relacionais para o MongoDB. O Relational Migrator permite que você:
- Crie um esquema MongoDB efetivo, derivado de um esquema relacional existente.
- Migre dados do Oracle, SQL Server, MySQL e PostgreSQL para o MongoDB enquanto transforma ao esquema de destino.
- Gere artefatos de código para reduzir o tempo necessário para atualizar o código do aplicativo.
Utilizando como referência o esquema e tabelas definidos anteriormente, uma vez que a conexão com o banco de dados relacional for feita, poderemos ver, como na imagem a seguir, a representação visual do esquema relacional na parte superior e, abaixo disso, a coleção modelado pelo Relational Migrator:
Depois que o modelo de dados for definido, será possível e muito fácil definir um novo trabalho de sincronização. Precisamos configurar a opção de origem, destino e migração. Também será possível definir uma verificação de validação de dados e eliminar as collection que possam ser o resíduo de algumas etapas realizadas anteriormente.
Depois que tudo estiver configurado, basta iniciar o trabalho de sincronização, obtendo o seguinte resultado:
Por último, mas não menos importante, temos a possibilidade de usar o gerador de aplicativos de código e o conversor de consulta em visualização privada!
Armados com o que discutimos até agora sobre os recursos dos dois produtos, aqui está o que podemos dizer:
- Relational Migrator
- Sua facilidade de configuração oferece uma vantagem significativa para os usuários, economizando tempo e esforço na implementação.
- Sua interface intuitiva e recursos avançados tornam a experiência geral mais eficiente e eficaz.
- Representa uma solução ideal para quem busca uma experiência fácil de usar.
- O usuário pode entrar em contato com o suporte para resolver problemas relacionados ao produto.
- Logstash
- Permite grande flexibilidade na modelagem de documentos.
- É possível definir vários pipelines e executar mais de um pipeline no mesmo processo.
Independentemente da solução que será usada para migrar, você poderá entrar em contato com o suporte do MongoDB para fazer uma migração bem-sucedida para sua infraestrutura.
Se você tiver dúvidas ou comentários, pode nos encontrar na Comunidade de Desenvolvedores do MongoDB!