Статьи

Сценарии пошаговой миграции MongoDB

Март 2, 2019

Вступление

Процесс поэтапной разработки программного обеспечения требует стратегии поэтапной миграции баз данных.

Я помню, как работал над корпоративным приложением, где hibernate.hbm2ddl.auto был инструментом переноса данных по умолчанию.

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

Добавочные обновления для спасения

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

Мы использовали для разработки наших собственных реализаций миграции данных, и время, затрачиваемое на написание / поддержку сред, всегда работает против вашего текущего бюджета проекта.

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

В настоящее время вам не нужно внедрять инструменты переноса данных, Flyway работает лучше, чем все наши предыдущие пользовательские платформы. Все изменения схемы базы данных и данных должны быть записаны в сценарии инкрементного обновления в соответствии с четко определенным соглашением об именах .

План миграции СУБД учитывает изменения как схемы, так и данных. Всегда хорошо разделять схему и изменения данных. Интеграционные тесты могут использовать сценарии переноса схемы только в сочетании с данными, относящимися ко времени тестирования.

Flyway поддерживает все основные системы баз данных отношений, но для NoSQL (например, MongoDB) вам нужно искать в другом месте.

Mongeez

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

Интеграция Монгез

Сначала вы должны определить файл конфигурации mongeez:

mongeez.xml

1
2
3
4
<changeFiles>
    <file path="v1_1__initial_data.js"/>
    <file path="v1_2__update_products.js"/>
</changeFiles>

Затем вы добавляете фактические сценарии миграции:

v1_1__initial_data.js

01
02
03
04
05
06
07
08
09
10
11
12
13
14
15
16
17
18
//mongeez formatted javascript
//changeset system:v1_1
db.product.insert({
    "_id": 1,
    "name" : "TV",
    "price" : 199.99,
    "currency" : 'USD',
    "quantity" : 5,
    "version" : 1
});
db.product.insert({
    "_id": 2,
    "name" : "Radio",
    "price" : 29.99,
    "currency" : 'USD',
    "quantity" : 3,
    "version" : 1
});

v1_2__update_products.js

01
02
03
04
05
06
07
08
09
10
11
12
13
14
15
16
//mongeez formatted javascript
//changeset system:v1_2
db.product.update(
    {
        name : 'TV'
    },
    {
         $inc : {
             price : -10,
             version : 1
         }
    },
    {
        multi: true
    }
);

И вам нужно добавить MongeezRunner тоже:

1
2
3
4
5
6
<bean id="mongeez" class="org.mongeez.MongeezRunner" depends-on="mongo">
    <property name="mongo" ref="mongo"/>
    <property name="executeEnabled" value="true"/>
    <property name="dbName" value="${mongo.dbname}"/>
    <property name="file" value="classpath:mongodb/migration/mongeez.xml"/>
</bean>

Бегущий Монжез

При первом запуске приложения инкрементные сценарии анализируются и запускаются только при необходимости:

1
2
3
INFO  [main]: o.m.r.FilesetXMLReader - Num of changefiles 2
INFO  [main]: o.m.ChangeSetExecutor - ChangeSet v1_1 has been executed
INFO  [main]: o.m.ChangeSetExecutor - ChangeSet v1_2 has been executed

Mongeez использует отдельную коллекцию MongoDB для записи ранее запущенных скриптов:

01
02
03
04
05
06
07
08
09
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
db.mongeez.find().pretty();
{
        "_id" : ObjectId("543b69eeaac7e436b2ce142d"),
        "type" : "configuration",
        "supportResourcePath" : true
}
{
        "_id" : ObjectId("543b69efaac7e436b2ce142e"),
        "type" : "changeSetExecution",
        "file" : "v1_1__initial_data.js",
        "changeId" : "v1_1",
        "author" : "system",
        "resourcePath" : "mongodb/migration/v1_1__initial_data.js",
        "date" : "2014-10-13T08:58:07+03:00"
}
{
        "_id" : ObjectId("543b69efaac7e436b2ce142f"),
        "type" : "changeSetExecution",
        "file" : "v1_2__update_products.js",
        "changeId" : "v1_2",
        "author" : "system",
        "resourcePath" : "mongodb/migration/v1_2__update_products.js",
        "date" : "2014-10-13T08:58:07+03:00"
}

Вывод

Для автоматизации процесса развертывания необходимо создать самодостаточные пакеты, содержащие как байт-код, так и все связанные с ним конфигурации (файлы XML, пакеты ресурсов и сценарии переноса данных). Перед тем, как начать писать свою собственную платформу, вы всегда должны исследовать доступные альтернативы с открытым исходным кодом.

  • Код доступен на GitHub .
Ссылка: Сценарии пошаговой миграции MongoDB от нашего партнера по JCG Влада Михалча в блоге Влада Михалча .
80
Share: