Этапы предварительной миграции данных из MongoDB в Azure Cosmos DB для MongoDB

Область применения: MongoDB

Внимание

Прочтите это руководство целиком, прежде чем выполнять шаги по подготовке к миграции. Сведения о миграции в Azure Cosmos DB для виртуальных ядер MongoDB см. в параметрах миграции виртуальных ядер

Это руководство по предварительной миграции MongoDB является частью серии по миграции MongoDB RU. Критически важные этапы миграции MongoDB — это предварительная миграция, миграция и после миграции, как показано в этом руководстве.

Общие сведения о подготовке к миграции

Перед фактическим перемещением данных крайне важно провести определенное предварительное планирование и принять решения, касающиеся миграции. Начальный процесс принятия решений называется "подготовкой к миграции".

Цель вашей подготовки к миграции состоит в том, чтобы:

1. Убедиться, что вы настроили Azure Cosmos DB для выполнения требований вашего приложения, и
2. Планирование выполнения миграции.

Чтобы успешно подготовиться к миграции, выполните следующие шаги.

1. Обнаружение существующих ресурсов MongoDB и оценка готовности существующих ресурсов MongoDB для миграции данных
2. Сопоставьте существующие ресурсы MongoDB с новыми ресурсами Azure Cosmos DB.
3. Спланируйте процесс миграции полностью, прежде чем приступать к полномасштабной миграции данных.

Затем выполните миграцию в соответствии с планом подготовки к миграции.

Наконец, выполните критические важные действия по переносу и оптимизации, совершаемые после миграции.

Все описанные выше шаги являются критически важными для обеспечения успешной миграции.

При планировании миграции рекомендуется планировать ее для каждого ресурса.

Оценка подготовки к миграции

Первым шагом перед миграцией является обнаружение существующих ресурсов MongoDB и оценка готовности ресурсов к миграции.

Обнаружение включает создание комплексного списка существующих ресурсов (баз данных или коллекций) в хранилище данных MongoDB.

Оценка включает в себя определение того, используете ли вы поддерживаемые функции и синтаксис. Он также включает в себя обеспечение соблюдения вами ограничений и квот. Цель этого этапа — создать список несовместимостей и предупреждений, если таковые имеются. После получения результатов оценки можно попытаться устранить результаты во время остальной части планирования миграции.

Существует 3 способа завершения оценки предварительной миграции, мы рекомендуем использовать расширение Перенос данных из Azure Cosmos DB в Mongo DB.

расширение Перенос данных из Azure Cosmos DB в Mongo DB

Расширение Перенос данных из Azure Cosmos DB в Mongo DB в Azure Data Studio помогает оценить рабочую нагрузку MongoDB для миграции в Azure Cosmos DB для MongoDB. Это расширение можно использовать для выполнения комплексной оценки рабочей нагрузки и получения действий, которые могут потребоваться для простой миграции рабочих нагрузок в Azure Cosmos DB. Во время оценки конечной точки MongoDB расширение сообщает обо всех обнаруженных ресурсах.

Примечание.

Мы рекомендуем подробно ознакомиться с поддерживаемыми функциями и синтаксисом, ограничениями и квотами Azure Cosmos DB, а также выполнить проверку концепции до фактической миграции.

Обнаружение вручную (устаревшая версия)

Кроме того, можно создать электронную таблицу миграции данных. Цель этой электронной таблицы — повысить производительность и помочь вам спланировать миграцию из сквозной и использовать ее в качестве документа отслеживания во всем процессе миграции.

• Эта таблица содержит полный список существующих ресурсов (баз данных или коллекций) в пространстве данных MongoDB.
• Электронная таблица должна быть структурирована в виде списка с записями ресурсов пространства данных.
• Каждая строка соответствует ресурсу (базы данных или коллекции).
• Каждый столбец соответствует свойству ресурса; начните как минимум со столбцов имени и размера данных (ГБ).
• По мере выполнения этого руководства вы создадите эту электронную таблицу в документ отслеживания для комплексного планирования миграции, добавив столбцы по мере необходимости.

Вот некоторые средства, которые можно использовать для обнаружения ресурсов:

