21–30 of 71 posts
Not quite sure what this is supposed to be good for.
I'd guess for "I want redis, but more durable clustering" (although I don't quite remember how much redis nowadays offers there itself). Would want a lot more info before trusting it for that though.
A 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.
Source: several years dealing with vault and consul.
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.
A 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.
It uses Raft underneath as well which means there's a bunch of non-determinism and hell for anyone who invokes it as well from experience. The thing is cursed. Source: several years dealing with vault and consul.
What demons did you encounter with vault/consul?
Earlier quoted context omitted.
It uses Raft underneath as well which means there's a bunch of non-determinism and hell for anyone who invokes it as well from experience. The thing is cursed. Source: several years dealing with vault and consul.
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?
A 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.
It uses Raft underneath as well which means there's a bunch of non-determinism and hell for anyone who invokes it as well from experience. The thing is cursed. Source: several years dealing with vault and consul.
SET: 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…
Things that can make a difference: Databases have subtly different definitions of "durability", so they aren't always doing semantically equivalent operations. Write throughput sometimes scales with the number of clients and it is not possible to saturate the server with a single client due to limitations of the client protocol, so single client benchmarks are misleading. Some databases allow read and write operations to be pipelined; in these implementations it is possible for write performance to sometimes exceed read performance.
For open source databases in particular, read and write throughput is significantly throttled by poor storage engine performance, so the ratio of read/write performance is almost arbitrary. That 3:1 ratio isn't a good heuristic because the absolute values in these cases could be much higher. A more optimal design would offer integer factor throughput improvements for both reading and writing, but it is difficult to estimate what the ratio "should" be on a given server absent a database engine that can really drive the hardware.
A 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.
It's less than a few hundred lines of Go that just wraps two other databases (syndtr/goleveldb and ledisdb/ledisdb) with a third library (tidwall/uhaha) that provides a Raft API.
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.
Earlier quoted context omitted.
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.