4 ms·

We're here, ready for your questions to be consistently replicated across the WAN at the lowest latency information science allows ;-)

ryanworl 8y ago
Has the lack of interactive transactions and only supporting entirely deterministic transactions been a big issue for your customers? My understanding is you're essentially shipping a "stored procedure" to the database where every input and condition is known up-front. It seems like a reasonable trade-off for lowering the latency of WAN transactions, but it might make application development more complicated.
- evanweaver 8y ago
  No, it hasn't. It is possible to layer an optimistic concurrency model for session transactions on top of our protocol, but the database standard library is sufficiently full-feature that it's easy to express most application logic as a pure function over the current state of the database. Most read/modify/write cycles end up being essentially that, but with the added confusion of local application threading and standard library. We eliminate that, but preserve the general ability to express a complex query in application code (which also increases application concurrency since the database executes transactions with maximum parallelism.) Transactions do not have to be pre-registered as stored procedures.
- jchrisa 8y ago
  This FaunaDB ledger tutorial gives a feel for how you'd build out your application logic: https://fauna.com/blog/tutorial-how-to-create-and-query-a-ledger-with-faunadb https://fauna.com/blog/tutorial-how-to-create-and-query-a-le... If you want to see a query with precondition checks etc, the code at the end of this post is another example: https://fauna.com/blog/distributed-ledger-without-the-blockchain https://fauna.com/blog/distributed-ledger-without-the-blockc...
ummonk 8y ago
Not a database person, so I might be missing context, but why is FaunaDB the only implementation of this? Intuitively, it seems to be exactly the way I would do a distributed database - distributed transactional storage with a global ordering of transactions that are based on ids rather than timestamps. The only thing that I wouldn't intuitively come up with is the actual consensus algorithm, but that already existed... Both the tendency to use declarative rather than transactional queries and the tendency to use timestamps with clock skew rather than an id-based ordering always seemed surprising to me.
- evanweaver 8y ago
  Everybody wants to copy Google apparently; there are a variety of Spanner or Percolator clones although some of them do not meet the original guarantees of their reference systems. FoundationDB also forged its own path and is worth studying.
- zzzcpan 8y ago
  This is such a niche subcategory of distributed databases [1], that it's a miracle even a few of them exist and you want more implementations. Intuitively distributed systems try to avoid consensus/coordination, as doing those things over public internet is not that useful. [1] https://trends.google.com/trends/explore?date=2016-09-20%202018-10-20&q=FaunaDB,FoundationDB,CockroachDB,TiDB https://trends.google.com/trends/explore?date=2016-09-20%202... compare that to some other distributed database https://trends.google.com/trends/explore?date=2016-09-20%202018-10-20&q=FaunaDB,FoundationDB,CockroachDB,TiDB,DynamoDB https://trends.google.com/trends/explore?date=2016-09-20%202...
  - jchrisa 8y ago
    The property that attracts the most mission critical use cases is the ability to keep transactions rolling without loss of guarantees, even while hitting the typical cloud failure modes. Some applications can't make tradeoffs between correctness and global availability, for them FaunaDB's mainframe-like capabilities are key. For the average application, the benefit is that you don't need to write code to address database drift / eventual consistency. I expect Fauna-like systems to gain popularity as more developers come to expect cloud-native solutions to offer global ACID transactions.
tongcx 8y ago
have a question about phantom read issue, i.e. two doctors are oncall for the night, but we have the constraint that at least one is needed to be oncall. If we have two transaction checking whether there is at least 2 doctors oncall, then remove one, seems we could end up with no one oncall with FaunaDB? If so, seems this violate serializability?

ryanworl 8y ago

Has the lack of interactive transactions and only supporting entirely deterministic transactions been a big issue for your customers? My understanding is you're essentially shipping a "stored procedure" to the database where every input and condition is known up-front. It seems like a reasonable trade-off for lowering the latency of WAN transactions, but it might make application development more complicated.

evanweaver 8y ago
No, it hasn't. It is possible to layer an optimistic concurrency model for session transactions on top of our protocol, but the database standard library is sufficiently full-feature that it's easy to express most application logic as a pure function over the current state of the database. Most read/modify/write cycles end up being essentially that, but with the added confusion of local application threading and standard library. We eliminate that, but preserve the general ability to express a complex query in application code (which also increases application concurrency since the database executes transactions with maximum parallelism.) Transactions do not have to be pre-registered as stored procedures.
jchrisa 8y ago
This FaunaDB ledger tutorial gives a feel for how you'd build out your application logic: https://fauna.com/blog/tutorial-how-to-create-and-query-a-ledger-with-faunadb https://fauna.com/blog/tutorial-how-to-create-and-query-a-le... If you want to see a query with precondition checks etc, the code at the end of this post is another example: https://fauna.com/blog/distributed-ledger-without-the-blockchain https://fauna.com/blog/distributed-ledger-without-the-blockc...

ummonk 8y ago

Not a database person, so I might be missing context, but why is FaunaDB the only implementation of this? Intuitively, it seems to be exactly the way I would do a distributed database - distributed transactional storage with a global ordering of transactions that are based on ids rather than timestamps. The only thing that I wouldn't intuitively come up with is the actual consensus algorithm, but that already existed... Both the tendency to use declarative rather than transactional queries and the tendency to use timestamps with clock skew rather than an id-based ordering always seemed surprising to me.

evanweaver 8y ago
Everybody wants to copy Google apparently; there are a variety of Spanner or Percolator clones although some of them do not meet the original guarantees of their reference systems. FoundationDB also forged its own path and is worth studying.
zzzcpan 8y ago
This is such a niche subcategory of distributed databases [1], that it's a miracle even a few of them exist and you want more implementations. Intuitively distributed systems try to avoid consensus/coordination, as doing those things over public internet is not that useful. [1] https://trends.google.com/trends/explore?date=2016-09-20%202018-10-20&q=FaunaDB,FoundationDB,CockroachDB,TiDB https://trends.google.com/trends/explore?date=2016-09-20%202... compare that to some other distributed database https://trends.google.com/trends/explore?date=2016-09-20%202018-10-20&q=FaunaDB,FoundationDB,CockroachDB,TiDB,DynamoDB https://trends.google.com/trends/explore?date=2016-09-20%202...
- jchrisa 8y ago
  The property that attracts the most mission critical use cases is the ability to keep transactions rolling without loss of guarantees, even while hitting the typical cloud failure modes. Some applications can't make tradeoffs between correctness and global availability, for them FaunaDB's mainframe-like capabilities are key. For the average application, the benefit is that you don't need to write code to address database drift / eventual consistency. I expect Fauna-like systems to gain popularity as more developers come to expect cloud-native solutions to offer global ACID transactions.

tongcx 8y ago

have a question about phantom read issue, i.e. two doctors are oncall for the night, but we have the constraint that at least one is needed to be oncall. If we have two transaction checking whether there is at least 2 doctors oncall, then remove one, seems we could end up with no one oncall with FaunaDB? If so, seems this violate serializability?