Learn the "why" behind slow queries and how to fix them in our 2-Part Webinar.
Register now >
Menu Docs
Página inicial do Docs
/ /

Benchmarks de migração

Esta página explica os resultados do benchmark da migração de dados do Relational Migrator e fornece recomendações com base nesses resultados. Você pode usar os resultados e as recomendações para estimar cronogramas de migração, selecionar configurações de infraestrutura apropriadas e planejar os requisitos de recursos para sua migração relacional para o MongoDB .

Os benchmarks do Relational Migrator mediram o desempenho da migração com base nos seguintes fatores:

  • complexidade do mapeamento de esquema

  • Tamanho do banco de dados relacional

  • Tipo de armazenamento do banco de dados relacional

  • Configuração da instância do Relational Migrator

  • Configuração do MongoDB Atlas

Os benchmarks usaram a infraestrutura do MongoDB Atlas e da AWS . No entanto, os padrões de desempenho e recomendações se aplicam amplamente a outros provedores de nuvem e implantações no local. Para aprender mais sobre a infraestrutura usada nos benchmarks, consulte Configuração do benchmark.

O Relational Migrator permite transformar seu esquema relacional em um document model. Os termos a seguir descrevem diferentes complexidades de mapeamento de esquema MongoDB usadas pelos benchmarks:

Nível de complexidade
Descrição

Um a um

Um esquema MongoDB que corresponda ao seu esquema relacional: cada tabela mapeia para uma única coleção MongoDB e cada linha mapeia para um único documento. Uso mínimo de recursos avançados.

Mapeamentos incorporados

Um esquema MongoDB contendo algumas arrays incorporadas ou documentos incorporados. Máximo de dois níveis de documentos aninhados.

Avançado

Um esquema MongoDB que usa muitos recursos avançados que podem aumentar os tempos de migração. Alguns exemplos de funcionalidades avançadas incluem o seguinte:

  • Filtros de mapeamento

  • Filtros de tabelas

  • Arrays primitivas

  • Condições da array

O esquema avançado tem um máximo de três níveis de documentos aninhados.

Para saber mais sobre como mapear dados relacionais para esquemas MongoDB, consulte Modelagem de dados.

A tabela a seguir descreve a configuração de cada componente usado nos testes de benchmark:

Componente
Configuração

Banco de Dados de Origem (Oracle)

  • Plataforma: AWS RDS

  • vCPUs: 2

  • RAM: 8 GB

  • Região: AWS ap-southeast-2

  • Armazenamento: O tipo de armazenamento do AWS RDS varia de acordo com o tamanho do banco de dados e a complexidade do mapeamento. Para aprender mais sobre os tipos de armazenamento da AWS RDS, consulte a documentação dos tipos de armazenamento da AWS RDS.

A instância do Oracle foi isolada e recebeu tráfego exclusivamente da instância do Relational Migrator .

Relational Migrator

  • Plataforma: AWS ECS

  • vCPUs: 32

  • RAM: 64 GB

  • Região: AWS ap-southeast-2

  • Versão: Relational Migrator v1.15

  • Modo: Padrão (modo incorporado com multithreading ativado)

Banco de dados de destino (MongoDB Atlas)

  • Plataforma: MongoDB Atlas

  • Região: AWS ap-southeast-2

  • Configuração: A configuração do cluster do MongoDB Atlas varia com base no tamanho do banco de dados e na complexidade do mapeamento. Para saber mais sobre como modificar um cluster do MongoDB Atlas, consulte Modificar um cluster.

A tabela a seguir mostra os resultados dos testes de benchmark. Os benchmarks usaram a IU do Atlas ou o mongostat para monitorar as métricas do documento. A coluna Average Throughput (MB/s) é arredondada para duas casas decimais. A coluna Cluster Documents/s é arredondada para os dez mil documentos por segundo mais próximos. Para migrações de longa duração One-to-one, a coluna Cluster Documents/s fornece um limite inferior e superior observados devido a mudanças de velocidade durante o benchmark.

Observação

O banco de dados Oracle não exibiu uso significativo de CPU ou RAM durante o teste de benchmark.

Tamanho do Banco de Dados
complexidade do mapeamento
Tipo de armazenamento Oracle RDS
Camada do cluster do Atlas
Duração da migração
Taxa de transferência média (MB/s)
Documentos de cluster

10 GB

Um a um

gp2

M60

15 minutos

11.11

80,000 (insert)

10 GB

Mapeamentos incorporados

gp2

M60

37 minutos

4.50

80,000 (insert), 40,000 (update)

10 GB

Avançado

gp2

M60

47 minutos

3.55

90,000 (insert), 40,000 (update)

100 GB

Um a um

gp3

M60

2 horas, 31 minutos

11.04

80,000 a 100,000 (inserir)

100 GB

Mapeamentos incorporados

gp3

M80

16 horas, 25 minutos

1.69

90,000 (insert), 40,000 (update)

100 GB

Avançado

gp3

M140

15 horas, 47 minutos

1.76

90,000 (insert), 40,000 (update)

1 TB

Um a um

IOPS SSD

M60

30 horas, 50 minutos

9.01

85,000 a 100,000 (inserir)

