5

I'm slightly embarrassed to admit it, but I'm having trouble conceptualizing how to architect data in a non-relational world. Especially given that most document/KV stores have slightly different features.

I'd like to learn from a concrete example, but I haven't been able to find anyone discussing how you would architect, for example, a blog using CouchDB/Redis/MongoDB/Riak/etc.

There are a number of questions which I think are important:

  1. Which bits of data should be denormalised (e.g. tags probably live with the document, but what about users)
  2. How do you link between documents?
  3. What's the best way to create aggregate views, especially ones which require sorting (such as a blog index)
Community
  • 1
  • 1
sh1mmer
  • 1,316
  • 11
  • 19

3 Answers3

3

First of all I think you would want to remove redis from the list as it is a key-value store instead of a document store. Riak is also a key-value store, but you it can be a document store with library like Ripple.

In brief, to model an application with document store is to figure out:

  1. What data you would store in its own document and have another document relate to it. If that document is going to be used by many other documents, then it would make sense to model it in its own document. You also must consider about querying the documents. If you are going to query it often, it might be a good idea to store it in its own document as you would find it hard to query over embedded document.
    • For example, assuming you have multiple Blog instance, a Blog and Article should be in its own document eventhough an Article may be embedded inside Blog document.
    • Another example is User and Role. It makes make sense to have a separate document for these. In my case I often query over user and it would be easier if it is separated as its own document.

  2. What data you would want to store (embed) inside another document. If that document only solely belongs to one document, then it 'might' be a good option to store it inside another document.

    • Comments sometimes would make more sense to be embedded inside another document

    { article : { comments : [{ content: 'yada yada', timestamp: '20/11/2010' }] } }

    Another caveat you would want to consider is how big the size of the embedded document will be because in mongodb, the maximum size of embedded document is 5MB.

  3. What data should be a plain Array. e.g:
    • Tags would make sense to be stored as an array. { article: { tags: ['news','bar'] } }
    • Or if you want to store multiple ids, i.e User with multiple roles { user: { role_ids: [1,2,3]}}

This is a brief overview about modelling with document store. Good luck.

Joshua Partogi
  • 16,167
  • 14
  • 53
  • 75
  • to understand better: if you want to add user inside the comments, I think you have to denormalize and adding both the username and the userid inside every comment. In this way you can show the blog comments without querying also the users, but you can easily retrieve all blog posts commented by a given user. Is this right? – Uberto Nov 22 '10 at 16:02
  • Not really. You can add the userid only in the comment document. But it's upto you how you want the data to be organized. I usually put the userid and user email in the comment because I want to generate gravatar. – Joshua Partogi Dec 02 '10 at 22:38
1

  1. Deciding which objects should be independent and which should be embedded as part of other objects is mostly a matter of balancing read/write performance/effort - If a child object is independent, updating it means changing only one document but when reading the parent object you have only ids and need additional queries to get the data. If the child object is embedded, all the data is right there when you read the parent document, but making a change requires finding all the documents that use that object.

  2. Linking between documents isn't much different from SQL - you store an ID which is used to find the appropriate record. The key difference is that instead of filtering the child table to find records by parent id, you have a list of child ids in the parent document. For many-many relationships you would have a list of ids on both sides rather than a table in the middle.

  3. Query capabilities vary a lot between platforms so there isn't a clear answer for how to approach this. However as a general rule you will usually be setting up views/indexes when the document is written rather than just storing the document and running ad-hoc queries later as you would with SQL.

Tom Clarkson
  • 16,074
  • 2
  • 43
  • 51
0

Ryan Bates made a screencast a couple of weeks ago about mongoid and he uses the example of a blog application: http://railscasts.com/episodes/238-mongoid this might be a good place for you to get started.

Bastien
  • 481
  • 4
  • 16