Pebble: A RocksDB Inspired Key-Value Store Written in Go
cockroachlabs.com
Pebble: A RocksDB Inspired Key-Value Store Written in Go
1–10 of 84 posts
Re: Pebble: A RocksDB Inspired Key-Value Store Written in Go
#2Was anyone else deeply saddened about three words into the headline, on realizing this wasn't a watch? (RIP)
Re: Pebble: A RocksDB Inspired Key-Value Store Written in Go
#3So 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 they are going about randomized crash testing:
> The random series of operations also includes a “restart” operation. When a “restart” operation is encountered, any data that has been written to the OS but not “synced” is discarded. Achieving this discard behavior was relatively straightforward because all filesystem operations in Pebble are performed through a filesystem interface. We merely had to add a new implementation of this interface which buffered unsynced data and discarded this buffered data when a “restart” occurred.
but this seems to only scratch the surface of possibilities that can come up with a crash. For example, it's possible the filesystem had synced some of the buffered data to disk, but not all of it. There's no guarantee about what buffered data was synced to disk. All you know is that some, all, or none of it made it to disk.
Bugs in this area are still regularly found in e.g. Postgres, so I'm having a hard time seeing how Coackroach is making sure Pebble doesn't have similar problems.
Re: Pebble: A RocksDB Inspired Key-Value Store Written in Go
#4So 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.
Re: Pebble: A RocksDB Inspired Key-Value Store Written in Go
#5As 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.
Re: Pebble: A RocksDB Inspired Key-Value Store Written in Go
#6How does this compare to Badger[0], another similar in nature key-value store in Go?
What were the trade-offs which made it necessary to create something new instead of adapting what exists?
Re: Pebble: A RocksDB Inspired Key-Value Store Written in Go
#7So 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…
Fewer features and fewer lines of code, and those LOC are written in Go, which is the language in which CockroachDB is written and which, presumably, for which their team and tooling are best optimized. It's a reasonable thesis.
Re: Pebble: A RocksDB Inspired Key-Value Store Written in Go
#8How does this compare to Badger[0], another similar in nature key-value store in Go? What were the trade-offs which made it necessary to create something new instead of adapting what exists? [0]: https://github.com/dgraph-io/badger
from the article:
"A final alternative would be to use another storage engine, such as Badger or BoltDB (if we wanted to stick with Go). This alternative was not seriously considered for several reasons. These storage engines do not provide all the features we require, so we would have needed to make significant enhancements to them. ... Lastly, various RocksDB-isms have slipped into the CockroachDB code base, such as the use of the sstable format for sending snapshots of data between nodes. Removing these RocksDB-isms, or providing adapters, would either be a large engineering effort, or impose unacceptable performance overhead. "
Re: Pebble: A RocksDB Inspired Key-Value Store Written in Go
#9Really enjoyed reading this, thanks.
Would be interested to see if the garbage collector has presented any problems when running in production
Re: Pebble: A RocksDB Inspired Key-Value Store Written in Go
#10As 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.
They mention in the article that it's mostly due to familiarity with Go:
> CockroachDB is primarily a Go code base, and the Cockroach Labs engineers have developed broad expertise in Go.