An Optimization Opportunity with RavenDB and FreeDB

update: the numbers in this post are not relevant. i include them here solely so you would have a frame of reference . we have done a lo t of optimization work, and the numbers are orders of magnitude faster now. see the next post for details.

the purpose of this post is to setup a scenario, see how ravendb does with it, and then optimize the parts that we don’t like. this post is scheduled to go about two months after it was written, so anything that you see here is likely already fixed. in future posts, i’ll talk about the optimizations, what we did, and what was the result.

system note: i run those tests on a year old desktop, with all the database activity happening on a single 7200 rpm 300gb disk with 8 gb of ram. please don’t get to hung up on the actual numbers, i include them for reference, but real hardware on production system should kick this drastically higher. another thing to remember is that this was an active system, while all of those operations were running, i was actively working and developing on the machine. the main point is to give us some sort of a metric about where we are, and to see whatever we like this or not.

we keep looking at additional things that we can do with ravendb, and having large amount of information to tests things with is awesome. having non fake data is even awesomer, because fake data is predictable data, while real data tend to be much more… interesting.

that is why i decided to load the entire freedb database into ravendb and see what is happening.

what is freedb?

freedb is a database to look up cd information using the internet. this is done by a client (a freedb aware application) which calculates a (nearly) unique disc id for a cd in your cd-rom and then queries the database. as a result, the client displays the artist, cd-title, tracklist and some additional info.

the nice thing about freedb is that you can download their data* and make use of it yourself.

* the not so nice thing is that the data is in free form text format. i wrote a parser for it if you really want to use it, which you can find here: https://github.com/ayende/xmcdparser

so i decided to push all of this data into ravendb. the import process took a couple of hours (didn’t actually measure, so i am not sure exactly how much), and we ended up with a ravendb database with: 3,133,903 documents. memory usage during the import process was ~100  mb – 150 mb (no indexes were present).

the actual size in ravendb is 3.59 gb with 3.69 gb reserved on the file system.

starting the database from cold boot takes about 4 seconds.

this is what the document looks like:

a full backup of the database took about 3 minutes, with all of the time dedicate for pure i/o.

doing an export, using smuggler (on the local machine, 128 document batches) took about 18 minutes and resulted in a 803mb file (not surprising, smuggler output is a compressed file).

note that we created this in a completely empty database, so the next step was to actually create an index and see how the database behaves. we create the default raven/documentsbyentityname index, and got 5,870 seconds, so just over an hour and a half. for what it worth, this resulted in on disk index with a size of 125mb.

i then tried a much more complex index:

just to give you some idea, this index gives you full text search support over just about every music cd that was ever made . to be frank, this index scares me, because it means that we have to have index entry for every single track in the world.

after indexing was completed, we ended up with a 700 mb on disk presence. indexing took about 7 hours to complete. that is a lot, but remember what we are dealing with, we indexed 3.1 million documents, but we actually indexed, 52,561,894 values (remember, we index each and every track ).  the interesting bit is that while it took a lot of cpu (full text indexing usually does) memory usage was relatively low, it peaked about 300 mb and usually was around the 180mb).

searching over this index is not as fast as i would like, taking about a second to complete. then again, the results are quite impressive:

well, given that this is the equivalent of a 52 million records (in this case, literally records ) , and we are performing full text search, quite nice.

let us see what happens when do something a little simpler, shall we?

in this case, we are only indexing 3.1 millions documents, and we don’t do full text searches. this index took 2.3 hours to run.

queries on that are a much more satisfactory rate of starting out at 75 ms and dropping to 5 ms very quickly.