O Relational Migrator sempre começa com uma série de operações doinsert para escrever os documentos raiz. Em seguida, ele usa a operação update para inserir documentos incorporados ou arrays incorporados. Como resultado, os resultados do benchmark One-to-one contêm somente operações de inserção, enquanto os resultados Embedded Mappings e Advanced contêm operações de inserção e atualização.

Com base nos resultados do parâmetro de comparação, o Relational Migrator pode migrar aproximadamente:

  • 21 GB/hora para esquemas um a um.

  • 7 GB/hora para esquemas com até dois níveis de mapeamentos incorporados.

A velocidade de migração do banco de dados para esquemas um para um é aproximadamente linear. Por exemplo, uma migração um-para-um de 100 GB leva aproximadamente 10 vezes mais tempo do que uma migração um-para-um de 10 GB.

A velocidade de migração para esquemas mais complexos não é dimensionada linearmente com o tamanho do banco de dados . Quanto mais documentos incorporados, arrays incorporados e outros recursos em seu esquema, mais lenta será a velocidade de migração.

A tabela a seguir fornece as camadas do cluster Atlas recomendadas e os tipos de armazenamento do AWS RDS com base no tamanho do banco de dados de origem e na complexidade do mapeamento.

Tamanho do conjunto de dados de origem
complexidade do mapeamento
Atlas camada do cluster recomendada
Tipo de armazenamento AWS RDS recomendado

0-50 GB

Um a um

M60

gp2

0-50 GB

Mapeamentos incorporados

M60

gp2

0-50 GB

Avançado

M60

gp2

50 GB-300 GB

Um a um

M60

gp3

50 GB-300 GB

Mapeamentos incorporados

M80

gp3

50 GB-300 GB

Avançado

M80

gp3

300 GB-1 TB

Um a um

M60

gp3

300 GB-1 TB

Mapeamentos incorporados

M140

IOPS SSD

300 GB-1 TB

Avançado

M140

IOPS SSD

1 TB+

Um a um

M60

IOPS SSD

1 TB+

Mapeamentos incorporados

M200

IOPS SSD

1 TB+

Avançado

M200

IOPS SSD

Embora a tabela especifique configurações do MongoDB Atlas e AWS RDS, você pode aplicar estas recomendações a outros provedores de nuvem e implantações autogerenciadas. Para saber mais sobre a configuração de infraestrutura associada a uma determinada camada do cluster do MongoDB Atlas, consulte Provedores de nuvem. Para saber mais sobre os tipos de armazenamento da AWS RDS, consulte a documentação dos tipos de armazenamento da AWS RDS.

Para minimizar a latência de rede, certifique-se de que o banco de dados de origem, o Relational Migrator e o cluster de destino estejam em execução no mesmo data center.

Para otimizar o desempenho da migração, monitore as métricas para identificar os gargalos de desempenho. Como melhor prática, siga o fluxo de dados ao identificar gargalos de desempenho: comece com o monitoramento do banco de dados de origem e, em seguida, passe para o Relational Migrator e, finalmente, o cluster de destino.

Se você observar IOPS de leitura baixo (< 50), o banco de dados de origem poderá ser o gargalo. Considere realizar as seguintes ações para melhorar o desempenho do banco de dados de origem:

  • AWS RDS: use Provisioned IOPS ou atualize o tipo de armazenamento.

  • No local: para melhorar o desempenho, você pode precisar de atualizações de armazenamento físico ou uma migração para uma solução de armazenamento de mais desempenho.

Se você observar que a CPU e a RAM na instância do Relational Migrator estão totalmente utilizadas, o Relational Migrator é o gargalo. Considere aumentar o tamanho da instância para melhorar o desempenho da migração.

Os resultados do teste a seguir mostram o impacto do aumento da contagem de vCPU e da RAM da instância do Relational Migrator no desempenho da migração:

Tamanho do Banco de Dados de Origem
complexidade do mapeamento
16 vCPU, 32 GB de duração de RAM
32 vCPU, 64 GB de duração de RAM
Melhoria

10 GB

Um a um

15 minutos

15 minutos

0%

10 GB

Mapeamentos incorporados

50 minutos

37 minutos

26%

10 GB

Avançado

63 minutos

47 minutos

25.40%

100 GB

Um a um

3 horas, 34 minutos

2 horas, 31 minutos

29.44%

100 GB

Mapeamentos incorporados

18 horas, 24 minutos

16 horas, 25 minutos

10.78%

100 GB

Avançado

16 horas, 35 minutos

15 horas, 47 minutos

4.82%

1 TB

Um a um

45 horas, 20 minutos

30 horas, 50 minutos

31.99%

Quando a instância do Relational Migrator era o gargalo, o aumento da contagem de vCPU e da RAM resultou em uma melhoria de desempenho de 25-30%.

Se você observar baixas taxas de inserção ou atualização de documento em comparação com a tabela de resultados do benchmark, o cluster MongoDB pode ser o gargalo. Considere realizar as seguintes ações para melhorar o desempenho da migração:

  • Aumentar o IOPS provisionado

  • Aumentar a vCPU ou a RAM

  • Aumentar o camada do cluster

Se você observar que as atualizações foram limitadas devido ao atraso de replicação, o aumento de IOPS provisionadas terá o maior impacto no desempenho da migração.

Voltar

Referência de risco

Nesta página