What is New in RavenDB 3.0: Operations - the Pretty Pictures Tour

this has been the most important change in ravendb 3.0, in my opinion. not because of complexity and scope, pretty much everything here is much simpler than other features than we have done. but this is important because it makes ravendb much easier to operate. since the get go, we have tried to make sure that ravendb would be a low friction system. we usually focused on the developer experience, and that showed when we had to deal with operational issues.

things were more complex than they should. now, to be fair, we had the appropriate facilities to figure things out, ranging from debug endpoints, to performance counters to a great debug log story. the problem is that in my eye, we were merely on par with other systems. ravendb wasn’t created to be on par, ravendb was created so when you use this, you would sigh and say “that is how it should be done”. with ravendb 3.0, i think we are much closer to that.

because we have done so much work here, i’m going to split things to multiple posts. this one is the one with all the pretty pictures, as you can imagine. next one will talk about the actual operational behavior changes we made.

let me go over some of those things with you. here you can see the stats view, including looking at an index details.

that is similar to what we had before. but it gets interesting when we want to start actually looking at the data more deeply. here are the indexing stats on my machine:

you can see that the product/sales index has a big fanout, by the fact that it has more items out than in, for example. you can also see how much items we indexed per batch, and how we do parallel indexing.

we also have a lot more metrics to look at. the current requests view along several time frames.

the live index work view:

the indexing batch size and the perfetching stats graph gives us live memory consumption usage for indexing, as well as some view on what indexing strategy is currently in use.

combining those stats, we have a lot of information at our fingertips, and can get a better idea about what exactly is going on inside ravendb.

but so far, this is just to look at things, let us see what else we can do. ravendb does a lot of things in the background. from bulk insert work to set based operations. we added a view that let you see those tasks, and cancel them if you need to:

you can now see all the work done by the replication background processes, which will give you a better idea on what your cluster is doing. and of course there is the topology view that we already looked at.

we also added views for most of the debug endpoints that ravendb has. here we are looking at the subscribed changes connections.

we get a lot of metrics available for us now. in fact, we went a bit crazy there and started tracking a lot of stuff. this will help you understand what is going on internally. and you can also get nice histograms.

there is a lot of stuff there, so i won’t cover it all, but i would show you what i think is one of the nicest features:

this will give you real stats about resource usage in your system. including counts of documents per collection and the size on disk.

okay, that is enough with the pretty pictures, on my next post, i’ll talk about the actual changes we made to support operations better.