• оболочка MongoDB,
• MongoDB Compass.

Просмотрите электронную таблицу и проверьте каждую коллекцию в отношении поддерживаемых функций и синтаксиса, а также ограничения и квоты Azure Cosmos DB.

Служебная программа Помощник по миграции базы данных (устаревшая версия)

Примечание.

База данных Помощник по миграции — это устаревшая программа, предназначенная для выполнения предварительных действий по миграции. Мы рекомендуем использовать расширение Перенос данных из Azure Cosmos DB в Mongo DB для всех этапов предварительной миграции.

Вы можете использовать служебную программу Помощник по миграции базы данных (DMA) для выполнения предварительных действий по миграции.

Сопоставление при подготовке к миграции

После выполнения действий по обнаружению и оценке вы завершите работу с стороной MongoDB уравнения. Теперь пришло время спланировать сторону уравнения Azure Cosmos DB. Как вы планируете настроить и настроить рабочие ресурсы Azure Cosmos DB? Выполните планирование на уровне каждого ресурса. Это означает, что в таблицу планирования следует добавить следующие столбцы.

• Сопоставление Azure Cosmos DB
• Ключ сегмента
• Модель данных
• Общая и выделенная пропускная способность

Подробные сведения см. в следующих разделах.

Планирование ресурсов

Если вы планируете ресурсы для миграции в Azure Cosmos DB,

• Если вам известно только количество виртуальных ядер и серверов в существующем кластере баз данных, см. сведения об оценке единиц запросов на основе виртуальных ядер и серверов.
• Если вам известна стандартная частота запросов для текущей рабочей нагрузки базы данных, ознакомьтесь со статьей о расчете единиц запросов с помощью планировщика ресурсов Azure Cosmos DB

Рекомендации по использованию API Azure Cosmos DB для MongoDB

Перед планированием пространства данных Azure Cosmos DB убедитесь, что понимаете следующие концепции, имеющие отношение к Azure Cosmos DB.

• Модель емкости. Емкость базы данных в Azure Cosmos DB определяется посредством модели на основе пропускной способности. Эта модель основана на единицах запросов в секунду. Это единица измерения, представляющая количество операций с базами данных, которые могут выполняться с коллекцией в секунду. Эту емкость можно выделить на уровне базы данных или коллекции, и ее можно подготовить в модели выделения или с помощью автомасштабирования подготовленной пропускной способности.
• Единицы запросов. С каждой операцией базы данных связано определенное число единиц запроса (ЕЗ) в Azure Cosmos DB. При выполнении единицы запроса вычитаются из уровня доступных единиц запросов в заданной секунде. Если запросу требуется больше единиц ЕЗ, чем выделенные в данный момент ЕЗ/с, существует два варианта решения проблемы— увеличьте количество единиц запросов или подождите до следующего второго запуска, а затем повторите операцию.
• Эластичная емкость. Емкость заданной коллекции или базы данных может измениться в любое время. Эта гибкость позволяет базе данных эластично адаптироваться к требованиям к пропускной способности рабочей нагрузки.
• Автоматическое сегментирование. Azure Cosmos DB предоставляет систему автоматического сегментирования, для которой требуется только сегмент (или ключ секции). Механизм автоматического секционирования действует во всех API Azure Cosmos DB. Это позволяет эффективно масштабировать данные и пропускную способность с помощью горизонтального распределения.

Планирование пространства данных Azure Cosmos DB

Узнайте, какие ресурсы Azure Cosmos DB вы создаете. Этот процесс требует пошагового перехода по электронной таблице миграции данных и сопоставления каждого существующего ресурса MongoDB с новым ресурсом Azure Cosmos DB.

