Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Consistency Without Clocks: FaunaDB's Distributed Transaction Protocol

fauna.com

Post reply on HN
Print view View original

41–50 of 105 posts

Re: Consistency Without Clocks: FaunaDB's Distributed Transaction Protocol

#41

Post by jamesblonde »

evanweaver wrote: post #39
jamesblonde wrote: post #38

Earlier quoted context omitted.

But spanner uses 2pc for cross partition transactions and paxos within a partition. There's no global coordinator service there. Dont get me wrong. I think Calvin/FaunaDb is great as an alternative to Spanner for multi region Dbs. But strict serializability is not a goal for all systems and certainly not for high performance distributed systems that can provide their own concurrency models. Not just HopsFs, but any s…

There is no global coordinator "service" in FaunaDB either. The "coordinator" is a stateless function on available on every node. The log is a stateful, logical function implemented in Raft, so no different than a Paxos ring in terms of failure modes and high availability. Think of it as a way to scale a single Spanner tablet to support the entire dataset and eliminate the 2-phase commit, as well as the associated wr…

Paxos/raft is an agreement service where nodes agree on entries in a single log. I have no problem calling it a distributed/global coordination service for agreeing on entries in a log.

Re: Consistency Without Clocks: FaunaDB's Distributed Transaction Protocol

#43

Post by evanweaver »

kerneltime wrote: post #40

Apologies, I quickly skimmed the blog but in the summary did not see clear answers for: When is the transaction acked? What is the reader-writer consistency? If the transaction is acknowledged only after speculative work is validated after ordering, what is the value add for doing the speculative work? Would you achieve similar benefits from just batching commits?

The transaction is acknowledged after it has been durably replicated to the distributed write-ahead log, and applied by at least one replica. The first replica to apply will ack back to the coordinator and on to the client. This increases partition tolerance and reduces latency.

The speculative work ("reconnaissance query") is what enables support for dependent transactions (transactions where the write set depends on the values of the read set rather than just the keys themselves). The transaction will optimistically retry if the speculation turns out to be false.

Re: Consistency Without Clocks: FaunaDB's Distributed Transaction Protocol

#44

Post by kerneltime »

evanweaver wrote: post #43
kerneltime wrote: post #40

Apologies, I quickly skimmed the blog but in the summary did not see clear answers for: When is the transaction acked? What is the reader-writer consistency? If the transaction is acknowledged only after speculative work is validated after ordering, what is the value add for doing the speculative work? Would you achieve similar benefits from just batching commits?

The transaction is acknowledged after it has been durably replicated to the distributed write-ahead log, and applied by at least one replica. The first replica to apply will ack back to the coordinator and on to the client. This increases partition tolerance and reduces latency. The speculative work ("reconnaissance query") is what enables support for dependent transactions (transactions where the write set depends o…

A system like CORFU where the log is serialized upfront (not post speculative commit) will give most of the benefits mentioned?

Re: Consistency Without Clocks: FaunaDB's Distributed Transaction Protocol

#46

Post by gigatexal »

This is a weakness imo:

`client.query( q.get( q.match( q.index("posts_by_title"), "My cat and other marvels" ) ))`

That you have to specify the index in a query is a regression imo at least I've been spoiled by not having to have to do so in when using Mongo or SQL databases since the query engine will more often than not find the right index.

Re: Consistency Without Clocks: FaunaDB's Distributed Transaction Protocol

#47

Post by gigatexal »

evanweaver wrote: post #45
gigatexal wrote: post #42

Hmm. I’m intrigued though skeptical. Who’s using this in production that can give an unbiased take?

Not quite what you are asking, but some customers with case studies on the site: https://fauna.com/customers

Unbiased in that the article we are all referencing is coming from you guys, the creators, you can't help but show it in a positive light and I don't fault you for it. Just I've become so jaded of late that I am looking for people who have used it in the wild.

I also signed up for the cloud account -- your pricing terms are some of the best I've ever seen, kudos -- so that I can check out the API some more.

Re: Consistency Without Clocks: FaunaDB's Distributed Transaction Protocol

#48

Post by evanweaver »

gigatexal wrote: post #46

This is a weakness imo: `client.query( q.get( q.match( q.index("posts_by_title"), "My cat and other marvels" ) ))` That you have to specify the index in a query is a regression imo at least I've been spoiled by not having to have to do so in when using Mongo or SQL databases since the query engine will more often than not find the right index.

This a design choice to guarantee predictable performance at scale, not an architectural limitation, and subject to revision.

You don't want your service to collapse when the query optimizer suddenly doesn't choose the right index anymore. That was a hard lesson learned for us at Twitter.

Re: Consistency Without Clocks: FaunaDB's Distributed Transaction Protocol

#49

Post by evanweaver »

kerneltime wrote: post #44
evanweaver wrote: post #43

Earlier quoted context omitted.

The transaction is acknowledged after it has been durably replicated to the distributed write-ahead log, and applied by at least one replica. The first replica to apply will ack back to the coordinator and on to the client. This increases partition tolerance and reduces latency. The speculative work ("reconnaissance query") is what enables support for dependent transactions (transactions where the write set depends o…

A system like CORFU where the log is serialized upfront (not post speculative commit) will give most of the benefits mentioned?

My understanding is that in CORFU the write set is always known, so this kind of transaction cannot be expressed. You could layer it on top with the same strategy.

Re: Consistency Without Clocks: FaunaDB's Distributed Transaction Protocol

#50

Post by gigatexal »

evanweaver wrote: post #48
gigatexal wrote: post #46

This is a weakness imo: `client.query( q.get( q.match( q.index("posts_by_title"), "My cat and other marvels" ) ))` That you have to specify the index in a query is a regression imo at least I've been spoiled by not having to have to do so in when using Mongo or SQL databases since the query engine will more often than not find the right index.

This a design choice to guarantee predictable performance at scale, not an architectural limitation, and subject to revision. You don't want your service to collapse when the query optimizer suddenly doesn't choose the right index anymore. That was a hard lesson learned for us at Twitter.

I agree -- it burns us in the SQL world too. I was just seeing it from a developer cognitive load point of view and maybe as a premature optimization, again, though if you guys and gals put this in place because of war stories from twitter then it's not premature by any means.

In the rare case when no index or the wrong index is used in a SQL query an index hint is all it takes to fix or updating statistics of a table to help the optimizer. Not having to remember the exact index for a query imo is better, but I could learn to adapt.

Post reply on HN