A Year with MongoDB • Hacker News Board

Re: A Year with MongoDB

#151

Post by bitops » Wed, Apr 18, 2012, 2:07 AM UTC

gatesvp1 wrote: post #147

bitops wrote: post #24

Earlier quoted context omitted.

> I'll admit I'm a non-believer, but every time I see "Schemaless" in MongoDB, I think "oh, so you're implementing schema in your application?" I think that is arguably one of the selling points of MongoDB. Yes, you do implement schema in your application, but should be doing that knowingly and embracing both the costs and benefits. The benefit is that you can very quickly change your "schema" since it's just however…

> A more "Mongo" approach is to migrate data as you need to; e.g. you pull in an older document and at that time add any missing fields. I think this works when you're talking about adding fields. But it really breaks down if you need to make some change regarding "sub-objects" or arrays of "sub-objects". If you have made a modeling mistake and you need to pull out a sub-object you generally have to do simply stop th…

That's very true. Sometimes you can't do a live migration and you have to bite the bullet.

Re: A Year with MongoDB

#152

Post by bradgessler » Fri, Apr 20, 2012, 6:53 PM UTC

Jare wrote: post #82

bradgessler wrote: post #71

Earlier quoted context omitted.

That's still a migration, its just incremental.

Incremental can make all the difference between zero- and hours of downtime. Do not underestimate the importance of this extra agility in the modern world of almost daily updates to web apps and backends.

I don't see where I underestimated that?

Re: A Year with MongoDB

#153

Post by jeltz » Fri, Apr 20, 2012, 7:09 PM UTC

bitops wrote: post #151

gatesvp1 wrote: post #147

Earlier quoted context omitted.

> A more "Mongo" approach is to migrate data as you need to; e.g. you pull in an older document and at that time add any missing fields. I think this works when you're talking about adding fields. But it really breaks down if you need to make some change regarding "sub-objects" or arrays of "sub-objects". If you have made a modeling mistake and you need to pull out a sub-object you generally have to do simply stop th…

That's very true. Sometimes you can't do a live migration and you have to bite the bullet.

Which means it is not too much unlike a quality RDBMS like PostgreSQL. For adding (remember to not set a default value for large tables) and removing fields in PostgreSQL there is no requirement for locking the tables more than an instant. But for complicated schema changes you may have to either force a long lock or use some messy plan either involving replication or doing the migration in multiple steps.