• Ожидается, что каждая база данных MongoDB становится базой данных Azure Cosmos DB.
• Предвидеть, что каждая коллекция MongoDB становится коллекцией Azure Cosmos DB.
• Выберите соглашение об именовании для ресурсов Azure Cosmos DB. Сохранение одинаковых имен ресурсов обычно является прекрасным выбором, если в структуре баз данных и коллекций нет никаких изменений.
• Определите, используете ли вы сегментированные или несхардированные коллекции в Azure Cosmos DB. Ограничение на несегментированную коллекцию составляет 20 ГБ. Сегментирование, с другой стороны, помогает достичь горизонтального масштабирования, которое имеет решающее значение для производительности многих рабочих нагрузок.
• При использовании сегментированных коллекций не предполагается, что ключ сегмента коллекции MongoDB становится ключом секции контейнера Azure Cosmos DB. Не предполагайте, что существующая структура документа модели данных MongoDB должна быть той же моделью, которую вы используете в Azure Cosmos DB.
  • Ключ сегмента — это наиболее важный параметр для оптимизации масштабируемости и производительности Azure Cosmos DB, а моделирование данных является вторым по степени важности параметром. Оба этих параметра неизменяемы и не могут быть изменены после их установки; Поэтому очень важно оптимизировать их на этапе планирования. Для получения дополнительных сведений выполните инструкции в разделе Неизменяемые решения.
• Azure Cosmos DB не распознает определенные типы коллекций MongoDB, такие как ограничения коллекций. Для этих ресурсов просто создайте обычные коллекции Azure Cosmos DB.
• Azure Cosmos DB имеет два собственных типа коллекций: общая и выделенная пропускная способность. Общая и выделенная пропускная способность — это еще одно критическое, неизменяемое решение, которое жизненно важно сделать на этапе планирования. Для получения дополнительных сведений выполните инструкции в разделе Неизменяемые решения.

Неизменяемые решения

Следующие варианты конфигурации Azure Cosmos DB нельзя изменить или отменить после создания ресурса Azure Cosmos DB; Поэтому важно правильно выбрать эти варианты конфигурации во время планирования перед миграцией, прежде чем начать любые миграции:

• Чтобы выбрать оптимальный ключ сегмента, см. статью "Секционирование и горизонтальное масштабирование в Azure Cosmos DB". Секционирование, также называемое сегментированием, является ключевой точкой, которую необходимо рассмотреть перед переносом данных. Azure Cosmos DB использует полностью управляемое секционирование для увеличения емкости базы данных в соответствии с требованиями к хранилищу и пропускной способности. Для этого компонента не требуется размещение или настройка серверов маршрутизации.
  • Аналогичным образом возможность секционирования автоматически добавляет емкость и перебалансирует данные соответствующим образом. Дополнительные сведения о выборе правильного ключа секции для данных см. в разделе о выборе ключа секции.
• Следуйте руководству по моделированию данных в Azure Cosmos DB, чтобы выбрать модель данных.
• Следуйте инструкциям по оптимизации подготовленной пропускной способности в Azure Cosmos DB , чтобы выбрать между выделенной и общей пропускной способностью для каждого ресурса, который вы переносите.
• Моделирование и секционирование данных в Azure Cosmos DB с помощью реального примера — это реальный пример сегментирования и моделирования данных, которые помогут вам в принятии решений

Стоимость владения

• Оцените стоимость владения новыми ресурсами Azure Cosmos DB с помощью калькулятора емкости Azure Cosmos DB.

Оценка пропускной способности

• В Azure Cosmos DB пропускная способность предусматривается заранее и измеряется в единицах запроса в секунду (ЕЗ/с). В отличие от виртуальных машин или локальных серверов, значение ЕЗ можно легко масштабировать в любой момент. Можно мгновенно изменить число подготовленных ЕЗ. Дополнительные сведения см. в статье Единицы запроса в базе данных Azure Cosmos DB.

• Вы можете использовать калькулятор емкости Azure Cosmos DB для определения количества единиц запросов, которые следует использовать. Это число основано на конфигурации учетной записи базы данных, объема данных, размера документа и необходимых операций чтения и записи в секунду.

• Ниже приведены ключевые факторы, влияющие на количество ЕЗ.

  • Размер документа: по мере увеличения размера элемента или документа количество единиц запросов, потребляемых для чтения или записи элемента или документа, также увеличивается.

  • Число свойств документа. Количество ЕЗ, используемых для создания или обновления документа, связано с числом, сложностью и длиной его свойств. Вы можете сократить потребление единиц запроса для операций записи, ограничив количество индексируемых свойств.

  • Шаблоны запросов: сложность запроса влияет на количество единиц запросов, потребляемых запросом.

