7 ms·

TLDR: FaunaDB is a distributed database that offers multi-partition ACID transactions and is optimized for cloud / multi-cloud deployment. This is a big deal be

TLDR: FaunaDB is a distributed database that offers multi-partition ACID transactions and is optimized for cloud / multi-cloud deployment. This is a big deal because there aren't many other options with this level of data integrity at worldwide scale. Use cases include financial services, retail, user identity, game world state, etc. Basically anything you'd put in an operational database. In addition to the download (free for one node), you can get started with FaunaDB Serverless Cloud for free in moments. It's a fully managed version that is used in production by some major sites and many smaller apps.

jatsign 8y ago
Sorry, I'm not trying to be snarky, but that sounds like "it's good for everything" and doesn't help me determine when I should look at Fauna and when I shouldn't. Perhaps alternately - when is Fauna NOT a good choice?
- evanweaver 8y ago
  Well, it is a general-purpose database with a document-relational programming model. It's a good choice when correctness, high availability, and flexible data modeling matter, like the core business objects of a service or app. Currently it supports its own native DSL similar to LINQ or an ORM, and if you want compatibility with existing query languages from other databases, we will be rolling those out over time. It's not a good choice for analytics or time series data which is redundant or aggregated, and doesn't need the high availability or performance overhead of transactional isolation.
- deleted 8y ago
  [deleted]
- aphyr 8y ago
  A few other points to consider! FaunaDB is a unique database: its architecture offers linear scalability for transaction throughput (limited, of course, by contention on common records and predicates). That sets it aside from databases which use a single coordinator for all, or just cross-shard, transactions, like Datomic and VoltDB, respectively. It's also intended for geographic replication, which is a scenario many databases don't try to handle with the same degree of transactional safety--lots of folks support, say, snapshot isolation or linearizability inside one DC, but between DCs all bets are off. FaunaDB also does not depend on clocks for safety, which sets it aside from other georeplicated databases that assume clocks are well-synchronized. Theoretically, relying on clocks can make you faster, so those kinds of systems might outperform Fauna--at the potential cost of safety issues when clocks misbehave. In practice, there are lots of factors that affect performance, and it's easy to introduce extra round trips into a protocol which could theoretically be faster. There's a lot of room for optimization! I can't speak very well to performance numbers, because Jepsen isn't designed as a performance benchmark, and its workloads are intentionally pathological, with lots of contention. One of the things you lose with FaunaDB's architecture is interactive transactions--as in VoltDB, you submit transactions all at once. That means FaunaDB can make some optimizations that interactive session transactions can't do! But it also means you have to fit your transactional logic into FaunaDB's query language. The query language is (IMO) really expressive, but if you needed to do, e.g. a complex string-munging operation inside a transaction to decide what to do, it might not be expressible in a single FaunaDB transaction; you might have to say, read data, make the decision in your application, then execute a second CaS transaction to update state. FaunaDB's not totally available--it uses unanimous agreement over majority quorums, which means some kinds of crashes or partitions can pause progress. If you're looking for a super low latency CRDT-style database where every node can commit even if totally isolated, it's not the right fit. It is a good fit if you need snapshot isolation to strict serializability, which are strong consistency models!
  - dsergeyev 8y ago
    Hey I am curious what does it use in place clocks for safety and quorum? Is there a paper
    - aphyr 8y ago
      Yes, there IS a paper! Check out Calvin: Fast Distributed Transactions for Partitioned Database Systems. FaunaDB uses Calvin with some changes to allow more types of transactions, and to improve fault tolerance. :) http://cs.yale.edu/homes/thomson/publications/calvin-sigmod12.pdf http://cs.yale.edu/homes/thomson/publications/calvin-sigmod1...
    - evanweaver 8y ago
      See our blog post as well: https://fauna.com/blog/consistency-without-clocks-faunadb-transaction-protocol https://fauna.com/blog/consistency-without-clocks-faunadb-tr...
  - deleted 8y ago
    [deleted]
  - deleted 8y ago
    [deleted]
  - justinsaccount 8y ago
    > If you're looking for a super low latency CRDT-style database where every node can commit even if totally isolated, it's not the right fit. What is actually a good for this lately?
    - aphyr 8y ago
      Gosh, I wish I had a good answer. Riak (and Riak-DT) were the best I knew of in this regard, but Basho folded and I haven't kept track of the level of community/corporate support available. Not sure where Riak stands these days. There are a bunch of prototype databases experimenting with CRDTs and other eventually-consistent mechanisms, but I'm not sure which ones have garnered significant traction in the industry yet.
