Win a copy of The Little Book of Impediments (e-book only) this week in the Agile and Other Processes forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

How to model docs for use in MongoDB without going backwards

 
andrew ennamorato
Ranch Hand
Posts: 100
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
We have a couple web apps using MongoDB and in both cases we tried to sit and think about how we were modeling our data beforehand. Thanks to MongoDB's awesomeness, it's obviously pretty malleable, so we didn't spend too much time of that but figured "OK, this looks good" and dove in.

In both cases, we had to sort of "back out" our original design, tweak the documents (usually creating new collections), etc.

How could we have avoided this? It didn't bite us too bad but it could have I guess. Obviously, I think the book is meant for people like me, but I wanted to get in a question and see if there's any good suggestions on how to plan out your "schema" and test it, but without actually doing it...Or maybe the best suggestion is to go ahead and use a few tracer bullets/spikes to actually see what is like to work with the data in that fashion.

Thanks!
 
Rick Copeland
author
Greenhorn
Posts: 17
5
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Doing a spike to figure out the best schema is often the easiest way to get to a good schema, unfortunately. At this point in time, NoSQL schema design is in its infancy compared with RDBMSs. Some things that I would keep in mind when designing a schema:

  • When embedding an array inside a document, make sure the array doesn't grow without bound (so it won't overrun the 16MB document size limit)
  • Make sure that embedded arrays don't grow too frequently, as this can turn a fast update-in-place to a slow copy operation
  • Try to keep things that need to be updated atomically inside the same document, since making correctness guarantees across documents without real transactions is tedious and error-prone.
  • Ideally, have the 'unit of work' you're dealing with only touch a single document. In a web app, for example, this would mean that each page only loads a single document.


  • Of course, many of these rules of thumb can't be satisfied all the time, and thus comes the 'art' of schema design in MongoDB. The best advice I can give is to try different approaches, turn on slow query logging and the profiler, make sure you have the right indexes defined, and be ready to adapt when you find a better way to do it.

    Hope that helps!
     
    andrew ennamorato
    Ranch Hand
    Posts: 100
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    Try to keep things that need to be updated atomically inside the same document, since making correctness guarantees across documents without real transactions is tedious and error-prone.
    Ideally, have the 'unit of work' you're dealing with only touch a single document. In a web app, for example, this would mean that each page only loads a single document.


    Those sound like great tips. We started with the mindset of 'put everything about a model/object in the same document' but invariably we split it out. Which has been just okay.

    Anyway, thanks for the tips and Q&A this week, I look forward to reading the book.
     
    • Post Reply
    • Bookmark Topic Watch Topic
    • New Topic