Ayende @ Rahien

Refunds available at head office

Designing a document database: Looking at views

I was asked how we can handle more complex views scenarios. So let us take a look at how we can deal with them.

Joins

In a many to one scenario, (post & comments), how can we get both on them in one call to the database? I am afraid that I am not doing anything new here, since the technique is actually described here. The answer to that is quite simple, you don’t. What you can do, however, is generate a view that will allow you to get both of them at the same time. For example:

image

The key here is that views are always calculated in sort order, so what is actually happening here is that we sort by post id, then by IsPost. Since false is higher then true, the actual post is always the first item, with the comments directly following that. This means that we can query for all of them in one DB call.

Returning more than a single result per row

To be fair, I haven’t considered this, but it seems like a pretty obvious that this is needed. Here is the original request:

Question: can a view contain more rows than the underlying document database? For example: assume an invoice database (each document is an invoice with buyer's and seller's Tax ID). I want to create index: Tax ID -> #of invoices, where tax id can belong either to buyer or seller. In worst case scenario, unique tax IDs in every invoice, we'll have index with 2N entries. How view syntax would look like?

If I understand the problem correctly, this can be resolve using the following view definition:

image

Thoughts?

Comments

Rafal
03/16/2009 06:37 PM by
Rafal

Regarding the problem with joins, maybe there should be an option to left-join with an already existing view by its key? Not necessarily in v 1.0.

Ayende Rahien
03/16/2009 06:39 PM by
Ayende Rahien

Rafal,

Can you give me an example please?

Rafal
03/16/2009 07:05 PM by
Rafal

Let's stick to the invoice db example. Suppose we have invoice documents with buyerTaxID and corporate customer database, customers identified also by Tax ID. And we have a view Tax ID -> Customer (vCustomerByTaxID) . Then, when doing mapping on invoices, we could tell the system to fetch customer data from vCustomerByTaxID, where key is in invoice's buyerTaxId field. Something like

select d as doc, vCustomerByTaxId.Value as customer

from docs

join vCustomerByTaxId on docs.buyerTaxId

Rafal
03/17/2009 07:04 AM by
Rafal

Second thought is that such join will probably have the same cost as fetching data 'by hand' in map function...

Nathaniel Neitzke
03/17/2009 02:41 PM by
Nathaniel Neitzke

Ayende,

This is the problem that map-reduce-merge was intended to solve, relational algebra (joins especially) in map reduce. Sorry the link before was an ACM one, but if you google for map-reduce-merge there is a decent amount of info out there. This is what I am working on implementing at the moment.

Ayende Rahien
03/20/2009 11:13 AM by
Ayende Rahien

Nathaniel,

I read some about it. What seems to be missing is the concept of updatable data source.

That is the problem that I am trying to solve at this stage. And the main goal is to reduce the amount of work that I have to do whenever I have to update a document to a minimum.

Comments have been closed on this topic.