What is new in RavenDB 3.0Voron
If you have been following this blog at all, you must have heard quite a lot about Voron. If you haven’t been paying attention, you can watch my talk about it at length, or you can get the executive summary below.
The executive summary is that Voron is a high performance low level transactional storage engine, which was written from scratch by Hibernating Rhinos with the intent to move most / all of our infrastructure to it. RavenDB 3.0 can run on either Voron or Esent, and show comparable performance using either one.
More importantly, because Voron was created by us, this means that we can do more with it, optimize it exactly to our own needs and requirements. And yes, one of those would be running on Linux machines.
But more important, having Voron also allows us to create dedicated database solutions much more easily. One of those is RavenFS, obviously, but we have additional offering that are just waiting to get out and blow you minds away.
More posts in "What is new in RavenDB 3.0" series:
- (24 Sep 2014) Meta discussion
- (23 Sep 2014) Operations–Optimizations
- (22 Sep 2014) Operations–the nitty gritty details
- (22 Sep 2014) Operations–production view
- (19 Sep 2014) Operations–the pretty pictures tour
- (19 Sep 2014) SQL Replication
- (18 Sep 2014) Queries improvements
- (17 Sep 2014) Query diagnostics
- (17 Sep 2014) Indexing enhancements
- (16 Sep 2014) Indexing backend
- (15 Sep 2014) Simplicity
- (15 Sep 2014) JVM Client API
- (12 Sep 2014) Client side
- (11 Sep 2014) The studio
- (11 Sep 2014) RavenFS
- (10 Sep 2014) Voron
Comments
So, how fast is Voron compared to Esent?
Catalin, Run it and test it yourself, I would e very interested in seeing what you'll get :-)
Is Voron somehow more tolerant to power failures than Esent? We use RavenDb for Embedded POS application, and power failures are frequent on this world.
This is currently the major issue we face with RavenDb / Esent - We had to automate the execution of esentutl.exe after a power failure since the database often gets corrupted, but this means that the first startup after a failure takes a LOT of time.
Thanks!
Rodrigo, Yes, Voron so be more resilient to power outages.
Those are excellent news for me. Thanks! :)
That was marvelous to watch! So much details of low level stuff. Really enjoyed!
Thank you but please repeat questions next time. They are difficult to hear.
"... And yes, one of those would be running on Linux machines. ..."
Any insight on the timeline that you can share with us - inquiring minds and all...
J Healy, I'm afraid that we are focused first on getting 3.0 out the door. After that, we are going to start working on this, among others. No word yet on that.
How Voron move journal file to data file's target position ? Append only or create new file from old data and journal file?
Oguzhan, We write to a mmap file and then we call fsync, basically. Only after we return from the fsync do we clear the journal.
Is data file to big for hold in memory/mmap?
Oğuzhan, On 32 bits, that is a problem. On 64 bits, we let the OS deal with paging data in / out.
Comment preview