wood burning stoves 2.0*
The moose likes MongoDB and the fly likes How to model docs for use in MongoDB without going backwards Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of Murach's Java Servlets and JSP this week in the Servlets forum!
JavaRanch » Java Forums » Databases » MongoDB
Bookmark "How to model docs for use in MongoDB without going backwards" Watch "How to model docs for use in MongoDB without going backwards" New topic
Author

How to model docs for use in MongoDB without going backwards

andrew ennamorato
Ranch Hand

Joined: Oct 03, 2007
Posts: 100
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

Joined: Apr 09, 2013
Posts: 17
    
    5
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!


    My book: [MongoDB Applied Design Patterns]
    My blog: [Just a Little Python]
    andrew ennamorato
    Ranch Hand

    Joined: Oct 03, 2007
    Posts: 100
    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.
     
    I agree. Here's the link: http://aspose.com/file-tools
     
    subject: How to model docs for use in MongoDB without going backwards
     
    Similar Threads
    10Gen M101 MongoDB for Developers: how was it for you?
    How do you design a data model for object oriented applications?
    MongoDB and NoSQL - when to use or not use it?
    General NoSQL Question: Deciding to go NoSQL
    Text analytics on MongoDb documents