RavenDB Founder On .NET, ACID with NoSQL, Upcoming Features
RavenDB 2.0 was recently released with several new features. In an InfoQ exclusive interview, Oren Eini (Ayende Rahien), founder and project lead of RavenDB, shares the rationale behind various decisions in the project, as well as what’s coming up.
When RavenDB project was started back in 2009, Erlang was one of the choices evaluated to build it on – however, the team decided to stick with .NET due to their existing experience with it, the availability of significant choice of libraries and adoption rates within the Enterprise Ops community.
We have been working with .NET since the early 1.0 Alpha days. It is an environment that we are familiar with, are very comfortable with and one that allows us to get the performance, reliability, stability and ease of development that we need to create a top tier database.
In addition, we wanted something that would integrate well and easily into the existing eco system for many shops. Being able to build on top of a very well established foundation. This applies both to the client side, where we offer really good .NET integration, and for the server side (operations), where we allow easy extensions, monitoring and customization.
Erlang is very limited in the type of libraries that it has, and some things are just plain hard to do. In particular, compared to the richness of the environment of the CLR, Erlang is a barren land. And yes, I am fully aware that I'll bring a tidal wave of Erlang fans after me. I didn't make this decision lightly. Before making it, I went through the entire CouchDB codebase, and tried to grok it all (and yes, I am aware that at least at the time, CouchDB wasn't idiomatic Erlang).
Just to give you some examples, RavenDB makes uses of underlying libraries like Lucene or several out of the box spatial libraries that exists for the CLR. Finding similar things for Erlang is hard, if they exist at all.
But in the end, it was a matter of expertise. We know how to make the CLR sit up & beg, how to make it roll over, and how to make it stop playing dead.
The choice seems to have worked and RavenDB is now in the top 2% of all the project teams in Ohloh.
One of the advantages that RavenDB provides over several other NoSQL databases is the existence of ACID guarantees -
I think that many NoSQL solutions are only now learning what became obvious to the DB guys in the late 70s. Working without transactions is hard. And not being able to rely on that leads to trying (and failing) to manage transactions in your code, random data corruption and a lot of complexity all around.
Sure, transactions aren't simple, and they require finesse to write correctly and in a performant manner, but there really is no good alternative. Asking business developers to deal (in addition to all of their existing headaches) with ensuring transactional system is just too much.
As an occasional application developer myself, I can tell you that you'll pry transactions from my cold dead hands. That is why one of the core promises that RavenDB has is the notion of transactional safeties. That include the full ACID promise.
RavenDB has a bundle-based architecture – a thin core which has hooks in place for developers to extend RavenDB. Oren explains that a lot of features released by the RavenDB team itself are initially through feature-packs, that can be opted in by choice. Over time as the code matures, the features are moved to the core. This makes it easy to provide large new features non-disruptively. Developers can also choose to build their own extensions – all they need to do is inherit from one of the supplied extension points, compile code and drop the dlls in the Plugins folder.
On what to look forward to in the next year -
We want to have additional clients, from WinRT to Android to iPhone to the JVM. There are plans afoot to have a better central management system for large clusters of RavenDB nodes. We want to do some work on the notion of doing reports on top of RavenDB, although this is highly experimental and might not end up anywhere. But the most important item of work we will probably have is improvements in the indexing management, the query optimizers and how RavenDB auto tunes itself for production usage.