This is the third post in a small series about RavenDB – a document database in .NET. I will try to touch the same areas as I did in my series on MongoDB, possibly comparing the two where I see fit.

Now, this time we will take a look at some more querying…

Introduction

After having chewed a bit on the concept of map/reduce queries from doing my MongoDB series, I am actually beginning to see the beauty of this kind of query – and of course RavenDB supports them as well, because it is currently the only sane way to structure aggregate queries in distributed databases.

All of RavenDB’s queries are actually map/reduce queries, but if you don’t supply a reduction function, the reduction is trivial, as every document is emitted in its entirety.

Now, let’s try specifying our own reduction function….

Simple map/reduce query

But first we’ll start out by stuffing some data in the DB:

Now, in order to aggregate each Item by name, summing up the amounts, let’s construct the following index:

Note how this way of structuring the map/reduce differs from MongoDB and CouchDB where the map operation decides which value to aggregate on by emitting it as the key – in RavenDB, this decision is made in the reduce function.

Note also that I need to create a type, ItemAggregate, that is used to tell which fields the reduce function should expect as input. It is important that this type’s fields correspond to those emitted from the map function, or else the serialization will fail silently, yielding no results.

Now, let’s execute the index creation like so:

and now I am ready to query the index:

which yields the following results:

and that was pretty much what I expected.

That was a quick look at map/reduce queries in RavenDB. I’m sure there’s no end to the fun you can have with this kind of stuff, but I have yet to use map/reduce for anything in a real project, so I can’t really comment further on those.

Fun with RavenDB 3

2 thoughts on “Fun with RavenDB 3

  • 2010-11-11 at 22:59
    Permalink

    “All of RavenDB’s queries are actually map/reduce queries, but if you don’t supply a reduction function, the reduction is trivial, as every document is emitted in its entirety.”

    That’s not actually true, if you define a map function, only the fields you map are emitted.

    Of course if you then query that map index you can only query the fields you have emitted, but RavenDB will return the whole document once it has matched it, unless you specify a projection of some sort.

    Reply
    • 2010-11-11 at 23:21
      Permalink

      Yeah, I guess I wasn’t entirely clear on that one either – I’m having a hard time explaining myself 🙂

      What I actually meant to point out, was that – contrary to other map/reduce implementations – the map function is not responsible for projecting… So if no reduce function is specified, the result is documents.

      Reply

Leave a Reply

Your email address will not be published. Required fields are marked *

%d bloggers like this: