What is up with RavenDB 2.0?
The last stable version of RavenDB 1.0 was released about six months ago, ever since then, we were hard at work adding new features, improving things and in general doing Good Work.
Looking back into the last half a year of work, it is actually quite hard to pick out the major stuff. There was so much we did. That said, I think that I can pick up some things to salivate on for 2.0.
First & foremost, we drastically improved the RavenDB Management Studio (RDBMS). We spent a lot of time there, and you can now do pretty much everything you want in RavenDB through the studio. This seems like a stupid major feature, right? After all, this is just the UI that was updated, and RavenDB is actually the server stuff. But it provides you with at least an order of magnitude better tooling and ability to work more easily with RavenDB.
And that is really just the tip of the iceberg in terms of what is new in the studio.
But even though the changes to the studio are probably the most obvious ones, we have done a tremendous amount of work of work the server itself. Here are some of the highlights.
Operational Support – We spent a lot of time on making sure that ops people will have a lot of reasons to be happy with this new release. You can monitor this using any standard monitoring tool (SCOM, MOM, HP OpenView, etc). We expose a lot more data through performance monitors and logs. And we even added dedicated endpoints that you can hit to gather monitoring information (which database is currently doing what, for example) that would give ops the full view about what is actually going on there.
Core Bundles - We always had bundles, and we implement a lot of features through them. But in 2.0, we took a lot of the bundles and move them to the core, so now you can configure & use them easily.
Setting them up on new DB setup:
Setting up replication through the UI:
We have management UI support for all of the core bundles now, which makes using them a lot easier.
Changes() API – this allows you to get PUSH notifications from the RavenDB Server, you can subscribed to events from a particular documents, a set of documents or an index. That allows you to notify the user if something have changes without the need to do any expensive polling. The studio was actually doing a lot of polling, but we changed pretty much all of that to be PUSH based now.
Here is an usage sample:
1: store.Changes()
2: .ForDocument("users/1")3: .Subscribe(notification =>
4: {
5: using(var session = store.OpenSession())6: {
7: var user = session.Load<User>(notification.Name);8: Console.WriteLine("Wow! " + notification.Name + " changed. New name: " + user.Name);9: }
10: });
Yes, it is as easy as this .
Eval Patching – you can now run JS scripts against your objects, to modify them on the server side. This is perfect if you want to do migrations (if you actually need to, usually you don’t), want to run some complex modification on the server side or just need to do something as an administrator.
More authentication options & control – We now have a far easier time defining and controlling who can access the server, and what databases they can touch.
Here is an example of allowing the network service to have access to the tryout database:
And here we have an example of defining API Keys:
This allows your to define an API Key for a particular application very easily (vs. defining users ,which is usually how you handle admin / ops people coming in).
Indexing Performance – We have spent a lot of time on optimizing the way we are handling indexing. In particular, we now do a lot of work to make sure that we don’t wait for IO and we use as many cores as we can to get things done even faster. Even when you throw a lot of data at RavenDB, indexing catch up very quickly and the indexing latency is far lower.
Better map/reduce – Our map/reduce implementation have been drastically improved, allowing us to re-process and update existing results with a lot less computational & IO needs at the large scale of things.
Better facets – We have completely remapped the facets support, reducing the per facet value cost that used to be there. Now we are able to generate facets quickly regardless of how many facet values you have in a facet, and we even support paging & sorting of facets.
Better IN Query – This sounds silly, but supporting an efficient IN query is important for a lot of scenarios, especially when the number of items in the IN is large. We have a dedicated support for doing that efficiently and easily now.
Async – We matched all the standard client capabilities in our Async API, that means that we support async sharding, async replication failover, and the whole shebang. It means that using RavenDB with C# 5.0 is just as easy as you can imagine, it is all been done for you.
Sharding improvements – In addition to the async sharding support, we worked on improving sharding itself, giving you more integration & extensions points and made the whole thing just a tad bit smarter by default.
Cloud Backup – Backing up is hard to do, and we have decided to make it easier. In addition to supporting all enterprise backup tools, and having the ability to manually trigger backups or export (full or incremental), we now have the ability to schedule automatic backups to the cloud.
You can setup period backups to Amazon Glacier or Amazon S3, and it will incrementally backup your database there as we go along.
CSV Import / Export – Silly, but data still goes around mostly in flat files, and RavenDB now support importing & exporting data in CSV format, so you can easily pull some data into excel or push some data that you got from some other source.
Debuggability – We now expose a lot more hooks for you to use when you debug things. You can look directly into how the index is built (index entries, stored fields, etc), you can inspect the intermediate steps of RavenDB’s map/reduce processes, how the IO processes for loading document work, indexing times and a lot more.
There are more, but I think that this is enough for now.
Comments
I would really love to see a detailed comparison to MongoDB written up that shows performance and scalibility numbers and why you would pick RavenDB over Mongo. Mongo is the leading document db and I think that represents a great opportunity for you to win people over by provide concrete data and reason why RavenDB is a better choice.
I agree with Eric J Smith - I am at the point where I am choosing a document store, and I love what I see here for Raven, but pulled by Mongo because of the momentum it has.
I'll third that motion. We are using Mongo internally for several small apps, but I really like what I see with Raven. It would be nice to see a comparison of the two.
A MongoDB vs RavenDB write-up would be very interesting.
@Rob I have been using RavenDb since v1 and can tell you that v2 is an amazing leap forward for the product. The performance is great when dealing with Maps. If you are developing in the .Net sphere, then RavenDB is the definite winner in my book. The only thing that might keep you from choosing RavenDB is cost vs. Free.
If I had one thing I would wish for is to kill the silverlight admin and move to HTML5 based admin. Tired of seeing Silverlight crashes due to VMWare.
Not at all. Tooling is often overlooked in the NoSQL space. I find Mongo's management studio severely lacking. Glad to see Raven 2.0 improving its tooling.
Woops, wrong quote. :-) I meant to quote the post,
"We spent a lot of time there, and you can now do pretty much everything you want in RavenDB through the studio. This seems like a stupid major feature, right? After all, this is just the UI that was updated, and RavenDB is actually the server stuff."
I have two Mongo systems in production and have been experimenting with RavenDb and would never use Mongo again. The productivity from even the 1.0 management studio and ease of use inside .NET make it a very easy choice.
RavenDb is so freaking fast and productive to develop with I really wouldn't care if Mongo was twice as fast.
The benefits I gain in productivity save me so much time I'd worry about scaling when it happens. Besides, unless you are a top 10,000 website or have billions of documents chances are Raven will perform just fine and all the facets,map/reduce and indexing features of Ravendb handle a lot of the issues you'll encounter anyway.
For example a mongo application I was part of had this weird taxonomy of attributes that eventually required a full custom lucene implementation and all sorts of extra work just to make searching the data perform well.
I recreated the multi week project in RavenDb index in an afternoon. :p
For the changes API when you say "a set of documents" do you mean a collection like "users".
If so does it get triggered when the collection changes (i.e. add / update of a document in the collection)?
I fell in love with RavenDB and I played with it a lot just for fun; but unfortunately I can not use it in my productions. The licensing prevents me even from using it as a backend for a service. And price is too high for my company. But besides that RavenDB is a really nice product.
William, Yes, you can do that like that. And it is triggered on changes to a document with the prefix "users/"
When an article Mongo DB vs Raven DB ?
Spare me the comparison, such articles only draw out the zealots. Just do the comparison yourself, should not be so hard...
+1 to the HTML5 studio. I would trade every feature in this post for not having to deal with Silverlight any more.
The other thing causing us a lot of pain is the Newtonsoft.Json version conflict with MVC4. Is there a 2.0 release date yet?
Sam, It is going to be out this month,
Any closer to a release date?
Georgios, We run into memory issues, looking into that now.
Comment preview