• Лучший способ понять стоимость запросов — использовать примеры данных в Azure Cosmos DB и выполнить примеры запросов из оболочки MongoDB с помощью getLastRequestStastistics команды, чтобы получить плату за запрос, которая выводит количество использованных единиц запросов:

  db.runCommand({getLastRequestStatistics: 1})
  

  *Эта команда выводит документ JSON, аналогичный следующему примеру:

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

• Можно также использовать параметры диагностики, чтобы понять частоту и закономерности запросов, выполняемых в Azure Cosmos DB. Результаты из журналов диагностики можно отправлять в учетную запись хранения, экземпляр Центров событий или Azure Log Analytics.

Планирование логистики при подготовке к миграции

Наконец, теперь, когда у вас есть представление о существующем объекте данных и проектировании для нового объекта данных Azure Cosmos DB, вы готовы спланировать выполнение процесса миграции. Еще раз сделайте планирование на уровне ресурсов , добавив столбцы в электронную таблицу, чтобы записать измерения логистики, включенные в этот раздел.

Логистика выполнения

• Возложите ответственность за перенос каждого существующего ресурса из MongoDB в Azure Cosmos DB. Как вы применяете ресурсы команды для того, чтобы пастуха миграции к завершению вам. Если масштаб миграций невелик, можно поручить комплексное проведение миграции и отслеживание хода ее выполнения одной команде. В случае более крупномасштабных миграций можно возложить на членов группы ответственность за миграцию и мониторинг каждого ресурса по отдельности.

• После того, как вы возложили ответственность за миграцию ресурсов, для миграции следует выбрать нужное средство или средства миграции. При миграции небольших объемов данных для переноса всех ресурсов в пределах одного снимка можно использовать одно средство миграции. Например, собственное средство MongoDB или Azure DMS. В случае более крупномасштабных миграций или миграций с особыми требованиями может потребоваться выбирать средства миграции со степенью детализации на уровне ресурса.

  • Прежде чем планировать, какие средства миграции использовать, мы рекомендуем ознакомиться с имеющимися возможностями. Служба Azure Database Migration Service для API Azure Cosmos DB для MongoDB предоставляет механизм, который упрощает перенос данных за счет полностью управляемой платформы размещения, параметров мониторинга миграции и автоматического регулирования. Ниже приведен полный список параметров:

    Тип переноса	Решение	Рекомендации
    Миграция по сети	Миграция баз данных Azure	• Использует библиотеку массового исполнителя для Azure Cosmos DB • Подходит для больших наборов данных и заботится о репликации динамических изменений • Работает только с другими источниками MongoDB.
    Offline	Миграция баз данных Azure	• Использует библиотеку массового исполнителя для Azure Cosmos DB • Подходит для больших наборов данных и заботится о репликации динамических изменений • Работает только с другими источниками MongoDB.
    Offline	Фабрика данных Azure	• Использует библиотеку массового исполнителя для Azure Cosmos DB • Подходит для больших наборов данных • Легко настроить и поддерживать несколько источников • Отсутствие контрольных точек означает, что любая проблема во время миграции потребует перезапуска всего процесса миграции • Отсутствие очереди недоставленных писем означает, что несколько ошибочных файлов могут остановить весь процесс миграции. • Требуется пользовательский код для увеличения пропускной способности чтения для определенных источников данных.
    Offline	Существующие инструменты Mongo (mongodump, mongorestore, Studio3T)	• Легко настроить и интегрировать • Требуется настраиваемая обработка для регуляторов рабочей нагрузки.
    Вне сети или в сети	Azure Databricks и Spark	• Полный контроль скорости миграции и преобразования данных • Требуется специальный код

  • Если ресурс может терпеть автономную миграцию, используйте эту схему, чтобы выбрать соответствующее средство миграции:

    

  • Если ресурсу требуется миграция по сети, используйте эту схему, чтобы выбрать соответствующий инструмент миграции:

    

  • Просмотрите обзор и демонстрацию видео о решениях миграции.

