NoSQL Zone is brought to you in partnership with:

Mike is co-founder of Fiesta - https://fiesta.cc. Before Fiesta, he was a developer working on the MongoDB project. Mike is a DZone MVB and is not an employee of DZone and has posted 14 posts at DZone. You can read more from them at their website. View Full User Profile

MongoDB Schema Design by Example

01.07.2012
| 11667 views |
  • submit to reddit

This was a live-blog from a MongoSV session. Here’s a link to the entire series of posts.

Kyle’s strategy is to start with a normalized representation and then embed for simplicity and optimization. This reminds me of our data-modeling post.

1. Hierarchies

Two strategies; first is to store the canonical hierarchy in a single document. That allows atomic updates of the hierarchy, but can make other ops difficult. The second is to store a list of ancestors in each document; that’s the one we’ll talk about. Each node has a parent_id with the immediate parent. Each also has an array of ancestors. It’s easy to display a single node, but it’s also easy to display all descendants of a node (by looking inside the ancestors array). What about updates?

There’s a new helper to compute ancestors for a node and overwrite the ancestors array (in case we insert in the middle of the hierarchy). When we do an insert in the middle we’ll need to run the helper on each descendant, since they all have a new ancestor.

tl;dr use arrays and multi-key indexes (and the positional operator) to deal with hierarchies.

2. Ticketing

What about ticketing, don’t you need transactions? How can you do transactions w/o RDBMS style transactions? Distributed systems, long-running transactions, and contentious environments might require different strategies (see paper: your coffee shop doesn’t use two-phase commit). Let’s see an example:

Two collections. One is a map of available seats for an event. The second has one document for each seat, with a state (available or not) and price.

Use find-and-modify as a TAS operation to update the state of seats to “Cart”. If it succeeds all of the seats then we’re good to go. If not, we can manually roll-back state. Basically do each state-change manually and be prepared to roll-back if needed.

This isn’t right for everything but it works for some.

3. Feed reader example

Four collections: users, feeds, entries and buckets.

Users have username and an array of feeds. Each feed in that array is a document with an ID and denormalized name. We’ll index on username.

Feeds collection each has a URL, name, subscriber count (denormalizing here again) and date of last entry.

To add a feed, do an upsert to insert if missing or increment subscriber count otherwise (good use of upsert). Also need to do an $addToSet on the user to add the feed to the feeds array.

Removing means a $pull from the user’s feed array and a $inc of -1 on the feed’s subscriber count.

Entries documents each have content for a single entry, with ID of feed it belongs to.

We need a way to show an individual user’s feed: that query can be expensive if done naively. That’s what bucketing is for: only query for latest entries and then store them in a bucket.

A bucket has a user_id, timestamp, and list of entries. We can just query for buckets to get a users feed. Again, we’re selectively denormalizing here to get good locality and performance. Use rich documents for caching. This gives good sharded locality, too.

Source:  http://blog.fiesta.cc/post/13979455049/mongosv-live-blog-schema-design-by-example

Published at DZone with permission of Mike Dirolf, author and DZone MVB.

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)