abadid

8 ms·

31.
by abadid 8y ago
What you say is correct :)
32.
by abadid 8y ago
I think I misunderstood what you were saying. By "available" I mean that the version exists at the time of the read. As far as available wrt failure, this is no different than any other system. If you don't synchronously repl
33.
by abadid 8y ago
2PC requires two network round trips and a global synchronization point. Plus it has the blocking problem and the cloggage problem described in the blog post. The first read of OLLP is before the first lock is acquired, so it doesn't r
34.
by abadid 8y ago
OLLP by itself is not guaranteed to make progress, but it is easy to prevent starvation via exerting more control at the preprocessing layer. The three papers to read related to this subject are: (1) http://www.cs.umd.edu/~a
35.
by abadid 8y ago
This requires a longer response that I have time write now. Please check back tomorrow night ...
36.
by abadid 8y ago
Unfortunately 3PC exacerbates the performance problems of 2PC.
37.
by abadid 8y ago
Yes, but it is possible to architect the system such that Y_i is available.
38.
by abadid 8y ago
I wasn't intending for it to be part of a series, but I agree that the OLLP technique may be of interest to a general audience and therefore a good subject for a future post.
39.
by abadid 8y ago
The assumption is that the data partitions are disjoint. Each worker controls its own data and therefore controls what value the other workers see. So the worker is responsible for making sure the other workers read the correct version.
40.
by abadid 8y ago
What you said is one reasonable way to accomplish what is stated in the post. There are other alternatives (described in the links from the post), but your way would work fine.
41.
by abadid 8y ago
Please see discussion thread: https://news.ycombinator.com/item?id=19000711 (remote reads instead of data duplication)
42.
by abadid 8y ago
I understood and agree with all of your stated assumptions. However, I didn't follow your naive implementation. I would definitely caution against using a coordinator.
43.
by abadid 8y ago
They don't need to be persisted at the received side, but yes, there could be 9 remote reads if each of 10 shards are running code that may result in state-based aborts. Usually, however, only a subset of the shards run such code. But
44.
by abadid 8y ago
There is no separate snapshot system. Each partition just maintains multiple versions of all data it stores locally.
45.
by abadid 8y ago
To clarify a couple of things: (1) Calvin does support dependent transactions (it uses OLLP to support them. (2) Calvin is just one example of a system that disallows arbitrary aborts. We've built a bunch of them in my lab. (3) I do no
46.
by abadid 8y ago
On A: temp = remote read of y; if (temp >=1 && x >= 1) A.x = A.x - 1; On B: temp = remote read of x; if (temp >=1 && y >= 1) B.y = B.y - 1; I simplified the code a little by checking on the old value of
47.
by abadid 8y ago
Multi-versioned systems can read from a snapshot at negligible complexity (just read the correct version).
48.
by abadid 8y ago
Please see the section entitled: "Removing system-induced aborts".
49.
by abadid 8y ago
No. Each process is independently checking the value of a non-changing snapshot of the state of the input data and we therefore do not run into the impossibility result.
50.
by abadid 8y ago
I should have made this point clearer in the post. 2PC requires 2 round trip messages per worker (i.e. 4 total messages per worker), of which the 3rd message cannot be sent until there is a global synchronization point. The proposal replace
51.
by abadid 8y ago
It would be hand-waving if we didn't actually do it :) Calvin uses a locking scheme with deadlock avoidance. PVW uses a MVCC scheme with no locking (and therefore no deadlock). Fauna uses an OCC scheme with no deadlock and deterministi
52.
by abadid 8y ago
Think of it this way: category (1) are transaction aborts that are dependent on the state of the data. If so, you can explicitly include conditional logic on that data state. The mechanism for accomplishing category (2) is described in the
53.
by abadid 8y ago
Yes, that's what I refer to as "unified consensus". Batching helps to overcome the scalability challenges (i.e. order batches rather than each individual xact). I talk about this briefly at: http://dbmsmusings.blog
54.
by abadid 8y ago
Please, please read the Calvin paper http://www.cs.umd.edu/~abadi/papers/calvin-sigmod12.pdf . The assumption that Calvin serializes cross-partition transactions is a common misunderstanding is 100% inaccurate. The
55.
by abadid 8y ago
I have not worked with NDB, nor read any research papers or documentation about it. So that's why I didn't have it in mind when I wrote that post. But I'm a little confused by your comment: How is it possible to partition con
56.
by abadid 8y ago
Looks like you cross-posted this comment here and on my blog, so I'll also cross-post in my response. I am quite confused by your statement that YugaByte does not claim linearizability. The C of CAP is linearizability (see the original
57.
by abadid 8y ago
Spanner's approach requires help from hardware and several full time employees maintaining and ensuring the uncertainty guarantees. This increases the cost of the maintaining the system, which for Cloud Spanner is partially passed on t
58.
by abadid 8y ago
The two approaches seem mutually exclusive to me.
59.
by abadid 8y ago
Or just use global consensus with batching and avoid the need for clock synchronization altogether!
60.
by abadid 8y ago
That post was actually quite different than this one. This one focuses on distributed vs. global consensus. But I added a note at the end that clearly documents my connection to FaunaDB. As far as Calvin, the post itself clearly says that i

More ›