Designing a document databaseLooking 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:
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:
Thoughts?
More posts in "Designing a document database" series:
- (17 Mar 2009) What next?
- (16 Mar 2009) Remote API & Public API
- (16 Mar 2009) Looking at views
- (15 Mar 2009) View syntax
- (14 Mar 2009) Aggregation Recalculating
- (13 Mar 2009) Aggregation
- (12 Mar 2009) Views
- (11 Mar 2009) Replication
- (11 Mar 2009) Attachments
- (10 Mar 2009) Authorization
- (10 Mar 2009) Concurrency
- (10 Mar 2009) Scale
- (10 Mar 2009) Storage
Comments
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.
Rafal,
Can you give me an example please?
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
Second thought is that such join will probably have the same cost as fetching data 'by hand' in map function...
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.
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.
Comment preview