Really enjoyed reading this, thanks. Would be interested to see if the garbage collector has presented any problems when running in production
There's some notes on that here: https://github.com/cockroachdb/pebble/blob/c39589c8cb36d95df...
Pebble: A RocksDB Inspired Key-Value Store Written in Go
11–20 of 84 posts
Re: Pebble: A RocksDB Inspired Key-Value Store Written in Go
#12Thought it would be worth mentioning Sled as an alternative to RocksDB for the Rust crowd:
Re: Pebble: A RocksDB Inspired Key-Value Store Written in Go
#13Not to be confused with Let's Encrypt's ACME client testing CA server project (the "scaled down" version of Boulder), Pebble: https://github.com/letsencrypt/pebble
Re: Pebble: A RocksDB Inspired Key-Value Store Written in Go
#14Really enjoyed reading this, thanks. Would be interested to see if the garbage collector has presented any problems when running in production
There's some notes on that here: https://github.com/cockroachdb/pebble/blob/c39589c8cb36d95df...
The TLDR is that the GC did cause problems so we had to avoid it for the block cache. Luckily we were able to do so without exposing the complexity in the API. Not for the faint of heart. Don't try this at home kids.
Re: Pebble: A RocksDB Inspired Key-Value Store Written in Go
#15So I understand the rationale for writing your own storage layer and think this is an awesome project, but there's something missing for me. One of the issues Peter brings up is they've come across a number of serious bugs in RocksDB. My question is, why would Pebble have less bugs. In fact, I would expect it to have significantly more bugs because Coackroach is the only company using Pebble. They mention briefly how…
Hi, I'm on the team that works on Pebble. Partially synced WAL records are easier to detect, as they would just appear as corrupt records and we can stop WAL replay at that point. Non-WAL writes are even easier to handle as SSTable files are immutable once fully written and synced. We rely pretty heavily on fsync/fdatasync calls to guarantee that "all" the data in a given range made it.
In addition to randomized crash tests, we have a suite of end-to-end integration tests on top of Cockroach, called Roachtests, that put clusters under a combination of node crash/restart scenarios and confirm data consistency.
Re: Pebble: A RocksDB Inspired Key-Value Store Written in Go
#16So I understand the rationale for writing your own storage layer and think this is an awesome project, but there's something missing for me. One of the issues Peter brings up is they've come across a number of serious bugs in RocksDB. My question is, why would Pebble have less bugs. In fact, I would expect it to have significantly more bugs because Coackroach is the only company using Pebble. They mention briefly how…
Well, I think what they're saying is that they'd rather have bugs in code they've written than in code that is written by other people and in another language, and for which they don't control the patching pipeline. If RocksDB had had no bugs, they wouldn't have needed to write Pebble.
I'm sure 'not have to cross the cgo boundary' is significant when debugging, as well.
Re: Pebble: A RocksDB Inspired Key-Value Store Written in Go
#17As a consumer, why would I want something like this written in Go vs. Rust? Is it just that Rust is really good with developer relations? Because it feels like to me that all new foundational technology is safer and faster in a language like Rust, and things written in Go should be higher up the food chain.
Because you already have a huge Go code base and you want an embedded kv db for your project?
Re: Pebble: A RocksDB Inspired Key-Value Store Written in Go
#18As a consumer, why would I want something like this written in Go vs. Rust? Is it just that Rust is really good with developer relations? Because it feels like to me that all new foundational technology is safer and faster in a language like Rust, and things written in Go should be higher up the food chain.
This is not a standalone DB. Its a key-value store implemented as a library. You would want this if you were a Go developer working on an application that needed a built in key-value store.
If you were a Rust developer you'd want something similar written in Rust.
Re: Pebble: A RocksDB Inspired Key-Value Store Written in Go
#19This makes total sense for Cockroach Labs, and I trust their engineering ability to get it right.
Re: Pebble: A RocksDB Inspired Key-Value Store Written in Go
#20So I understand the rationale for writing your own storage layer and think this is an awesome project, but there's something missing for me. One of the issues Peter brings up is they've come across a number of serious bugs in RocksDB. My question is, why would Pebble have less bugs. In fact, I would expect it to have significantly more bugs because Coackroach is the only company using Pebble. They mention briefly how…
Well, I think what they're saying is that they'd rather have bugs in code they've written than in code that is written by other people and in another language, and for which they don't control the patching pipeline. If RocksDB had had no bugs, they wouldn't have needed to write Pebble.
That's an argument for them using it, but it's also basically arguing why nobody else should.