+972 52-548-6969
Quick peek into Voron perf work
time to read 1 min | 199 words
Those are interim results, but it gives me some hope. This is running on a different machine than the numbers I posted before. But I have enough to compare to each other. You can see it here. All numbers are in operations / sec.
Writing 100,000 sequential items (100 items per transaction in 1,000 transactions):
And writing 100,000 random items:
And here is what we really care about. Comparing Voron to Esent:
This is actually pretty amazing, because we are now at about 25% write speed of Esent for sequential writes (we used to be at less than 5%). When talking about random writes (what we really care about) we are neck in neck.
Comments
The first 2 graphs - the smaller bar the better? the last graph - the bigger bar the better?
@Mystical Coder: "All numbers are in operations / sec."
@wqw: then well why does Voron have larger bars than Esent in the first 2 graphs and smaller in the third?
Because he is saying that they were only at 5% of Esent performance-wise originally for sequential writes and now they are ae 25% of Esent, i.e. an improvement... but they are roughly the same as Esent for random writes, which is what they are bothered about.
Not sure how that ties into Voron being better than Esent in both the other graphs though
Awesome that you threw FoundationDB into the mix. Crazy to see Voron just spank it in all those scenarios. I feel the Database Wars heating up :)
I am keen to see how Voron deals with high latency disks like Azure. A high degree of parallelism on writes would make such disks usable. For us it seems half the problem with esent writes is they are bottlenecked by the sequential transaction log.
Did you turn off disk caching?
Also this is a very short run length. How do they change if run over say 50m?
That bottom graph contradicts the top one. At the top it says RavenDB does sequential writes faster (more ops per second). But the bottom graph says the opposite?
These graphs confuse me like Matt pointed out, does the bottom graph mean RavenDB is slower than ESENT?
Turns out Esent is pretty good as a db engine.
Graham, Off by 0 error, it should be an order of manitude higher for Esent.
Khalid, This isn't db wars, this is just storage. This is a lot lower than what db do.
Jahmai, We will also have problems with high latency writes. We have a sequential transaction log. A non sequential transaction log is quite hard to do properly. And it opens you to interesting issues regarding sequentially, which you kind of needs for transactions.
Greg, This is a short test run specifically to show how this behave under this scenario. Mostly, because we're having users that use this micro benchmark as a way to base decisions. We're doing longer & bigger tests, yes. We'll post about them later on.
Phil. I had an typo in the graph, the Esent one should be x10 better.
Whilst I can see there's an interesting comparison to be had between Voron and Esent as competing storage engines, I'm not sure I follow the comparison against full databases; aren't they providing a significant layer on top of their own storage engines? Storage is indeed a lot lower than what DB's do.
Seeing you track your performance gains against Esent is quite exciting. Will you be explaining how you're making these gains?
Paul, People are going to do that, we need to be able to see where we stand. And we are able to see how other db engines do that. I'm having a lot of blog posts to show this off, yes. And explain exactly what we are doing.
Comment preview