Etapas de pré-migração das migrações de dados do MongoDB para o Azure Cosmos DB for MongoDB

APLICA-SE AO: MongoDB

Importante

Leia este guia inteiro antes de realizar as etapas de pré-migração. Para migrações para o Azure Cosmos DB para MongoDB vCore, consulte Opções de migração do vCore

Esse guia de pré-migração do MongoDB faz parte de uma série sobre migração do MongoDB RU. As etapas críticas de migração do MongoDB são pré-migração, migração e pós-migração, conforme mostrado neste guia.

Visão geral da pré-migração

É essencial realizar determinados planejamentos e tomadas de decisão antecipados sobre sua migração antes de realmente mover os dados. Esse processo inicial de tomada de decisão é a "pré-migração".

Suas metas na pré-migração são:

1. Certificar-se de configurar o Azure Cosmos DB para atender aos requisitos do aplicativo e
2. Planeje como executar a migração.

Siga estas etapas para executar uma pré-migração completa

1. Descubra os recursos existentes do MongoDB e avalie a preparação dos recursos existentes do MongoDB para migração de dados
2. Mapeie os recursos existentes do MongoDB para novos recursos do Azure Cosmos DB
3. Planeje a logística do processo de migração de ponta a ponta antes de começar a migração de dados em escala completa

Em seguida, execute sua migração de acordo com seu plano de pré-migração.

Por fim, execute as etapas críticas de pós-migração de recorte e otimização.

Todas as etapas acima são essenciais para garantir uma migração bem-sucedida.

Ao planejar uma migração, recomendamos que, sempre que possível, você planeje no nível por recurso.

Avaliação de pré-migração

A primeira etapa de pré-migração é descobrir seus recursos existentes do MongoDB e avaliar a preparação de seus recursos para migração.

A descoberta envolve a criação de uma lista abrangente dos recursos existentes (bancos de dados ou coleções) no seu acervo de dados do MongoDB.

A avaliação envolve descobrir se você está usando os recursos e a sintaxe que têm suporte. Isso também inclui garantir que você esteja aderindo aos limites e cotas. O objetivo desse estágio é criar uma lista de incompatibilidades e avisos, se houver. Depois de obter os resultados da avaliação, você pode tentar abordar as conclusões durante o restante do planejamento de migração.

Há três maneiras de concluir a avaliação de pré-migração. Recomendamos que você use a extensão de migração do Azure Cosmos DB para MongoDB.

Extensão da Migração do Azure Cosmos DB para MongoDB

A extensão de Migração do Azure Cosmos DB para MongoDB no Azure Data Studio ajuda você a avaliar uma carga de trabalho do MongoDB a fim de migrá-la do Azure Cosmos DB para MongoDB. Você pode usar essa extensão para executar uma avaliação de ponta a ponta em sua carga de trabalho e descobrir as ações que talvez seja necessário executar para migrar perfeitamente suas cargas de trabalho no Azure Cosmos DB. Durante a avaliação de um ponto de extremidade do MongoDB, a extensão relata todos os recursos descobertos.

Observação

Também recomendamos que você analise em detalhes os recursos e a sintaxe com suporte e os limites e cotas do Azure Cosmos DB, além de realizar uma prova de conceito antes da migração real.

Descoberta manual (herdada)

Como alternativa, você pode criar uma planilha de migração de patrimônio de dados. A finalidade dessa planilha é aprimorar sua produtividade e ajudar você a planejar a migração de ponta a ponta e usá-la como um documento de acompanhamento durante todo o processo de migração.

• Essa planilha contém uma lista abrangente dos recursos existentes (bancos de dados ou coleções) no seu acervo de dados do MongoDB.
• Essa planilha deve ser estruturada como um registro de seus recursos de acervo de dados, em formato de lista.
• Cada linha corresponde a um recurso (banco de dados ou coleção).
• Cada coluna corresponde a uma propriedade do recurso; comece com pelo menos o nome e o tamanho dos dados (GB) como colunas.
• Conforme avançamos nesse guia, você transforma essa planilha em um documento de acompanhamento para o planejamento de migração de ponta a ponta, adicionando colunas conforme necessário.

Aqui estão algumas ferramentas que você pode usar para descobrir os recursos:

• MongoDB Shell
• MongoDB Compass

Percorra a planilha e verifique cada coleção em relação aos recursos e à sintaxe com suporte, além de limites e cotas do Azure Cosmos DB em detalhes.

Utilitário do Assistente de Migração de Banco de Dados (herdado)

Observação

O Assistente de Migração de Banco de Dados é um utilitário preliminar destinado a ajudá-lo com as etapas de pré-migração. Recomendamos que você use a extensão de migração do Azure Cosmos DB para MongoDB em todas as etapas de pré-migração.

Você pode usar o utilitário Assistente de Migração de Dados (DMA) para ajudar com as etapas de pré-migração.

Mapeamento de pré-migração

Com as etapas de descoberta e avaliação completas, você concluiu o lado da equação do MongoDB. Agora é hora de planejar o lado da equação do Azure Cosmos DB. Como você planeja instalar e configurar seus recursos de produção do Azure Cosmos DB? Faça seu planejamento em um nível por recurso – isso significa que você deve adicionar as seguintes colunas à sua planilha de planejamento:

• Mapeamento do Azure Cosmos DB
• Chave de fragmentação
• Modelo de dados
• Taxa de transferência dedicada x compartilhada

Serão fornecidos mais detalhes nas seções a seguir.

planejamento de capacidade

Tentando fazer um planejamento de capacidade para uma migração para o Microsoft Azure Cosmos DB?

• Se você sabe apenas o número de vCores e servidores do cluster de banco de dados existente, leia sobre como estimar unidades de solicitação com vCores ou vCPUs
• Se souber as taxas de solicitação típicas da carga de trabalho do banco de dados atual, leia sobre como estimar unidades de solicitação usando o planejador de capacidade do Azure Cosmos DB

Considerações sobre o uso da API do Azure Cosmos DB para o MongoDB

Antes de planejar seu acervo de dados do Azure Cosmos DB, entenda os seguintes conceitos do Azure Cosmos DB:

• Modelo de capacidade: A capacidade do banco de dados no Azure Cosmos DB baseia-se em um modelo baseado em taxa de transferência. Esse modelo baseia-se em Unidades de Solicitação por segundo, que é uma unidade que representa o número de operações de banco de dados que podem ser executadas em uma coleção por segundo. Essa capacidade pode ser alocada no nível de um banco de dados ou coleção e pode ser provisionada em um modelo de alocação ou usando a taxa de transferência provisionada de dimensionamento automático.
• Unidades de Solicitação: Cada operação de banco de dados tem um custo de RUs (unidades de solicitação) associado no Azure Cosmos DB. Quando executado, as unidades de solicitação são subtraídas do nível de unidades de solicitação disponíveis em um determinado segundo. Se uma solicitação exigir mais RUs do que as RU/s atualmente alocadas, há duas opções para resolver o problema: aumentar o número de RUs ou aguardar o início do próximo segundo e, em seguida, repetir a operação.
• Capacidade elástica: A capacidade de uma determinada coleção ou banco de dados pode ser alterada a qualquer momento. Essa flexibilidade permite que o banco de dados se adapte de forma elástica aos requisitos da taxa de transferência de sua carga de trabalho.
• Fragmentação automática: O Azure Cosmos DB fornece um sistema de particionamento automático que requer somente um fragmento (ou uma chave de partição). O mecanismo de particionamento automático é compartilhado entre todas as APIs do Azure Cosmos DB e permite dimensionamento de taxa de transferência e dados contínuos através da distribuição horizontal.

Planejar o acervo de dados do Azure Cosmos DB

Descubra quais recursos do Azure Cosmos DB você criará. Esse processo requer percorrer sua planilha de migração de propriedade de dados e mapear cada recurso existente do MongoDB para um novo recurso do Azure Cosmos DB.

• Antecipe que cada banco de dados do MongoDB se torne um banco de dados do Azure Cosmos DB.
• Antecipe que cada coleção do MongoDB se torne uma coleção do Azure Cosmos DB.
• Escolha uma convenção de nomenclatura entre seus recursos do Azure Cosmos DB. Manter os mesmos nomes de recursos geralmente é uma boa escolha, a menos que haja mudanças na estrutura de bancos de dados e coleções.
• Determine se você está usando coleções fragmentadas ou não fragmentadas no Azure Cosmos DB. O limite de coleção não fragmentada é de 20 GB. A fragmentação, por outro lado, ajuda a alcançar uma escala horizontal que é fundamental para o desempenho de muitas cargas de trabalho.
• Se estiver usando coleções estilhaçadas, não presuma que sua chave de fragmento de coleção do MongoDB se torne sua chave de partição de contêiner do Azure Cosmos DB. Não suponha que a estrutura de documento do modelo de dados do MongoDB existente deva ser o mesmo modelo que você emprega no Azure Cosmos DB.
  • A chave de fragmentação é a configuração mais importante para otimizar a escalabilidade e o desempenho do Azure Cosmos DB, e a modelagem de dados é a segunda mais importante. Ambas as configurações são imutáveis e não podem ser alteradas depois de definidas; portanto, é muito importante otimizá-los na fase de planejamento. Siga as orientações na seção Decisões imutáveis para obter mais informações.
• O Azure Cosmos DB não reconhece determinados tipos de coleção do MongoDB, como coleções limitadas. Para esses recursos, basta criar coleções normais do Azure Cosmos DB.
• O Azure Cosmos DB tem dois tipos de coleções próprias – compartilhadas e de taxa de transferência dedicada. Taxa de transferência compartilhada versus dedicada é outra decisão crítica e imutável, que é vital tomar na fase de planejamento. Siga as orientações na seção Decisões imutáveis para obter mais informações.

Decisões imutáveis

As opções de configuração do Azure Cosmos DB a seguir não podem ser modificadas ou desfeitas após a criação de um recurso do Azure Cosmos DB; portanto, é importante acertar essas opções de configuração durante o planejamento da pré-migração, antes de iniciar qualquer migração:

• Consulte o Particionamento e dimensionamento horizontal no Azure Cosmos DB para escolher a melhor chave de fragmento. O particionamento, também conhecido como fragmentação, é um ponto-chave de consideração antes da migração de dados. O Azure Cosmos DB usa particionamento totalmente gerenciado para aumentar a capacidade em um banco de dados para atender aos requisitos de armazenamento e a taxa de transferência. Esse recurso não precisa da hospedagem nem da configuração de servidores de roteamento.
  • De maneira semelhante, o recurso de particionamento adiciona capacidade automaticamente e reequilibra os dados de acordo. Para obter mais informações sobre como escolher a chave de partição certa para seus dados, confira escolhendo uma chave de partição.
• Siga o guia de Modelagem de dados no Azure Cosmos BD para escolher um modelo de dados.
• Siga o Custo de taxa de transferência provisionada do Optimize no Azure Cosmos DB para escolher entre a taxa de transferência dedicada e compartilhada para cada recurso que você migrar
• Como modelar e particionar dados no Azure Cosmos DB usando um exemplo real é um exemplo real de fragmentação e modelagem de dados para ajudá-lo no processo de tomada de decisões

Custo de propriedade

• Estime o custo de propriedade de seus novos recursos do Azure Cosmos DB usando a calculadora de capacidade do Azure Cosmos DB.

Estimativa da taxa de transferência

• No Azure Cosmos DB, a taxa de transferência é provisionada antecipadamente e medida em Unidades de Solicitação (RUs) por segundo. Diferentemente das VMs ou servidores locais, as RUs são fáceis de escalar e reduzir verticalmente a qualquer momento. É possível alterar o número de RUs provisionadas instantaneamente. Para obter mais informações, confira Unidades de solicitação no Azure Cosmos DB.

• Você pode usar a Calculadora de capacidade do Azure Cosmos DB para determinar o número de Unidades de Solicitação que deve usar. Esse número é baseado na configuração da conta do banco de dados, quantidade de dados, tamanho do documento e leituras e gravações necessárias por segundo.

• Veja a seguir os principais fatores que afetam o número de RUs necessárias:

  • Tamanho do documento: à medida que o tamanho de um item/documento aumenta, o número de RUs consumidas para ler ou gravar o item/documento também aumenta.

  • Contagem de propriedades do documento: o número de RUs consumidas para criar ou atualizar um documento está relacionado ao número, à complexidade e ao comprimento de suas propriedades. Você pode reduzir o consumo de unidade de solicitação para operações de gravação, limitando o número de propriedades indexadas.

  • Padrões de consulta: a complexidade de uma consulta afeta quantas unidades de solicitação a consulta consome.

