One of the child comments made the observation that "this speaks Redis." Makes me wonder if there is any spec for the Redis commands. I.e., in the same way that SQL defines an interface, but leaves the details up to individual implementations, is there a "Redis" interface that leaves the details up to the implementation? I'm thinking of something similar to ISO or RFC.
IceFireDB: Distributed disk storage database based on Raft and Redis protocol
11–20 of 71 posts
Re: IceFireDB: Distributed disk storage database based on Raft and Redis protocol
#12Earlier quoted context omitted.
It speaks Redis so ideally it can replace Redis in cases where persistence is required. There are already several community solutions for Redis persistence - this one provides different guarantees. The name implies the goal is to make it easy to mix "hot" (from memory) and "cold" (from disk) data. The author suggests this.
Redis itself already supports a number of persistence schemes and has since the beginning: https://redis.io/topics/persistence
That's a good point and I should have been clearer.
I might be off (and probably am) but if I remember correctly Redis persistence is more for disaster recovery - you can create snapshots and recover them or replay a log file. That's very different in terms of performance guarantees from persisting the data itself to disk and reading from it.
I was under the impression that's what tools (like this one) and stuff like Ardb try to solve.
Re: IceFireDB: Distributed disk storage database based on Raft and Redis protocol
#13One of the child comments made the observation that "this speaks Redis." Makes me wonder if there is any spec for the Redis commands. I.e., in the same way that SQL defines an interface, but leaves the details up to individual implementations, is there a "Redis" interface that leaves the details up to the implementation? I'm thinking of something similar to ISO or RFC.
I've implemented a subset of redis in the past, and went by their official docs, first the protocol[1] level protocol, then the docs for individual comments such as SET[2]. They also have a test suite, and I extracted the bits that applied to my partial implementation from there.
The only real pitfall was what part of the CONFIG stuff I needed to implement to make popular redis client libs talk to me and/or use the newer protocol features.
The rest was pretty straight forward, just read the docs for a command, implement the stuff, run the test suite, fix any bugs, repeat.
As far as I know there is no RFC let alone an ISO standard.
Re: IceFireDB: Distributed disk storage database based on Raft and Redis protocol
#14SET: 253232.12 requests per second GET: 2130875.50 requests per second The 10:1 throughput ratio for GET vs SET is interesting. Redis being in-memory, the rates there are pretty close to the same for read/write. Is a 10:1 ratio typical for a storage backed distributed kv store? Edit: Looks like CockroachDb has roughly a 3:1 ratio, similar for YugabyteDB: https://www.cockroachlabs.com/docs/stable/performance.html http…
> Is a 10:1 ratio typical for a storage backed distributed kv store?
In a single-node system, the best way to increase your write throughput is to batch requests over small chunks of time. Ultimately, the amount of writes you can perform per unit time is either bounded by the underlying I/O sequential throughput, or the business constraints regarding maximum allowable request latency. In the most trivial case, you are writing a buffer containing the entire day's work to disk in 1 shot while everyone sleeps. Imagine how fast that could be.
A distributed system has all of the same properties, but then you have to put this over a denominator that additionally factors in the number of nodes and the latency between all participants. A single node is always going to give you the most throughput when talking about 1 serial narrative of events wherein any degree of contention is expected.
Re: IceFireDB: Distributed disk storage database based on Raft and Redis protocol
#15A database without any test harness? While this could be a good toy or PoC I would never use it in production. Readers should be aware, just because it's on HN doesn't mean it's production ready.
Re: IceFireDB: Distributed disk storage database based on Raft and Redis protocol
#16SET: 253232.12 requests per second GET: 2130875.50 requests per second The 10:1 throughput ratio for GET vs SET is interesting. Redis being in-memory, the rates there are pretty close to the same for read/write. Is a 10:1 ratio typical for a storage backed distributed kv store? Edit: Looks like CockroachDb has roughly a 3:1 ratio, similar for YugabyteDB: https://www.cockroachlabs.com/docs/stable/performance.html http…
Raft involves waiting for fsync on a majority of nodes, so that's not too surprising. 'Typical' is a matter of what guarantees you want to give.
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.
Re: IceFireDB: Distributed disk storage database based on Raft and Redis protocol
#17Quasi-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.
Re: IceFireDB: Distributed disk storage database based on Raft and Redis protocol
#18Quasi-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.
I was surprised out how easy it was to get started with Cassandra on DataStax:
https://www.datastax.com/
Re: IceFireDB: Distributed disk storage database based on Raft and Redis protocol
#19Earlier quoted context omitted.
Redis itself already supports a number of persistence schemes and has since the beginning: https://redis.io/topics/persistence
That's a good point and I should have been clearer. I might be off (and probably am) but if I remember correctly Redis persistence is more for disaster recovery - you can create snapshots and recover them or replay a log file. That's very different in terms of performance guarantees from persisting the data itself to disk and reading from it. I was under the impression that's what tools (like this one) and stuff like…
Youre right. Redis will persist either the AOF or log but your whole dataset must fit in memory (the AOF file is used to fill existing memory on boot).
Re: IceFireDB: Distributed disk storage database based on Raft and Redis protocol
#20Earlier quoted context omitted.
Redis itself already supports a number of persistence schemes and has since the beginning: https://redis.io/topics/persistence
That's a good point and I should have been clearer. I might be off (and probably am) but if I remember correctly Redis persistence is more for disaster recovery - you can create snapshots and recover them or replay a log file. That's very different in terms of performance guarantees from persisting the data itself to disk and reading from it. I was under the impression that's what tools (like this one) and stuff like…
I wouldn't call it disaster recovery per se.
It's just that Redis is mostly an in-memory database and if the process is terminated and restarted (for all sorts of reasons) the data can be restored from disk.
So what IceFireDB might be good for is data which would not fit easily into the memory of one node.
Again, it's really not clear to me.