Y
HN Search
Hacker News Search
new
|
comments
|
top
|
jobs
pbailis
searching Neon…
1.
▲
2.
▲
3.
▲
4.
▲
5.
▲
6.
▲
6 ms
·
1.
▲
by
pbailis
3y ago
Macrobase PI here – someone squatted on that io domain a long time ago while the project was active. Once we moved to macrobase.stanford.edu, a fan apparently took interest in our old domain. Thanks Andy for updating the link.
2.
▲
by
pbailis
12y ago
> Hmm... Serializable isolation and concurrency go together fine and certainly don't require blocking or even locking when using MVCC and optimistic concurrency. For that matter serializable transactions and scalability are not inco
3.
▲
by
pbailis
13y ago
Very cool, thanks! In general, immutable data items makes NBTA much easier; there's only one element in either 'good' or 'pending' for each data item at a time. The benefit of a single centralized transactor/ID generator is that it provides
4.
▲
by
pbailis
13y ago
Good questions. In the example configuration in the post (i.e., two servers with no replication), during the period between the write start and end of phase two of writes, reads can return either value written (x=y=0 or x=y=1). If we want t
5.
▲
by
pbailis
13y ago
Ha--good catch! I don't know if anyone else noticed that. I meant to say "within 33-4.8% of the peak throughput..." That is, we're 95.2% of the peak, not 4.8% of the peak. Fixed, thanks!
6.
▲
by
pbailis
13y ago
Post author here. Interesting take, but I'm not sure I agree, or perhaps I misunderstand. In the initial example, I represented 'good' as a set for ease of understanding, but, in practice, unless a client specifically requests an older vers
7.
▲
by
pbailis
13y ago
Post author here. Hmm. The invariant we're trying to maintain is that any write in 'good' should have its transactional "siblings" in either 'good' or 'pending' on their respective servers. So if we are trying to write x=1 and y=1, then, if
8.
▲
by
pbailis
13y ago
Thanks for the feedback--these are great points. (post author, btw) > The problem to me seems to be that the interesting problems always come across the case where updates are not commutative. I agree that many application-level integri
9.
▲
by
pbailis
13y ago
(edit: post author, [not OP]) here. Thanks for the feedback! > I guess one of the key insights is that each data has a canonical server owner which enforces the consistency of the writes of the data at a single place. Well, this is the
10.
▲
by
pbailis
13y ago
I'll also add that the metadata requirements aren't huge--typically 8 bytes for the timestamp and N*(bytes per key) for the keys. In our implementation and the benchmarks that we provided, we don't garbage collect the metadata as it's small
11.
▲
by
pbailis
13y ago
Good questions! > Doesn't writes that commute mean that there was no contention to begin with? Ideally, if I have a balance of $100 in my account and try to spend $60 in two different transactions, one should come back as failed before
12.
▲
by
pbailis
13y ago
> Does the data remain stable, or must some additional work be performed to correct the inconsistent state? If you want client writes that reached all servers to become visible, then the servers will have to perform the move from 'pendi
13.
▲
by
pbailis
13y ago
> However it doesn't appear to directly include semantics for aborting transactions which is a pretty important part of a distributed transaction protocol. Yep, I left this out to avoid confusion at first. There are some details in the
14.
▲
by
pbailis
13y ago
Yep--thanks! I've updated the post accordingly :)
15.
▲
by
pbailis
13y ago
There's at least one good reason for Dynamo's write-to-all and read-from-all mechanism: latency. What you've called 'W=2' in Couchbase is "write to master and at least one slave." Dynamo-style 'W=2' means "write to any two replicas." This c
16.
▲
For Big Data, Moore’s Law means better decisions
(amplab.cs.berkeley.edu)
1 points
by
pbailis
14y ago
|
0 comments
17.
▲
by
pbailis
14y ago
> if I understand correctly there's no way to avoid an extra round trip? With HATs, you only need to contact one replica for every key. This is to goal behind our definition of "high availability" ( http://www.bailis.org/blog/hat-not-ca
18.
▲
by
pbailis
14y ago
Good point, and well-taken. As I mention in http://www.bailis.org/blog/hat-not-cap-introducing-highly-av... (and devote an full section to in the paper, including documented isolation anomalies like lost updates, write skew, and anti-depe
19.
▲
Hat, not CAP: Introducing Highly Available Transactions
(bailis.org)
65 points
by
pbailis
14y ago
|
8 comments
20.
▲
by
pbailis
14y ago
I think we're conflating Snapshot Isolation and MVCC (e.g., Snapshot-isolation/MVCC ). MVCC is a general concurrency control mechanism, not an isolation level. Coupling MVCC and Snapshot Isolation is like saying "using locks provides seria
21.
▲
by
pbailis
14y ago
there are still fairly hard guarantees about things like consistency that you get with other isolation levels What do you mean by consistency ? I agree that there are many ways to ensure that application integrity constraints are not vio
22.
▲
by
pbailis
14y ago
Good points on both sides. One thing I'll point out is that many clustering, HA, and multi-master replication solutions either rely on a single master (what I think Michael means when he says they're not distributed) or don't provide seria
23.
▲
by
pbailis
14y ago
Unlike "C" and "A" in "CAP," "AC&D" (specifically, "C") can't be easily separated from "I". Serializability ("I") ensures that database consistency, or maintenance of integrity constraints ("C"), is not violated. While it's possible to
24.
▲
When is "ACID" ACID? Rarely
(bailis.org)
63 points
by
pbailis
14y ago
|
31 comments
25.
▲
by
pbailis
14y ago
"Conflating the storage of data with how it is queried" is a misinformed criticism of the relational model. Codd's Relational Algebra (Turing Award material) was in large part a move towards data independence, relaxing what was previously a
26.
▲
by
pbailis
14y ago
If you look at the actual papers, they're all under CC BY-NC-SA 3.0 already.
27.
▲
by
pbailis
14y ago
I agree--we definitely opted for a more traditional publication format in this first iteration. We've been thinking of how to fix this and were considering something like HackerNews for publicly-accessible articles (e.g., arXiv). Do you hav
28.
▲
What's hot in database research? (Analysis of VLDB papers)
(web.mit.edu)
1 points
by
pbailis
14y ago
|
0 comments
29.
▲
Tiny Transactions on Computer Science: CS research in 140 chars or less
(tinytocs.org)
12 points
by
pbailis
14y ago
|
0 comments
30.
▲
by
pbailis
14y ago
As a shameless plug, I might add that if you can model your network delays, you can use some modeling like our work on PBS (Probabilistically Bounded Staleness) to predict staleness: http://pbs.cs.berkeley.edu/#demo I'd also add that the
More ›