Open jvsteiner opened 5 years ago
Badger has a long way to go to gain any credibility, as far as I'm concerned. It has a miserable history of preferring to run benchmarks without fsync, claiming that data loss is not loss of data (yup, you read that right: "if the bug only causes Badger to not return data, and the data is fully recoverable by an easy fix to the code -- that's technically not a data loss"), and what not. Building a castle on a swamp just ain't a way to good architecture.
https://github.com/dgraph-io/badger/issues/28
https://github.com/dgraph-io/badger/issues/570
https://github.com/dgraph-io/badger/issues/575
https://github.com/dgraph-io/badger/issues/579
@jvsteiner
this port surpasses the performance of badger
Can you share the metrics for this? I cant seem to find any benchmarks.
As you can see, the post was pretty old. I used it then, in a project that I am no longer involved with. I had benchmarks, but they were a part of the propriety code from that project.
I'd like to point out that I noticed that this port surpasses the performance of badger, which I actually find a bit worrying. Especially since the performance is better, even when passing
&opt.WriteOption{Sync:true}
to the call to Set. I'd like to know more about the crash resistance of this library, and in how much detail it has actually been been tested. Badger did their homework: https://blog.dgraph.io/post/alice/