What are your thoughts on Raven DB?

Question

What are your thoughts on Raven DB?

I see this below my title: The question you're asking appears subjective and is likely to be closed.

Please don't do that. I think the question is legit because:

1. Raven DB is brand-spanking-new.
2. RDBMS's are probably the de facto for data persistence for .net developers, which Raven DB is not.

Given these points, I would like to know your general opinions. Admittedly, the question is sort of broad. That is intentional, because I am trying to learn as much about it as possible, however here are some of my initial concerns and questions:

1. What about using Raven DB for data storage in a shared web hosting environment, since Raven DB is interacted with through HTTP?
2. Are there any areas that Raven DB is particularly well or not well suited for?
3. How does it rank among alternatives, from a .net developer's perspective?

Answer 1

With my number 1 concern above, about shared hosting environments, it seems that the server can be embedded with the application. I haven't yet found out about running it in less than full trust.

Answer 2

The typical context I see for Raven DB is a web site or single-focused web application with mostly CRUD pages, possibly with lots of fields of a dynamic/optional nature, and a particular need for scalability.

I don't see it well suited for software that needs advanced reporting or data analysis features or as a central database with two or more very heterogeneous applications on top of it.

Data storage in a web hosting environment seems to be a pretty good fit for Raven, actually the 3 main cloud service providers (Amazon, Google and Microsoft) all offer some kind of non-relational data store to their customers. Raven comes with a browser-based administration interface out of the box which makes it all the more convenient to manage remotely.

What I think is nice about Raven DB :

• It makes your ORM layer useless since there is no more an impedance mismatch between objects and relational data storage (biggest benefit for me).
• Data can be accessed in a RESTful and human readable form.
• Much more easily scalable than an rdbms.
• .NET API with Linq querying.
• Fits well with Domain Driven Design style architecture. Raven DB documents are basically aggregates and the recommendations to model your documents are the same as those to constitute DDD aggregates.

What's less :

• If you want to take full advantage of Raven performance wise, your data storage will probably tend to mimic your GUIs a lot.
• Persistance ignorance suffers a bit from what I've seen so far. Using Raven seems to have quite an impact on the way you design your objects. For instance it looks like an entity that refers to an object in another aggregate (another document, in Raven terms) cannot hold a direct reference to that object as you would normally do in an object model, but has to store its ID instead. If you want to persist the entity as it is, this ID has to follow the Raven document key format which I think makes it harder to trace back to the original object it stands for.

Doubts that will need to be removed :

• Performance. Ayende has published some promising performance measures but I guess they need to be generalized and repeated on larger scale projects. I particularly look forward to seeing how Raven's optimistic concurrency system behaves in a transaction-intensive context.
• Adoption. My guess is NoSQL DBs will not survive without a solid ecosystem around them both in terms of supporting community and tools available.

Answer 3

The most compelling plus is the ability to have automatically synchronized materialized views. SQL Server also has materialized views which it automatically matches to any query that is being executed. They can include joins and grouping. However only raven can stack them which is really required if you want to have everything you need for a certain view model in one extremely cheap query. With raven you get performance of a key-value-store but can have normalized data (although Ayende seems to be a fan of denormalization which I deem unnecessary in this system).

Answer 4

One very nice feature, for me, is to use it as an easy data-store for a standalone client application. You could save your date to xml, file, or something like SQLite (possibly with NHibernate), but nothing compares to the ease-of-use with RavenDb.

If you construct your classes well, with aggregates and a domain-driven approach, you can just pass your objects, and RavenDb does the rest. No need for mapping files, serialize attributes, or other complicating stuff. And no need to compromise your model (which is necessary for NHibernate for example).

The fact that you better use a domain-drive approach with aggregates, is a good thing, not a bad thing.