• После выбора средств миграции для каждого ресурса необходимо определить приоритеты ресурсов, которые будут перенесены. Хорошая расстановка приоритетов способна помочь в проведении миграции по расписанию. Рекомендуется определить приоритет миграции этих ресурсов, которые требуют больше всего времени для перемещения; Миграция этих ресурсов сначала приносит наибольший прогресс к завершению. Кроме того, поскольку эти временные миграции обычно включают больше данных, они являются более ресурсоемкими для средства миграции и, следовательно, скорее всего, подвержены любым проблемам с конвейером миграции на ранних этапах. Эта практика сводит к минимуму вероятность скольжения расписания из-за каких-либо трудностей с конвейером миграции.

• Планирование отслеживания хода миграции после его начала. Если вы координируете усилия по миграции данных между командой, запланируйте регулярное время синхронизации команд, чтобы получить полное представление о том, как происходит миграция с высоким приоритетом.

Поддерживаемые сценарии миграции

Наилучший выбор средства миграции MongoDB зависит от сценария миграции.

Типы миграций

Ниже приведен список совместимых средств для каждого сценария миграции:

Источник	Назначение	Рекомендации по процессу
• Локальный кластер MongoDB • MongoDB в кластере виртуальных машин IaaS • Кластер MongoDB Atlas — автономный	API MongoDB Azure Cosmos DB	• <Данные размером 10 ГБ: собственные средства MongoDB • <1 ТБ данных: Azure DMS • > Данные размером 1 ТБ: Spark
• Локальный кластер MongoDB • MongoDB в кластере виртуальных машин IaaS • Кластер MongoDB Atlas — online	API MongoDB Azure Cosmos DB	• <1 ТБ данных: Azure DMS • >1 ТБ данных: Spark + Mongo Changestream
• Необходимо изменить схему во время миграции Требуется больше гибкости, чем упомянутые выше инструменты	API MongoDB Azure Cosmos DB	• ADF является более гибким, чем DMS, он поддерживает изменения схемы во время миграции и поддерживает самые исходные и конечные сочетания. • DMS лучше с точки зрения масштабирования (например, более быстрая миграция)
• JSON-файл	API MongoDB Azure Cosmos DB	• Собственные средства MongoDB специально mongoimport
• CSV-файл	API MongoDB Azure Cosmos DB	• Собственные средства MongoDB специально mongoimport
• BSON-файл	API MongoDB Azure Cosmos DB	• Собственные средства MongoDB специально mongorestore

Поддержка средств для версий MongoDB

Учитывая, что вы выполняете миграцию из определенной версии MongoDB, поддерживаемые средства для каждой версии включаются здесь:

Исходная версия MongoDB	Целевая версия Azure Cosmos DB для MongoDB (на основе ЕЗ)	Поддерживаемые инструменты	Неподдерживаемые инструменты
<3.2	3.2, 3.6, <8.0	Собственные инструменты MongoDB, Spark	DMS, ADF
3.2, 3.6, <8.0	3.2, 3.6, <8.0	Собственные инструменты MongoDB, DMS, ADF, Spark	нет

После миграции

На этапе предварительной миграции провести некоторое время, чтобы спланировать действия по миграции приложений и оптимизации после миграции.

• На этапе после миграции вы выполняете переключение приложения на использование Azure Cosmos DB вместо существующего объекта данных MongoDB.
• Сделайте все возможное, чтобы спланировать индексирование, глобальное распределение, согласованность и другие изменяемые свойства Azure Cosmos DB на уровне ресурсов. Однако эти параметры конфигурации Azure Cosmos DB могут быть изменены позже, поэтому ожидается внести изменения в эти параметры позже. Эти изменяемые конфигурации применяются после миграции.
• Инструкции по действиям после миграции см. в статье "Действия по оптимизации после миграции при использовании API Azure Cosmos DB для MongoDB".

Следующие шаги

• Миграция в Azure Cosmos DB для MongoDB
  • Автономная миграция с использованием собственных средств MongoDB
  • Автономная миграция с использованием службы миграции баз данных Azure (DMS)
  • Оперативная миграция с использованием службы миграции баз данных Azure (DMS)