• A melhor maneira de entender o custo das consultas é usar dados de amostra no Azure Cosmos DB e executar consultas de amostra do MongoDB Shell usando o comando getLastRequestStastistics para obter a cobrança da solicitação, que gera o número de RUs consumidos:

  db.runCommand({getLastRequestStatistics: 1})
  

  *Esse comando gera um documento JSON semelhante ao exemplo a seguir:

  {
    "_t": "GetRequestStatisticsResponse",
    "ok": 1,
    "CommandName": "find",
    "RequestCharge": 10.1,
    "RequestDurationInMilliSeconds": 7.2
  }
  

• Você também pode usar as configurações de diagnóstico para entender a frequência e os padrões das consultas executadas em relação ao Azure Cosmos DB. Os resultados dos logs de diagnóstico podem ser enviados para uma conta de armazenamento, uma instância de Hubs de Eventos ou da Análise de Log do Azure.

Planejamento de logística de pré-migração

Finalmente, agora que você tem uma visão de seu estado de dados existente e um design para seu novo estado de dados do Azure Cosmos DB, você está pronto para planejar como executar seu processo de migração de ponta a ponta. Mais uma vez, faça seu planejamento em um nível por recurso, adicionando colunas à sua planilha para capturar as dimensões logísticas incluídas nessa seção.

Logística de execução

• Atribua a responsabilidade de migrar cada recurso existente do MongoDB para o Azure Cosmos DB. A maneira como você aplica os recursos de sua equipe para conduzir sua migração até a conclusão fica a seu critério. Em pequenas migrações, você pode ter uma equipe iniciando toda a migração e monitorando o progresso. Em grandes migrações, você pode atribuir a responsabilidade aos membros da equipe por recurso para migrar e monitorar esse recurso.

• Depois de atribuir a responsabilidade para migrar os recursos, você deve escolher as ferramentas de migração corretas. Em pequenas migrações, você pode usar uma ferramenta de migração, como uma ferramenta nativa do MongoDB ou o DMS do Azure, para migrar todos os recursos de uma só vez. Em migrações grandes ou com requisitos especiais, talvez você queira escolher as ferramentas de migração em uma granularidade por recurso.

  • Antes de planejar quais ferramentas de migração usar, é recomendável se familiarizar com as opções disponíveis. O Serviço de Migração de Banco de Dados do Azure para a API do Azure Cosmos DB para o MongoDB fornece um mecanismo que simplifica a migração de dados por meio do fornecimento de uma plataforma de hospedagem totalmente gerenciada, opções de monitoramento de migração e manipulação de limitação automática. Aqui está uma lista completa de opções:

    Tipo de migração	Solução	Considerações
    Online	Serviço de Migração de Banco de Dados do Azure	• Usa a biblioteca do executor em massa para o Azure Cosmos DB • Adequado para grandes conjuntos de dados e cuida da replicação de alterações dinâmicas • Funciona somente com outras fontes do MongoDB
    Offline	Serviço de Migração de Banco de Dados do Azure	• Usa a biblioteca do executor em massa para o Azure Cosmos DB • Adequado para grandes conjuntos de dados e cuida da replicação de alterações dinâmicas • Funciona somente com outras fontes do MongoDB
    Offline	Fábrica de dados do Azure	• Usa a biblioteca do executor em massa para o Azure Cosmos DB • Adequada para grandes conjuntos de dados • Fácil de configurar e dá suporte a várias fontes • A falta de ponto de verificação significa que qualquer problema durante a migração exigiria a reinicialização de todo o processo de migração • A falta de uma fila de mensagens mortas significa que alguns arquivos errados poderiam parar todo o processo de migração • Precisa de código personalizado para aumentar a taxa de transferência de leitura para determinadas fontes de dados
    Offline	Ferramentas do Mongo existentes (mongodump, mongorestore, Studio3T)	• Fácil de configurar e de integrar • Precisa de manipulação personalizada para restrições
    Offline/online	Azure Databricks e Spark	• Controle total da taxa de migração e transformação de dados • É necessária codificação personalizada

  • Se seu recurso conseguir tolerar uma migração offline, use esse diagrama para escolher a ferramenta de migração apropriada:

    

  • Se seu recurso exigir uma migração online, use esse diagrama para escolher a ferramenta de migração apropriada:

    

  • Assista um vídeo da visão geral e demonstração das soluções de migração.

