4 ms·
I really like the fact that facts are immutable in the Datomic model. It actually makes it easier to reason about eventually consistent, because you can rely on
by sargun 12y ago
I really like the fact that facts are immutable in the Datomic model. It actually makes it easier to reason about eventually consistent, because you can rely on causal consistency between facts. Eventually consistent systems can give you durability, isolation, and atomicity, but it's typically hard to reason about, because the interface that's given to the user is some sort of multi-value, vector-clock tracked thing, and it's hard to reason about.
Datomic can manage a commit protocol under the hood, and deal with causality tracking without requiring the developer to "get dirty." It's query language is declarative, and doesn't provide the same implicit guarantees that SQL queries need.
- mdavidn 12y agoDatomic is not an eventually consistent system. All writes pass through a single "transactor," which serializes transactions and provides the same ACID guarantees as a traditional SQL database.
- sargun 12y agoBut, the data storage can be in a AP system, allowing better stories around data availability.
- dantiberian 12y agoThe Datomic docs at http://docs.datomic.com/acid.html http://docs.datomic.com/acid.html describe it's ACID properties quite well. > Another way to understand this is to consider the failure mode introduced by an eventually consistent node that is not up-to-date yet. Datomic will always see a correct log pointer, which was placed via conditional put. If some of the tree nodes are not yet visible underneath that pointer, Datomic is consistent but partially unavailable, and will become fully available when eventually happens.