Ayende @ Rahien

My name is Oren Eini
Founder of Hibernating Rhinos LTD and RavenDB.
You can reach me by phone or email:


+972 52-548-6969

, @ Q c

Posts: 6,131 | Comments: 45,563

filter by tags archive

Rhino Divan DB – Performance

time to read 2 min | 330 words

The usual caveat applies, I am running this in process, using small data size and small number of documents.

This isn’t so much as real benchmarks, but they are good enough to give me a rough indication about where i am heading, and whatever or not i am going in completely the wrong direction.

Those two should be obvious:

image image

This one is more interesting, RDB doesn’t do immediate indexing, I chose to accept higher CUD throughput and make indexing a background process. That means that the index may be inconsistent for a short while, but it greatly reduce the amount of work required to insert/update a document.

But, what is that short while in which the document and the DB may be inconsistent. The average time seems to be around 25ms in my tests, with some spikes toward 100 ms in some of the starting results. In general, it looks like things are improving the longer the database run. Trying it out over a 5,000 document size give me an average update duration of 27ms, but note that I am testing the absolute worst usage pattern, lot of small documents inserted one at a time with index requests coming in as well.


Be that as it may, having inconsistency period measured in a few milliseconds seems acceptable to me. Especially since RDB is nice enough to actually tell me if there are any inconsistencies in the results, so I can chose whatever to accept them or retry the request.


Uriel Katz

The index update seems high for 5,000 documents.

If you scale it to let say 5 million documents,it wil take at least 27 seconds,and this is in the really good case that the indexing scale in a linear way.

As you said this is really a small dataset.


Uriel, probably there is a large constant cost, so you cannot multiply it by 1000.

Ayende Rahien


There is a cost per indexing operation, which is pretty high, but that cost isn't affected by the size of the already indexed documents.

5,000 docs or 5 millions, doesn't matter for the indexing op

Uriel Katz

Oops,you are right i forgot that the cost is per a set of modified/added documents.

How many indices are you updating with those 5,000 docs? i guess if you have many indices(for many views) the cost per document will grow too,right?

Richard Dingwall

It might be too soon, but would be cool to see performance benchmarks comparing RDB to NoSQL databases.


I understand the delay between changing the document and the time the change is reflected by an index is practically constant. Does it mean that no matter how many documents are updated, the index update delay will be more or less the same? What about a 'flood' of changes at maximum possible rate?

  1. What about having several indexes? In many systems I have seen tables having 10-20 indexes for various kinds of search/sorting. What will be the index update delay if there are 20 indexes?

  2. Did you measure the insert/update performance in a multithreaded environment?

Ayende Rahien


It is WAY too soon to do real benchmarks for Raven.

I only did this test to prove that I this approach is valid

Ayende Rahien


Indexing time for a single document is practically zero, the cost is actually writing & flushing to the index.

A flood of changes doesn't really bother me, you can still access all the data, and the index will keep up with the work being done. The only bad affect is that the index will indicate that it is stale, but there is no real helping that here.

2) Each index is handled separately, more or less, so there would be some indexes that might take a bit longer, but I don't believe that significantly so.

3) Index update is a single threaded operation by nature.

Ryan Roberts

Isn't a large number of small writes pretty hard to optimise with Lucene, as it means you need to drop and reopen any existing index readers?

How are you handling index optimisation?

Ayende Rahien


As I said, this is the absolute worst possible scenario

Comment preview

Comments have been closed on this topic.


  1. RavenDB Conference 2016–Slides - 17 hours from now
  2. Proposed solution to the low level interview question - about one day from now

There are posts all the way to Jun 02, 2016


  1. The design of RavenDB 4.0 (14):
    26 May 2016 - The client side
  2. RavenDB 3.5 whirl wind tour (14):
    25 May 2016 - Got anything to declare, ya smuggler?
  3. Tasks for the new comer (2):
    15 Apr 2016 - Quartz.NET with RavenDB
  4. Code through the looking glass (5):
    18 Mar 2016 - And a linear search to rule them
  5. Find the bug (8):
    29 Feb 2016 - When you can't rely on your own identity
View all series



Main feed Feed Stats
Comments feed   Comments Feed Stats