rystsov

8 ms·

31.
by rystsov 10y ago
I described it in this post http://rystsov.info/2015/09/16/how-paxos-works.html With single-decree Paxos you can write a storage which provides the following API: function changeQuery(key, change, query) { va
32.
by rystsov 10y ago
Assuming linearity is atomic multi-key updates: 1. There are tasks which don't require atomic multi-key updates 2. Atomic multi-key updates can be implemented on the client side (see RAMP, Percolator transactions or the Saga pattern) 3
33.
by rystsov 10y ago
> cannot start a paxos instance for a new log entry until all prior instances have been resolved It's wrong. In Grydka (Single-decree Paxos) all the keys are independent so it's possible to update them at the same time without
34.
by rystsov 10y ago
It can screw only to the worse side so I don't care about the true results as long as the lower bound is sufficient enough.
35.
by rystsov 10y ago
Yes that's true if all the communication between agents goes through the database then the Monotonic Reads consistency level is equivalent to linearizability. In case there are off the database communications then this level of consist
36.
by rystsov 10y ago
Thank you! I'll rework this paragraph to be correct, I wanted to make an observation that the given data (two attempts to implement key-value storages with keeping the length of a program as short as possible) favour Gryadka but of cou
37.
by rystsov 10y ago
It would still lack "Consistent get operations", "Paxos group changes", be "bound to localhost" and do more than 1 round trip to commit. What do you mean by pipelining?
38.
by rystsov 10y ago
Making implicit assumptions about the environment is wrong. An instance may be running in virtual environment where time freezes are possible. A human may make an error and rollback time to 1970. It's impossible to eliminate all these
39.
by rystsov 10y ago
Gryadka is less than 500 but supports membership change :) yet 3 hours on it is quite impressive
40.
by rystsov 10y ago
> If you have one paxos/raft group per replica, you actually only get a small unavailability It isn't a small unavailability, it's an unavailability of the whole replica. If you don't have a lot of data then it's
41.
by rystsov 10y ago
I don't have a deep understanding of how ZAB works but based on the documentation (initLimit) and prior experience with ZooKeeper, ZAB has the same issues as Raft when a leader dies. Folk from Elastifile demonstrated it in their Bizur
42.
by rystsov 10y ago
Etcd used this scheme to provide fast reads but Aphyr demonstrated that it may lead to stale reads https://github.com/coreos/etcd/issues/741 . If you can't afford stale reads then you should ask Etcd to w
43.
by rystsov 10y ago
> consistent reads do not need a living master It's wrong. If you're fine with stale reads then you don't a living master, but if you want to have a guarantee that the read value is up-to-date then the living master is nec
44.
by rystsov 10y ago
Btw, Gryadka uses an idea of quorums with non-standard size to change a configuration of the cluster, see http://rystsov.info/2016/01/05/raft-paxos.html#details1 . I came up with this idea independently of How
45.
by rystsov 10y ago
What is the performance penalty you're talking about? Gryadka does 1 roundtrip to write a value and its performance (4720 rps, 1.68ms latency) is very similar to Etcd (5227 rps, 1.55ms).
46.
by rystsov 10y ago
Thanks, I didn't notice that the clients operate over the same key set, so I didn't think about the contention. It makes sense.
47.
by rystsov 10y ago
Not really :) Please follow the links. "Paxos Made Simple" describes the write once variant, but it's possible to choose a new value for the next ballot cycles to make it rewritable. Proof of the algorithm: http://
48.
by rystsov 10y ago
> If you can sacrifice more, you can get Single Paxos What do you mean? Single Decree Paxos is linearizable so it's consistent. When the multi-key updates are necessary - they can be implemented with client-side transactions such as
49.
by rystsov 10y ago
The paper is quite important - it's the first paper about the production usage of an algorithm similar to Single-Decree Paxos. 1) The atomicity usually isn't a problem, it can be added on top of the sharded storage with 2PC, RAMP
50.
by rystsov 10y ago
I got it, I was using Etcd v3.1.0 but with v2 API.
51.
by rystsov 10y ago
> Paxos-like algorithms which are used by existing distributed file systems, can have artificial contention points due to their dependence on a distributed log. It's half true. Paxos is an ambiguous term. It includes Multi-Paxos and
52.
by rystsov 10y ago
I mean that without the ?quorum flag the stale reads are possible. I tested the etcd v3 (http api) and the reads were incredibly fast but when I set the flag, the read's latency became the same as write.
53.
by rystsov 10y ago
What do you call by "queue depth". Is it the number of concurrent clients? If it's true then it looks very suspicious that avg. latency decreases as the number of concurrent clients goes up. How do you measure avg. latency? L
54.
by rystsov 10y ago
> We avoided reads (get operations) since the current version of etcd performs reads directly from the leader, without contacting the cluster, which doesn’t preserve the same consistency level as Bizur and ZooKeeper do. It's wrong.
55.
In search of a simple consensus algorithm(rystsov.info)
9 points by rystsov 10y ago|0 comments
56.
by rystsov 10y ago
Will you release binaries or it's gonna be a pure cloud solution like DocumentDB or DynamoDB?
57.
by rystsov 10y ago
Even if we focus on 120k writes and ignore the low transaction number then it's still an average result. They use c3.4xlarge to run 5 shards each with 3 replication factor. It's 1500 writes per core (120k / (5*16)). Etcd easi
58.
by rystsov 10y ago
With the cloud version, it's impossible to run jepsen-like tests to validate consistency and to observe cluster's behavior when the network is unstable and nodes tend to crush.
59.
by rystsov 10y ago
Is it possible to download fauna to play with it on my own?
60.
by rystsov 10y ago
Dura means fool (feminine gender) in Russian :)

More ›