Live data from Hacker News

IceFireDB: Distributed disk storage database based on Raft and Redis protocol

github.com

41–50 of 71 posts

Re: IceFireDB: Distributed disk storage database based on Raft and Redis protocol

#41

Quasi-related: what are some good hosted alternatives to AWS dynamodb / GCloud Firestore that are a) fast b) affordable at scale c) have a good local dev experience? A hosted disk based redis protocol compliant capable of sub TB size datasets would be a dream for me.

Cloudflare Workers KV is really promising, but needs a better local dev story (no stable project so simulate services locally e.g. cloudworkers). Pricing is reasonable depending on what you interpret "scale" to be.

Re: IceFireDB: Distributed disk storage database based on Raft and Redis protocol

#42
post #16

Earlier quoted context omitted.

Typically people use raft for leader election which in turn can coordinate writes. I don't think the writes are being fsync'd in the raft logs here. At least I wouldn't expect that behavior.

Each write should be fsync'd to the WAL, right?

Yes but those can happen at the convenience of the particular node, not necessarily as a globally chrckpointed fsync()

Re: IceFireDB: Distributed disk storage database based on Raft and Redis protocol

#43

Earlier quoted context omitted.

Each write should be fsync'd to the WAL, right?

Yes but those can happen at the convenience of the particular node, not necessarily as a globally chrckpointed fsync()

Then you're sacrificing consistency guarantees. If less than a majority have committed a write, it could be lost while the cluster still has a quorum up.

Waiting to report success until a majority have committed allows you to make guarantees with a straight face.. "it will probably be committed in the near future" is not the same thing.

Re: IceFireDB: Distributed disk storage database based on Raft and Redis protocol

#46
post #25

Earlier quoted context omitted.

We use consul a bit as some "light" service discovery and a KV store for a few things without much issue so far. What demons did you encounter with vault/consul?

We had some massive problems including complete cluster collapse requiring rebuilds from scratch, eternal leadership elections and occasionally nodes would just entirely stop responding to KV requests causing cascading failures outside. Vault is a massive damage multiplier for these issues plus some other nasty ones like buggy barely supported plugins.

Wouldn't mind knowing what versions you were using/how long ago this was. We haven't seen anything like this in > 3 years. Possible a barely supported plugin caused issues?

Re: IceFireDB: Distributed disk storage database based on Raft and Redis protocol

#47
post #33

Earlier quoted context omitted.

Look higher up the problem domain and solve it without requiring a consensus protocol.

Hmm, how do you have high availability consistent data without a consensus protocol? No matter where in the problem chain you move, you have to eventually solve that problem.

Easy you push the configuration to every target. Then they are logically consistent.

We did this for 30 years fine before someone invented this stack on deployments much larger then the average consul or vault deployment these days.

I had something running 15,000 dynamic rps on Apache about 15 years ago.

People are blinded from simplicity by complexity. Eventually complexity owns you. You can only own simplicity.

At the end of the day this is one way to solve a problem that doesn’t need to be solved that someone has convinced you is a problem.

Re: IceFireDB: Distributed disk storage database based on Raft and Redis protocol

#48
post #25

Earlier quoted context omitted.

We had some massive problems including complete cluster collapse requiring rebuilds from scratch, eternal leadership elections and occasionally nodes would just entirely stop responding to KV requests causing cascading failures outside. Vault is a massive damage multiplier for these issues plus some other nasty ones like buggy barely supported plugins.

Wouldn't mind knowing what versions you were using/how long ago this was. We haven't seen anything like this in > 3 years. Possible a barely supported plugin caused issues?

This is post 1.0 and without any plugins for consul. Vault has been a persistent point of failure.

It’s a good idea in principle but it’s not got a good ROI

Re: IceFireDB: Distributed disk storage database based on Raft and Redis protocol

#49
post #47

Earlier quoted context omitted.

Hmm, how do you have high availability consistent data without a consensus protocol? No matter where in the problem chain you move, you have to eventually solve that problem.

Easy you push the configuration to every target. Then they are logically consistent. We did this for 30 years fine before someone invented this stack on deployments much larger then the average consul or vault deployment these days. I had something running 15,000 dynamic rps on Apache about 15 years ago. People are blinded from simplicity by complexity. Eventually complexity owns you. You can only own simplicity. At…

>Easy you push the configuration to every target. Then they are logically consistent.

What does this mean? This doesn't mean anything?

Are you saying to push the DB to the client?

Re: IceFireDB: Distributed disk storage database based on Raft and Redis protocol

#50
post #47

Earlier quoted context omitted.

Hmm, how do you have high availability consistent data without a consensus protocol? No matter where in the problem chain you move, you have to eventually solve that problem.

Easy you push the configuration to every target. Then they are logically consistent. We did this for 30 years fine before someone invented this stack on deployments much larger then the average consul or vault deployment these days. I had something running 15,000 dynamic rps on Apache about 15 years ago. People are blinded from simplicity by complexity. Eventually complexity owns you. You can only own simplicity. At…

People need distributed consistent data for a lot of things besides configuration.
Post reply on HN