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

31–40 of 84 posts

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

#31

Post by jasonwatkinspdx »

petermattis wrote: post #23
malisper wrote: post #3

So 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…

> So 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 Cockroach is the only company using Pebble. We're only worried abou…

> The filesystem does provide guarantees when you use fsync() and fdatasync(). Postgres relies on these guarantees. So does RocksDB. Pebble's usage of fsync/fdatasync mirrors RocksDB's. Our crash testing is not testing the filesystem guarantees, only that we're correctly using fsync/fdatasync (which is hard enough to get right).

For anyone unfamiliar, fsync/fdatasync are infamous for all sorts of subtle sharp edges: https://www.usenix.org/conference/atc20/presentation/rebello

Having synchronous replication via paxos/raft can mitigate a lot of this.

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

#32

Post by jasonzemos »

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-a-time per thread? I'm genuinely curious how this all translates into Go's M:N coroutine model currently and moving forward with Pebble.

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

#33

Post by dfee »

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’d be concerned mainstream adoption might suffer. For example, I’d expect a hypothetical JsSql (a SQL engine written in JavaScript - assuming this doesn’t already exist) would achieve lower general adoption than writing it in C++.

Get it?

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

#34

Post by strken »

pdpi wrote: post #20
d--b wrote: post #4

Earlier quoted context omitted.

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.

Avoiding cgo would be a selling point for anyone else using go. Presumably other pure go kv stores like bbolt/badger/goleveldb would also solve that problem, but I don't know enough about them to understand the trade-offs.

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

#35

Post by mateus_amin »

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 wonder the same thing. I have not programed a DB but..

I would think the worst thing to program in a gc'd language would be the cache. So, if you write that layer of the database separately in a non-gc'd you would avoid most of the headache.

EDIT: I read the parent comment as why program a db in a gc language. I think the new wave 1st gen db's are doing alot of novel things. Minus the cache I imagine the velocity improvements form the 'simpler' language makes sense. Key value stores are become well trod ground however.

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

#36

Post by blaisio »

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.

It has to be written in Go because Cockroachdb is written in Go.

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

#38

Post by petermattis »

jasonwatkinspdx wrote: post #31
petermattis wrote: post #23

Earlier quoted context omitted.

> So 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 Cockroach is the only company using Pebble. We're only worried abou…

> The filesystem does provide guarantees when you use fsync() and fdatasync(). Postgres relies on these guarantees. So does RocksDB. Pebble's usage of fsync/fdatasync mirrors RocksDB's. Our crash testing is not testing the filesystem guarantees, only that we're correctly using fsync/fdatasync (which is hard enough to get right). For anyone unfamiliar, fsync/fdatasync are infamous for all sorts of subtle sharp edges:…

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 were in the process of being written are discarded. The WAL an MANIFEST (which lists the current sstables) are truncated at the first sign of data corruption. Getting all of this right definitely takes time and effort.

From the Rebello paper: > However, on restart, since the log entry is in the page cache, LevelDB includes it while creating an SSTable from the log file.

Pebble and RocksDB both inherited this behavior. The nuance here is that the sstable is then synced to disk and no reads are served until the sync is successful. If the machine were to crash before the sstable was synced, upon restart we'd rollback to the durable prefix of the log.

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

#39

Post by johncolanduoni »

nhumrich wrote: post #37

> written in go Why does the implementation language matter for non-library tool? Is that its only selling point?

It’s not a network-connected key value store so you need to interact with it from Go. That makes a pretty big difference.

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

#40

Post by ryanworl »

petermattis wrote: post #38
jasonwatkinspdx wrote: post #31

Earlier quoted context omitted.

> The filesystem does provide guarantees when you use fsync() and fdatasync(). Postgres relies on these guarantees. So does RocksDB. Pebble's usage of fsync/fdatasync mirrors RocksDB's. Our crash testing is not testing the filesystem guarantees, only that we're correctly using fsync/fdatasync (which is hard enough to get right). For anyone unfamiliar, fsync/fdatasync are infamous for all sorts of subtle sharp edges:…

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?
Post reply on HN