- peterwwillis 8y ago
  I'm not trying to be snarky either, but your question was a bit like "What's the use case for pants?" The answer is, a lot of things. We would need to know what you're doing to tell you what it's good for, what kind to choose, and why.
- zzzcpan 8y ago
  In general consensus based systems are not good when latency and performance actually matter and in real world WAN setups, where connectivity issues are pretty much constant. These are fundamental limitations they can't fix.
  - freels 8y ago
    Unless you have specifics, I’m not sure this comment stands up to reality. Modern networks are pretty reliable in my experience. The state of the art in consensus reduces learning to one round trip. Calvin further eliminates all but one global RT in distributed transaction commits. Additionally, FaunaDB gives you the tools to work within a global environment with _safe tradeoffs_. For example, reads at SI/Serializable can be fast and uncoordinated. You choose per-query.
    - deleted 8y ago
      [deleted]
    - zzzcpan 8y ago
      Well, networks are not that reliable. But you don't have to believe me, there is enough of public information about real world operations. Take Aurora paper for example, where they can't even do 2/3 quorum, but do 4/6 quorum instead and that's between datacenters they completely control with connectivity they more or less control.
      - freels 8y ago
        Just because failure can happen doesn't mean it's frequent. For the record AWS does this to protect against correlated failure. At their scale, they assume they have some percentage of local nodes down at any given time, so have designed the system to tolerate both network partitions and local failure at the same time.
        zzzcpan 8y ago
        They did it for stable performance, because failures are in fact frequent. Things are much worse once you go out into the public internet, where different hosting providers communicate over all kinds of networks with all kinds of issues.
twic 8y ago
Would it be fair to say that if i am considering Gemfire/Geode, i should also consider Fauna?
- evanweaver 8y ago
  Yes, for sure. They are both distributed object stores and share inspiration from the Linda/tuplespace lineage, as well as relational and document databases in FaunaDB's case. FaunaDB supports function execution in the database, if the functions are written in FQL. It has a much more powerful index system and consistency model than Gemstone/Gemfire/Geode and is designed for synchronous global replication. However, unlike Geode it is not an in-memory system, so it is not appropriate to use as a cache.
- metatype 8y ago
  As noted in the writeup, the FaunaDB transaction model uses a unique query expression language. Geode applies a more familiar begin + <operations> + commit / abort approach. Geode skews towards eventual consistency when connecting geographically dispersed clusters. This means you still get super fast local transactions with batched updates to remote sites.

jatsign 8y ago

Sorry, I'm not trying to be snarky, but that sounds like "it's good for everything" and doesn't help me determine when I should look at Fauna and when I shouldn't. Perhaps alternately - when is Fauna NOT a good choice?

evanweaver 8y ago
Well, it is a general-purpose database with a document-relational programming model. It's a good choice when correctness, high availability, and flexible data modeling matter, like the core business objects of a service or app. Currently it supports its own native DSL similar to LINQ or an ORM, and if you want compatibility with existing query languages from other databases, we will be rolling those out over time. It's not a good choice for analytics or time series data which is redundant or aggregated, and doesn't need the high availability or performance overhead of transactional isolation.
deleted 8y ago
[deleted]
aphyr 8y ago
A few other points to consider! FaunaDB is a unique database: its architecture offers linear scalability for transaction throughput (limited, of course, by contention on common records and predicates). That sets it aside from databases which use a single coordinator for all, or just cross-shard, transactions, like Datomic and VoltDB, respectively. It's also intended for geographic replication, which is a scenario many databases don't try to handle with the same degree of transactional safety--lots of folks support, say, snapshot isolation or linearizability inside one DC, but between DCs all bets are off. FaunaDB also does not depend on clocks for safety, which sets it aside from other georeplicated databases that assume clocks are well-synchronized. Theoretically, relying on clocks can make you faster, so those kinds of systems might outperform Fauna--at the potential cost of safety issues when clocks misbehave. In practice, there are lots of factors that affect performance, and it's easy to introduce extra round trips into a protocol which could theoretically be faster. There's a lot of room for optimization! I can't speak very well to performance numbers, because Jepsen isn't designed as a performance benchmark, and its workloads are intentionally pathological, with lots of contention. One of the things you lose with FaunaDB's architecture is interactive transactions--as in VoltDB, you submit transactions all at once. That means FaunaDB can make some optimizations that interactive session transactions can't do! But it also means you have to fit your transactional logic into FaunaDB's query language. The query language is (IMO) really expressive, but if you needed to do, e.g. a complex string-munging operation inside a transaction to decide what to do, it might not be expressible in a single FaunaDB transaction; you might have to say, read data, make the decision in your application, then execute a second CaS transaction to update state. FaunaDB's not totally available--it uses unanimous agreement over majority quorums, which means some kinds of crashes or partitions can pause progress. If you're looking for a super low latency CRDT-style database where every node can commit even if totally isolated, it's not the right fit. It is a good fit if you need snapshot isolation to strict serializability, which are strong consistency models!
- dsergeyev 8y ago
  Hey I am curious what does it use in place clocks for safety and quorum? Is there a paper
  - aphyr 8y ago
    Yes, there IS a paper! Check out Calvin: Fast Distributed Transactions for Partitioned Database Systems. FaunaDB uses Calvin with some changes to allow more types of transactions, and to improve fault tolerance. :) http://cs.yale.edu/homes/thomson/publications/calvin-sigmod12.pdf http://cs.yale.edu/homes/thomson/publications/calvin-sigmod1...
  - evanweaver 8y ago
    See our blog post as well: https://fauna.com/blog/consistency-without-clocks-faunadb-transaction-protocol https://fauna.com/blog/consistency-without-clocks-faunadb-tr...
