Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Pebble: A RocksDB Inspired Key-Value Store Written in Go

cockroachlabs.com

Post reply on HN
Print view View original

41–50 of 84 posts

Re: Pebble: A RocksDB Inspired Key-Value Store Written in Go

#41

Post by petermattis »

jasonzemos wrote: post #32

Concurrency and multithreading are a major focus of both Go and RocksDB. This introduction makes little mention of those areas, and I'm curious if there's any more to be said on this. The article lists several features being reimplemented, including: > Basic operations: Set, Get, Merge, Delete, Single Delete, Range Delete It makes no mention of RocksDB's MultiGet/MultiRead -- is CockroachDB/Pebble limited to query-at…

Pebble does not currently implement MultiGet as CockroachDB did not use RocksDB's MultiGet operation. CockroachDB can use multiple nodes to process a query by decomposing SQL queries along data boundaries and shipping the query parts to be executed next to the data. CockroachDB can't directly use MultiGet because that API was not compatible with how CockroachDB reads keys.

RocksDB MultiGet is interesting. Parallelism is achieved by using new IO interfaces (io_uring), not by using threads. That approach seems right to me. See https://github.com/facebook/rocksdb/wiki/MultiGet-Performanc.... My understanding is that io_uring support is still a work in progress. We experimented at one point with using goroutines in Pebble to parallelize lookups, but doing so was strictly worse for performance. Experimenting with io_uring is something we'd like to do.

Re: Pebble: A RocksDB Inspired Key-Value Store Written in Go

#42

Post by FridgeSeal »

AtlasBarfed wrote: post #27

Why would someone remove a non-GC database engine with a database engine with GC? Has Go evolved better low-GC features? As I understand Go GC vs JVM GC, Go avoids major GC by simply pushing it to the future and consuming memory more readily. But a database is a long-running program, so you have to pay the piper eventually.

I’d also be curious why they didn’t go with something like Foundation DB either.

Re: Pebble: A RocksDB Inspired Key-Value Store Written in Go

#43

Post by tonetheman »

AtlasBarfed wrote: post #27

Why would someone remove a non-GC database engine with a database engine with GC? Has Go evolved better low-GC features? As I understand Go GC vs JVM GC, Go avoids major GC by simply pushing it to the future and consuming memory more readily. But a database is a long-running program, so you have to pay the piper eventually.

I have had long running Java programs and their memory usage if done correctly is a nice saw tooth. As long as you are not leaking you can run a well written Java server for long long periods of time (months) without a bounce.

If you are leaking not so much. :)

Re: Pebble: A RocksDB Inspired Key-Value Store Written in Go

#44

Post by petermattis »

fis wrote: post #29

The name is a little close to this existing LevelDB fork, maybe consider a different name? https://github.com/utsaslab/pebblesdb

Damned for using a unique name (CockroachDB), and damned for using an innocuous one.

PS PebblesDB was a research project and is dead as far as I know.

Re: Pebble: A RocksDB Inspired Key-Value Store Written in Go

#45

Post by petermattis »

ryanworl wrote: post #40
petermattis wrote: post #38

Earlier quoted context omitted.

As far as I'm aware, the fsync/fdatasync sharp edges are around what happens after an fsync/fdatasync failure. My understanding is that you can't rely on anything. The only sane option is to crash the process and attempt recovery on restart. Even that is fraught because data can be in the OS cache but not synced to disk. Pebble (and RocksDB) both take a fairly pessimistic view of what can be recovered. Sstables that…

Have you considered using direct IO for the log?

Yes. So far performance was worse in experiments, and the durability improvements are questionable because it is extremely difficult to get a clear understanding of the durability semantics of direct IO. If you can find a pointer to clear documentation of what those semantics are I'd be extremely interested in reading it.

Re: Pebble: A RocksDB Inspired Key-Value Store Written in Go

#46

Post by petermattis »

FridgeSeal wrote: post #42
AtlasBarfed wrote: post #27

Why would someone remove a non-GC database engine with a database engine with GC? Has Go evolved better low-GC features? As I understand Go GC vs JVM GC, Go avoids major GC by simply pushing it to the future and consuming memory more readily. But a database is a long-running program, so you have to pay the piper eventually.

I’d also be curious why they didn’t go with something like Foundation DB either.

Pebble and FoundationDB are apples and oranges. Pebble is per-node KV storage engine. FoundationDB is a distributed multi-modal database. Internally, FoundationDB uses a library like Pebble for the per-node data storage. I think at one point it used SQLite. I'm not up to date on what it currently use. I seem to recall FoundationDB was writing their own btree-based node-level storage engine to replace the usage of SQLite.

The equivalent of FoundationDB is present inside of CockroachDB: a distributed, replicated, transactional, KV layer. This is where a big chunk of CockroachDB value resides. This is where our use of Raft resides. Pebble lies underneath this.

Re: Pebble: A RocksDB Inspired Key-Value Store Written in Go

#47

Post by pkaye »

dfee wrote: post #33
dfee wrote: post #5

As 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.

I really don’t understand the downvotes. I’m not experienced with either language - and this has nothing to do with a flame war. The question, unstated and unopinionated AND intellectually honest was: does language impact community adoption - and if so, what are the drivers behind it. If I were going to write a foundational technology, I probably wouldn’t write it in NodeJS, not that it couldn’t be done, but because…

Their main product is in Go so they are most familiar with it.

Re: Pebble: A RocksDB Inspired Key-Value Store Written in Go

#48

Post by ohnoesjmr »

cube2222 wrote: post #6

How 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

Badger is written by mad people from my point of view, who disabled issues on github, from my understanding declared it as "done" and "bug free", and any issue tracking is now done on the forum where the threads roll off to the void with no further trace.

Re: Pebble: A RocksDB Inspired Key-Value Store Written in Go

#49

Post by brokencode »

dfee wrote: post #33
dfee wrote: post #5

As 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.

I really don’t understand the downvotes. I’m not experienced with either language - and this has nothing to do with a flame war. The question, unstated and unopinionated AND intellectually honest was: does language impact community adoption - and if so, what are the drivers behind it. If I were going to write a foundational technology, I probably wouldn’t write it in NodeJS, not that it couldn’t be done, but because…

I don’t think Cockroach cares about adoption. This is not meant to be a generally useful product in itself outside of their database. So the language was chosen mainly based on their familiarity with Go and its ability to integrate with their existing codebase.

I think their omission of major features such as transactions is more likely to limit adoption than the language choice, so language choice is kind of irrelevant from that perspective.

Re: Pebble: A RocksDB Inspired Key-Value Store Written in Go

#50

Post by ryanworl »

petermattis wrote: post #46
FridgeSeal wrote: post #42

Earlier quoted context omitted.

I’d also be curious why they didn’t go with something like Foundation DB either.

Pebble and FoundationDB are apples and oranges. Pebble is per-node KV storage engine. FoundationDB is a distributed multi-modal database. Internally, FoundationDB uses a library like Pebble for the per-node data storage. I think at one point it used SQLite. I'm not up to date on what it currently use. I seem to recall FoundationDB was writing their own btree-based node-level storage engine to replace the usage of SQL…

The current production storage engine is an old-ish version of the SQLite btree. A new btree engine is being written now and is available but I don’t know if it is being used in production anywhere.

RocksDB is shipping soon thanks to some work by members of the community.

Post reply on HN