+972 52-548-6969
When should you use RavenDB?
This is a question a lot of people are asking me, and I keep give them the same answer. “I am the one building RavenDB, your grandmother and all her cats deserve to have three licenses, each (maybe with 3 way replication as well).”
Kidding aside, it is a serious question, which I am going to try answering in this post. I just wanted to make sure that it is clear that there might be some bias from my perspective.
Having built NHibernate based application for years, and having built RavenDB based applications from almost the point where it could start up on its own, I can tell you that there is quite a bit of a difference between the two. Mostly because I intentionally designed RavenDB and the RavenDB client API to deal with problems and frustrations in the NHibernate / RDMBS model.
What we discovered is that the lack of mapping and the ability to store complex object graphs in a single document makes for a speedy development and high performance applications. We usually see RavenDB being used in OLTP applications or as a persistent view model store (usually for the performance critical pages).
Typically, it isn’t the only database in the project. In brown field projects, we usually see RavenDB brought in to serve as a persistent view model store for the critical pages, data is replicated to RavenDB from the main database and then read directly from RavenDB in order to process the perf critical pages. For green field projects, we usually see RavenDB used as the primary application database, most or all of the data resides inside RavenDB. In some cases, there is also an additional reporting database as well.
So the quick answer, and the one we are following, is that RavenDB is imminently suitable for OLTP applications, and can be used with great success as a persistent view model cache.
Comments
Regarding the persistent view model cache, would you advise using RavenDB in place of a distributed cache, or alongside one? What advantages would you gain over using a persistent distributed cache? Is RavenDB a direct competitor to something like membase (now couchbase)?
Jonty, That really depend on your scenario. We see RavenDB used to store the view model in aggregated form, already prepared to be consumed. We are storing pretty much all of the information you need for a single page view on a single document, which makes us really fast for rendering complex pages.
RavenDB is fast compared to an RDBMS for data persistence but is still no match for Redis or Memcached as a distributed cache which both operate in memory, (although Redis can be made to persist to disk).
I did some benchmarks a while ago comparing raw write performance of Redis vs RavenDB: http://www.servicestack.net/mythz_blog/?p=474
Redis is used as the distributed cache for all StackOverflow websites because its so fast.
I find the post lacking substantial information: a NoSQL database stores data denormalized, and without schema. These are aspects which are crucial for the data and more importantly, the information that's being distilled from it: an RDBMS stores data normalized and WITH schema. Both have advantages and disadvantages. An article which describes 'when to use a NoSQL database' (in this case RavenDB) IMHO should address these advantages and disadvantages, if the article is about describing when to pick RavenDB over an RDBMS. I.o.w.: the post is useless without that.
If your intention was to describe when to pick RavenDB over other NoSQL / Document DBs / OODBs, you should address the advantages of RavenDB over these other choices. Again you don't do that.
Bouma++
Bouma, For these types of scenarios there really is no answer, at least not a cut-and-dry one. Ayende says you can use it for OLTP, or as a Persistent View Model Cache, or whatever you please. When and how, however, is ultimately up to you. If you need normalized data with schema as you pointed out, than you probably need an RDMBS. I think Ayende, somewhat subliminally, is making the point that there really is no "best-practice" here and there are many considerations and touch points in deciding between document and relational. In my opinion, one generally does the community a great service when not listing out bullet lists of how and where and when to do things.
I agree with Frans Bouma.
I know the answer to his question, but it's because I read this blog daily, have read a lot of the RavenDB documentation, follow the google group, and have been using RavenDB on a project.
It would be nice to see a list of all the things it solves and why could almost always choose no-sql for OLTP. People that are used to using relational databases don't even understand the benefits until they understand how the objects are broken up differently and how they should be used in RaveDB.
You've (Ayende) definitely covered this, but the info is spread out across other blog posts, RavenDB docs, and the group. Maybe just a brief description and a link would suffice.
I don't intend to rail on you, Joe, or Ayende, but that is an attitude I see frequently on this blog. I completely understand that you can't post a single example as a "best practice", however without any sort of concrete example, these potentially helpful tips remain too ethereal to assist many people.
I, and any other developer worth his/her salt, understand that you can't take a single piece of sample code, slather it all over your application, and say "Ayende and Joe told me to do it." However, a concrete example moves the conceptual into reality, and gives one a place to start his investigations.
Cargo Cult coders are going to copy and paste no matter what you do, if not from you than someone else.
It's Ayende's blog, and he can post whatever he wants, but many times I come here only to be frustrated because nobody wants to steer anyone in the wrong direction. Throw something practical out there and trust that people can manage not to shoot themselves in the foot.
This is truly new to me. What are some samples of RavenDB based applications?
these days quality of your posts are too low...
@Kurt
You could look at the code that runs Ayende's blog
https://github.com/ayende/RaccoonBlog
There's one major use case for RavenDB.
If you need to create a prototype application in a real hurry, nothing beats RavenDB. Design your objects, stuff it in, query it out and complete your prototype in record time.
It would be great if you could share the comparison chart and tests (db, data or script) that shows a scenario where RavenDB is preferable over other RDBMS ..
I always want to use RavenDB but it's hard to conceive the mgmt that this little db is better than MSSQL or Oracle that we spent thousands $..
The main blog says "..data is replicated to RavenDB from the main database .." and ".. there is also an additional reporting database as well..". What are the best and proven ways to migrate data to (in first statement) and from (in second statement) RavenDB to relational database say SQL Server? One of the Google Group discussion mentioned about using RavenDB Index Replication (http://ravendb.net/bundles/index-replication) but that seem to be limited to replication of index and not the data. Another discussion mentioned about Rhino ETL (http://ayende.com/blog/3102/rhino-etl-2-0). It will be great if you can give some insight into either of those or other alternatives. Thanks for your help.
Chirag, You can't usually replicate information from ravendb to relational. The format doesn't work, that is why you need to specify a transformation function, and that is where we have the index replication, the index provide the transformation function.
Going directly the other way is possible, but usually not really recommended, because you WANT to take advantage of the different structure options in RavenDB.
Usually, you write some sort of an ETL between the two
Comment preview