4 ms·
> Ugh, this sounds like a maintenance nightmare. How do you deal with adding extra field to the document? Do you ever feel the need of running on-the-fly migrat
by mitchellh 15y ago
> Ugh, this sounds like a maintenance nightmare. How do you deal with adding extra field to the document? Do you ever feel the need of running on-the-fly migration of old versions? (But when you do, shouldn't running a migration for all documents a better idea?)
Yes, we did on-the-fly migration as we loaded old data in.
Doing full data migration was not really an option because querying from MongoDB on un-indexed data is so slow, and paging in all that data would purge hot data, exacerbating the problem.
> 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?"
That's exactly what happens.
- judofyr 15y agoSo it's actually 100% the same as you would do with on-the-fly migrations in SQL: (1) Add column and add code moves the old data when you access it. Deploy. (2) Let it run for a while. Run a background job that migrates the rest (this might be done days or months later). (3) Remove the column and the custom code. The more I hear about "schemaless" the more I realize that it doesn't make any difference at all.
- scubaguy 15y agoFor a large table, adding a new column can be non-trivial, each record is updated when the new column is added.
- jeffdavis 15y agoIf you choose to update all of the old records. As other posts have already mentioned, adding a new column to a table in postgres does so instantly unless you set a default (telling postgres that you want it to update all the old records too). If you add the default separately from adding the column, you get the default but don't rewrite all the old rows (which remain NULL).
- raverbashing 15y agoAbsolutely not!! It's more like this You have old user table with for example: login and user name In MongoDB this is a JSON object {login:'user', name:'User Name'} You want to add 'shoe size'. So you add 1 - the shoe size to the signup/user editing form 2 - next user created is like this: {login:'user', name:'User Name', 'shoe_size': 7} 3 - Old users DON'T get a shoe_size added automatically to their document, but next time they login they get asked "What's your shoe size". It's dynamic. if (!user.shoe_size), done. You add new columns on demand, and you almost never remove them (you don't need to add fields for migrating, except of course those you want to add) You (almost never) "run the migration" for a while adding shoe_size to existing documents. And it absolutely does make a huge difference, since you don't have to deal with the mess of relational DB migrations. I'll never develop a system using a relational DB again if I can avoid.
- bradgessler 15y agoThat's still a migration, its just incremental.
- Jare 15y agoIncremental 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.
- bradgessler 14y agoI don't see where I underestimated that?
- pbiggar 15y agoIt's the same concept, but it's very different in practice. For example, adding a field with a default value in postgres will lock the table during the migration, which may be killer. If you use postgres for big data sets, what you'll end up implementing for your migrations looks a lot like what schemaless gives you for free.
- pbiggar 15y agoThat process sounds more like "implementing schemaless in SQL" than "implementing schema in NoSQL".