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

Jepsen: Redpanda 21.10.1

jepsen.io

Post reply on HN
Print view View original

1–10 of 61 posts

Re: Jepsen: Redpanda 21.10.1

#5

Post by CJefferson »

This isn't anything against Redpanda, but I'm always amazed how badly all these distributed databases do in Jepsen.

What would one use them for in practice, which wouldn't be better suitable by a (the thing I've used), say postgresql and streaming replication in case the server goes down? (I'm not suggesting there isn't a good application, just I'm not knowledgeable enough to know of one).

Re: Jepsen: Redpanda 21.10.1

#6

Post by claytonjy »

CJefferson wrote: post #5

This isn't anything against Redpanda, but I'm always amazed how badly all these distributed databases do in Jepsen. What would one use them for in practice, which wouldn't be better suitable by a (the thing I've used), say postgresql and streaming replication in case the server goes down? (I'm not suggesting there isn't a good application, just I'm not knowledgeable enough to know of one).

There's a lot of different ways to answer this, but I think about it as a different architectural paradigm. Yes you can do stream-ish things with Postgres but at some level of scale you'd be putting a square peg in a round hole.

What opened my eyes to this world is this post from Martin Kleppman on turning the database inside out: https://martin.kleppmann.com/2015/03/04/turning-the-database...

Re: Jepsen: Redpanda 21.10.1

#7

Post by agallego »

CJefferson wrote: post #5

This isn't anything against Redpanda, but I'm always amazed how badly all these distributed databases do in Jepsen. What would one use them for in practice, which wouldn't be better suitable by a (the thing I've used), say postgresql and streaming replication in case the server goes down? (I'm not suggesting there isn't a good application, just I'm not knowledgeable enough to know of one).

totally different approaches tho. people have tried what you proposed many times before and for some scale succeeded. hard to compare at all when you dig into the details.

expect a companion post. this was super fun to partner with kyle on this. +1 would recommend to anyone building a storage system.

Re: Jepsen: Redpanda 21.10.1

#8

Post by belter »

mandevil wrote: post #4

I was unfamiliar with Redpanda, and now I know and trust it. Whatever marketing budget Redpanda spent to get a Jepsen report was well worth it.

Agree. Nowadays, I see anything that did not go through Jepsen with suspicion. Forces me to do the triple of technical due diligence.

Re: Jepsen: Redpanda 21.10.1

#9

Post by jeffbee »

dhshshdhdgfff wrote: post #3

The first half is jepsen team trying to divine some actual testable guarantees from a pile of blog posts and a random Google doc. What a mess.

Total mess. It’s a real indictment of Kafka, more than it is anything about redpanda in the first half.

Re: Jepsen: Redpanda 21.10.1

#10

Post by rystsov »

CJefferson wrote: post #5

This isn't anything against Redpanda, but I'm always amazed how badly all these distributed databases do in Jepsen. What would one use them for in practice, which wouldn't be better suitable by a (the thing I've used), say postgresql and streaming replication in case the server goes down? (I'm not suggesting there isn't a good application, just I'm not knowledgeable enough to know of one).

Different systems solve different problems and have different functional characteristics. Actually one of the thing which Kyle highlighted in his report is write cycles (G0 anomaly), it isn't a problem of the Redpanda implementation but a fundamental property of the Kafka protocol. Records in Kafka protocol don't have preconditions and they don't overwrite each other (unlike the database operations) so it doesn't make sense to enforce order on the transactions and it's possible to run them in parallel. It gives enormous performance benefits and doesn't compromise safety.
Post reply on HN