Handling migrations with MongoDb

2019-02-06 04:06发布

Just to give a little more context to the question, I have a web application (asp mvc) which basically wraps CRUD operations to a MongoDb instance, it carries out validation and certain business logic before the model is verified and sent over to be stored, retrieved etc.

Now one problem we have his is that in the new version the models have changed but the existing data has not, here is an example: (it is c# specific but the question really is language agnostic)

public class Person
{
    public Guid Id {get; set;}
    public string Name {get; set;}
    public int Age {get;set;}
    public string BadgeNo {get;set;}
}

public class Person
{
    public Guid Id {get; set;}
    public string Name {get; set;}
    public int Age {get;set;}
    public string EmployeeNo {get; set;} // Still contains same data as BadgeNo just called something different
}

As you can see the structure of the objects have changed but in Mongo land it is still passing out a BadgeNo, not an EmployeeNo. In an SQL land we would usually have a migration script which is run as part of the build script which would change the schema and update/insert/delete any additional data for that delta.

So how is it best to manage these sort of migrations with Mongo? Should I also have a script which I use to update all instances within Mongo? or is there some other preferred practise for doing this sort of thing.

Any advice on the subject would be great

=== Edit ===

It seems like currently I am wanting to go with the migration option rather than a phasing out approach, so with this in mind can anyone recommend any tools for helping in this area, as otherwise each migration (assuming a roll-in, roll-out) would have to be a pre compiled assembly of some kind with all the logic in. I was thinking something along the lines of FluentMigrator but instead of working with SQL you are working with Mongo. Currently my build scripts are using Nant, I have seen some ruby tools but not sure if there are any .net equivalent.

3条回答
在下西门庆
2楼-- · 2019-02-06 04:36

There are basically two approaches:

  1. Make sure that your application code can handle both "versions" of the data structure, and when saving, updates to the new structure
  2. Write a migration script

I would probably go for option 1 as it's the method that allows you to gradually update, where as with option 2 you basically need to take down your application so that you can update the code (fast) and data (possibly slower) in one go.

Then later, or if you find it necessary do option 2 as well to migrate your data over. This then doesn't have to take down your site, and can happily run asynchronously in the background.

查看更多
3楼-- · 2019-02-06 04:43

It seems like currently I am wanting to go with the migration option rather than a phasing out approach, so with this in mind can anyone recommend any tools for helping in this area

For those who are still looking for the solution, take a look at MongoMigrations, this tool exposes MongoDatabase (from the mongo csharp driver) for manipulations over database so you can use all features from the driver.

查看更多
等我变得足够好
4楼-- · 2019-02-06 04:57

Strategies can be different. And they are depend on particular application. For sure for the sites like Facebook you will go with option #1 proposed by Derick to not hit your users at all, but if you have site that 'sells pizza' you for sure don't want make an effort to support both versions (current and new one), write more complex code, etc..

For such kind of apps simple patching may be better option:

  1. Build server send application to 'Read mode', so anyone can read, but can't insert anything into database.
  2. While prod in read mode i am taking database and apply patch.
  3. Once patching done it make backup of database, stop web server, deploy new database and new application.

Sending application to read mode allow to decrease downtime, but again for sites that's 'sells pizza' you don't need read mode.

查看更多
登录 后发表回答