• Depois de escolher as ferramentas de migração para cada recurso, a próxima etapa é priorizar os recursos que você migrará. Uma boa priorização pode ajudar a manter sua migração dentro do programado. Uma boa prática é priorizar a migração desses recursos, que precisam de mais tempo para serem movidos; migrar esses recursos primeiro traz o maior progresso para a conclusão. Além disso, como essas migrações demoradas normalmente envolvem mais dados, elas consomem mais recursos da ferramenta de migração e, portanto, têm maior probabilidade de expor problemas com o pipeline de migração desde o início. Essa prática minimiza a chance de atrasos no cronograma devido a qualquer dificuldade com o pipeline de migração.

• Planeje como você monitora o progresso da migração depois de iniciada. Se você estiver coordenando seu esforço de migração de dados entre uma equipe, planeje também uma cadência regular de sincronizações da equipe, para ter uma visão abrangente de como estão indo as migrações de alta prioridade.

Cenários de migração com suporte

A melhor opção da ferramenta de migração do MongoDB depende do seu cenário de migração.

Tipos de migrações

Aqui está uma lista de ferramentas compatíveis para cada cenário de migração:

Fonte	Destino	Recomendação de processo
• Cluster local do MongoDB • Cluster de VM IaaS do MongoDB • Cluster do MongoDB Atlas - Offline	API do Mongo do Azure Cosmos DB	• <Dados de 10 GB: ferramentas nativas do MongoDB - < 1 TB de dados: DMS do Azure • > Dados de 1 TB: Spark
• Cluster local do MongoDB • Cluster de VM IaaS do MongoDB • Cluster do MongoDB Atlas - Online	API do Mongo do Azure Cosmos DB	- < 1 TB de dados: DMS do Azure • >Dados de 1 TB: Spark + Mongo Changestream
• É necessário alterar o esquema durante a migração Precisa de mais flexibilidade do que as ferramentas mencionadas acima	API do Mongo do Azure Cosmos DB	• O ADF é mais flexível que o DMS, dá suporte a modificações de esquema durante a migração e dá suporte a maioria das combinações de origem/destino • O DMS é melhor em termos de escala (por exemplo, migração mais rápida)
• arquivo JSON	API do Mongo do Azure Cosmos DB	• Ferramentas nativas do MongoDB especificamente mongoimport
• arquivo CSV	API do Mongo do Azure Cosmos DB	• Ferramentas nativas do MongoDB especificamente mongoimport
• arquivo BSON	API do Mongo do Azure Cosmos DB	• Ferramentas nativas do MongoDB especificamente mongorestore

Suporte de ferramentas para versões do MongoDB

Considerando os dados que você está migrando de uma versão específica do MongoDB, as ferramentas que tem suporte para cada versão estão incluídas aqui:

Versão de origem do MongoDB	Versão de destino do Azure Cosmos DB para MongoDB (baseado em RU)	Ferramentas com suporte	Ferramentas sem suporte
<3.2	3.2, 3.6, <8.0	Ferramentas nativas do MongoDB, Spark	DMS, ADF
3.2, 3.6, <8.0	3.2, 3.6, <8.0	Ferramentas nativas do MongoDB, DMS, ADF, Spark	Nenhum

Pós-migração

Na fase de pré-migração, gaste algum tempo para planejar quais etapas você deve seguir para a migração de aplicativos e otimização pós-migração.

• Na fase de pós-migração, você executa uma transferência de seu aplicativo para usar o Azure Cosmos DB em vez de seu estado de dados do MongoDB existente.
• Faça o seu melhor para planejar a indexação, distribuição global, consistência e outras propriedades mutáveis do Azure Cosmos DB por nível de recurso. No entanto, essas definições de configuração do Azure Cosmos DB podem ser modificadas posteriormente, portanto, espere fazer ajustes nessas configurações posteriormente. Você aplicará essas configurações mutáveis após a migração.
• Para obter um guia pós-migração, consulte Etapas de otimização pós-migração com a API do Azure Cosmos DB para MongoDB.

Próximas etapas

• Migrar para o Azure Cosmos DB for MongoDB
  • Migração offline usando ferramentas nativas do MongoDB
  • Migração offline usando o DMS (serviço de migração de banco de dados) do Azure
  • Migração online usando o DMS (serviço de migração de banco de dados) do Azure