- deleted 8y ago
  [deleted]
- deleted 8y ago
  [deleted]
- justinsaccount 8y ago
  > If you're looking for a super low latency CRDT-style database where every node can commit even if totally isolated, it's not the right fit. What is actually a good for this lately?
  - aphyr 8y ago
    Gosh, I wish I had a good answer. Riak (and Riak-DT) were the best I knew of in this regard, but Basho folded and I haven't kept track of the level of community/corporate support available. Not sure where Riak stands these days. There are a bunch of prototype databases experimenting with CRDTs and other eventually-consistent mechanisms, but I'm not sure which ones have garnered significant traction in the industry yet.
peterwwillis 8y ago
I'm not trying to be snarky either, but your question was a bit like "What's the use case for pants?" The answer is, a lot of things. We would need to know what you're doing to tell you what it's good for, what kind to choose, and why.
zzzcpan 8y ago
In general consensus based systems are not good when latency and performance actually matter and in real world WAN setups, where connectivity issues are pretty much constant. These are fundamental limitations they can't fix.
- freels 8y ago
  Unless you have specifics, I’m not sure this comment stands up to reality. Modern networks are pretty reliable in my experience. The state of the art in consensus reduces learning to one round trip. Calvin further eliminates all but one global RT in distributed transaction commits. Additionally, FaunaDB gives you the tools to work within a global environment with _safe tradeoffs_. For example, reads at SI/Serializable can be fast and uncoordinated. You choose per-query.
  - deleted 8y ago
    [deleted]
  - zzzcpan 8y ago
    Well, networks are not that reliable. But you don't have to believe me, there is enough of public information about real world operations. Take Aurora paper for example, where they can't even do 2/3 quorum, but do 4/6 quorum instead and that's between datacenters they completely control with connectivity they more or less control.
    - freels 8y ago
      Just because failure can happen doesn't mean it's frequent. For the record AWS does this to protect against correlated failure. At their scale, they assume they have some percentage of local nodes down at any given time, so have designed the system to tolerate both network partitions and local failure at the same time.
      - zzzcpan 8y ago
        They did it for stable performance, because failures are in fact frequent. Things are much worse once you go out into the public internet, where different hosting providers communicate over all kinds of networks with all kinds of issues.

twic 8y ago

Would it be fair to say that if i am considering Gemfire/Geode, i should also consider Fauna?

evanweaver 8y ago
Yes, for sure. They are both distributed object stores and share inspiration from the Linda/tuplespace lineage, as well as relational and document databases in FaunaDB's case. FaunaDB supports function execution in the database, if the functions are written in FQL. It has a much more powerful index system and consistency model than Gemstone/Gemfire/Geode and is designed for synchronous global replication. However, unlike Geode it is not an in-memory system, so it is not appropriate to use as a cache.
metatype 8y ago
As noted in the writeup, the FaunaDB transaction model uses a unique query expression language. Geode applies a more familiar begin + <operations> + commit / abort approach. Geode skews towards eventual consistency when connecting geographically dispersed clusters. This means you still get super fast local transactions with batched updates to remote sites.