How to model docs for use in MongoDB without going backwards

andrew ennamorato

Ranch Hand

Posts: 100

posted 3 years ago

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

posted 3 years ago

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

posted 3 years ago

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.