How does this compare to Redis?
Redis isn't embeddable, but a standalone server application, and thus it's not really the same space.
Design Review: Key-Value Storage
11–20 of 90 posts
Re: Design Review: Key-Value Storage
#12How does this compare to Redis?
It actually stores data.
Re: Design Review: Key-Value Storage
#13I'm really surprised LSM trees didn't get more commentary. 'All are targeted at server workloads' - sure, but they're also incredibly popular and appear to be as close to the 'one-size-fits-all solution for storage' as we've found.
Also typically more complicated and require a separate compaction process. They're good for writing lots of data, but not so great for random reads.
Author of Badger here. Our design of separating keys and values has gotten us incredibly fast writes, while still keeping the read latencies neck-to-neck against B+ trees. Worth checking out: https://github.com/dgraph-io/badger
Re: Design Review: Key-Value Storage
#14Seems like an instance of reinventing the wheel ...
Curious comment. My reading of it is exactly the opposite of reinventing any wheels.
Re: Design Review: Key-Value Storage
#15Earlier quoted context omitted.
Also typically more complicated and require a separate compaction process. They're good for writing lots of data, but not so great for random reads.
Author of Badger here. Our design of separating keys and values has gotten us incredibly fast writes, while still keeping the read latencies neck-to-neck against B+ trees. Worth checking out: https://github.com/dgraph-io/badger
This looks very interesting. Do you have any builtin compression or tips on compressing data?
Re: Design Review: Key-Value Storage
#16Earlier quoted context omitted.
Also typically more complicated and require a separate compaction process. They're good for writing lots of data, but not so great for random reads.
Author of Badger here. Our design of separating keys and values has gotten us incredibly fast writes, while still keeping the read latencies neck-to-neck against B+ trees. Worth checking out: https://github.com/dgraph-io/badger
Badger is really good, i'm using it.
Re: Design Review: Key-Value Storage
#17This doc says LevelDB has no transacion, thats not true, they have batch writes and LEVEL-DB is not implemented in Go. Its implemented in CPP
Re: Design Review: Key-Value Storage
#18I thought that the issues like this would be blocking:
https://stackoverflow.com/questions/44407659/how-to-force-64...
Who knows how it should work on 32-bit systems?
And isn't endianess also a problem? And doesn't SQLite solve both problems by default? And isn't also possible to configure SQLite to be very fast, if one know what he's doing?
Btw I'd expected that the "notes here" https://docs.google.com/document/d/1bwbpqPb58a0GcEyB4W424pyf... are conclusions, but the document seems to be not publicly accessible.
Re: Design Review: Key-Value Storage
#19Bring back Mork! ducks
Mork actually sucked even as a key-value store. It's only decent if your requirements are a) only lookup on a fixed, autoincrement integer ID, b) the only operation you're likely to do is load an entire record or store an entire record at once, and c) parallelism is not in your vocabulary. Disclaimer: I'm one of the last people to make functional changes to mork.
That's not a "Disclaimer". It's actually the polar opposite... a "Claimer"? ... I think "Source" is the best word to use there.
Re: Design Review: Key-Value Storage
#20Earlier quoted context omitted.
Also typically more complicated and require a separate compaction process. They're good for writing lots of data, but not so great for random reads.
Author of Badger here. Our design of separating keys and values has gotten us incredibly fast writes, while still keeping the read latencies neck-to-neck against B+ trees. Worth checking out: https://github.com/dgraph-io/badger
“Please note that Badger obtains a lock on the directories so multiple processes cannot open the same database at the same time.”
With RocksDB there is not such limitation. Do you plan to lift it?