RavenDB gets filtered replication— like the one CouchDB had for a while

One of the features I asked about was the ability to filter out parts of the namespace for replication — instead of the ‘all or nothing’ approach used by default. […] Basically — my aim is to allow the developer to set replication filters — so only a part of a namespace is replicated — rather than the whole db.

For now this feature is available as a forked project on GitHub.

Original title and link: RavenDB Filtered Replication (NoSQL databases © myNoSQL)

via: http://blogs.sonatribe.com/wayne/2011/06/07/replication-predicates-in-ravendb/

Ayende:

At some point you realize that the data has grown too large for a single server, so you need to shard the data across multiple servers. You bring up another RavenDB server with the sharding bundle installed. You wait for the data to re-shard (during which time you can still read / write to the servers). You are done. At least, that is the goal. In practice, there is one step that you would have to do, you would have to tell us how to shard your data.

In theory, auto sharding would be available in every database. In practice, there are just a few where auto sharding actually works.

Original title and link: RavenDB to Add Auto Sharding (NoSQL databases © myNoSQL)

via: http://ayende.com/Blog/archive/2011/05/03/ravendb-auto-sharding-bundle-designndashearly-thoughts.aspx

Fitzchak Yitzchaki:

Using a document database like RavenDB will give you the following benefits:

• Better performance in your application
• Faster development time
• Better maintenance experience

Wide claims. To me, document databases’ main strengths are:

• data modeling flexibility
• preserving querying capabilities

Everything else is either a consequence of these or an implementation specific improvement which most of the time is the result of another tradeoff.

Original title and link: Why would I use Document Database? (NoSQL databases © myNoSQL)

via: http://blogs.hibernatingrhinos.com/archive/2011/04/10/ravendb-in-practice-part-1-an-introduction-to-ravendb.aspx

Rob Ashton published an article comparing the major NoSQL document databases: CouchDB, MongoDB, and RavenDB, from the perspective that “it’s all about sweet spots”. His conclusions about MongoDB are very interesting:

Mongo on the other hand, is very similar to our traditional databases – with the core difference that data is stored as documents instead of being split out (normalised) across multiple tables. The rest of it all looks very similar – except we lose the ability to do joins across our tables (so complex reporting is out). Reads are fast, but only because Mongo has been micro-optimised to the hilt (just like most database engines), writes are fast, but only because the system doesn’t wait to find out if writes have been successful before carrying on with the next job.

I don’t see it, I don’t see the sweet spot – even if the durability issues are sorted out it’s still just a traditional database with a few less features in the name of gaining a few milliseconds that most of us don’t need.

It achieves fast query speed by storing indexes in memory, which means what Mongo actually gives us is a really slow way to query in memory objects – and heaven forbid you run out of enough RAM to store these indexes on your production servers (ala Foursquare a few months ago). If you’re going to go for an in-memory query store then you’re probably going to use Redis because that’s its sweet spot…

Taking a step back, the two most visible differences between MongoDB and a relational database are:

• data model (relational vs document-based, non-relational)
• a different querying language

In reality there are more than just these two — think in terms of ACID — but they are not that obvious upfront.

So, as I said it before, I think MongoDB would be much better positioned if it would be using SQL. That would offer it a “sweet spot”: applications that haven’t worked with relational databases due to the data model. Think about (prototype) applications that are evolving rapidly their data model. Or applications where JOINs have become too complicated, too slow.

Original title and link: On Document Databases or Is MongoDB Lacking a Sweet Spot? (NoSQL databases © myNoSQL)

via: http://codeofrob.com/archive/2011/01/26/ravendb-vs-mongodb-why-i-dont-usually-bother.aspx

Basic, but clear example with everything you need to get this working:

RavenDB is a document database, and unlike a relational database (like say Microsoft SQL Server) – you can’t do your usual group-by type queries quite as simply. […] For RavenDB instead I need to use a Map-Reduce query. The basics of this are that the first part (the Map) runs over the documents, and finds the matches. The reduce then takes the found matches, and summarises (reduces) the result set.

Original title and link: RavenDB: Emulating Group By Using MapReduce (NoSQL databases © myNoSQL)

via: http://will.hughesfamily.net.au/20101212/ravendb-map-reduce-indexes-and-how-to-install-them/

Ayende writing about choosing between implementing RavenDB cache similar to Hibernate second level cache¹ or HTTP caches:

RavenDB is an HTTP server, in the end. Why not use HTTP caching? […] HTTP Caching is a somewhat complex topic, if you think it is not, talk to me after reading this 24 pages document describing it. But in essence, I am actually using only a small bit of it.

Firstly, if you really want to understand web caches I strongly recommend Mark Notthingham’s Caching tutorial for web authors and webmasters.

Getting back to Ayende’s post, a couple of comments

1. the mechanism described in the post is called conditional GET. According to the HTTP/1.1 RFC:

   The semantics of the GET method change to a “conditional GET” if the request message includes an If-Modified-Since, If-Unmodified-Since, If-Match, If-None-Match, or If-Range header field. A conditional GET method requests that the entity be transferred only under the circumstances described by the conditional header field(s). The conditional GET method is intended to reduce unnecessary network usage by allowing cached entities to be refreshed without requiring multiple requests or transferring data already held by the client.

2. an HTTP caching mechanism should also consider reversed proxies’ behavior. For these to work freshness (Expires) and cache-control (Cache-control) headers must be used

3. without reversed proxies, query caching based only on ETags will in most cases just reduce the bandwith (by not sending back a response), but will continue to fetch the data for calculating the query ETag. Basically, the benefits are smaller.

On the topic of HTTP-based caching, you should also check the article CouchDB and Varnish caching .

Original title and link: RavenDB and HTTP Caching (NoSQL databases © myNoSQL)

via: http://ayende.com/Blog/archive/2011/01/11/ravendb-amp-http-caching.aspx

Looks like RavenDB took a lot of inspiration from CouchDB and CouchApp:

The only reason RavenDB has attachments support is that we wanted to support the notion of Raven Apps (see Couch Apps) which are completely hosted in RavenDB. That was the original impetus. Since then, they evolved quite nicely. Attachments in RavenDB can have metadata, are replicated between nodes, can be cascade deleted on document deletions and are HTTP cacheable.

I didn’t even know RavenDB has something like CouchApps RavenApps.

Original title and link: RavenDB, Attachments, and Raven Apps (NoSQL databases © myNoSQL)

via: http://ayende.com/Blog/archive/2011/01/06/the-design-of-ravendbrsquos-attachments.aspx

A very detailed (and full of screenshots) tutorial on setting up RavenDB as an IIS application^[1]:

We successfully installed and set up Raven DB to run in IIS.  Just navigate to http://localhost:8080 url or in IIS Manager make sure the new web site is selected and click on “Browse *:8080 (http)” link in Action section.  Rave DB page should be opened in your favorite browser.

Original title and link: RavenDB: Run as an IIS Application (NoSQL databases © myNoSQL)

via: http://vkreynin.wordpress.com/2010/12/13/setting-up-ravendb-as-an-iis-application-by-pictures/