5 ms·

> The key is that data is immutable. Immutable data means there's no such thing as an update, so it's impossible for different replicas of a piece of data to be

> The key is that data is immutable. Immutable data means there's no such thing as an update, so it's impossible for different replicas of a piece of data to become inconsistent. I'm not following that point. Suppose you have an event-souring data store as the OP suggests, and some nodes go out of sync. So one of the nodes records that Sally now lives in Atlanta, the other doesn't. The query for Sally's location asks for the last update. One node says Atlanta, the other still says Chicago. What's that, if not inconsistent? Only appending data means you don't corrupt old data, but you still can get conflicting responses from different parts of your system.

herge 15y ago
You add a version number or timing information to each update. Node A says Atlanta, with version 42. Node B says Chicago, with version 41. 42 > 41, so you go with Atlanta.
- VladRussian 15y ago
  when you have fault in the system so you can't access node A, node B returns Chicago with version 41 and you proceed with it if your system choice is Availability at the price of Consistency, or you wait for the node A if you choice Consistency at the price of Availability.
IgorPartola 15y ago
This is the key point. You either set your writes to be synchronous or asynchronous, depending on whether you want consistency or high availability. The point of having no updates means that you have less possibility for conflicts when sites A and B are appended to simultaneously. This means robust replication even with async writes.
nathanmarz 15y ago
What you're describing is a query. "What is Sally's current location?" Queries can be inconsistent during partitions. This is what eventual consistency means. But once the partition clears, the queries will be consistent again. The data is immutable. Both "Sally lives in Atlanta as of time X" and "Sally lives in Chicago as of time Y" are true. This is far, far different from databases based on mutable state. In order for a database like that to be eventually consistent, you need to do read-repair to enforce consistency. This is besides the other problems I brought up with mutable databses, such as a lack of human fault-tolerance.
- VladRussian 15y ago
  >Both "Sally lives in Atlanta as of time X" and "Sally lives in Chicago as of time Y" are true. >This is far, far different from databases based on mutable state. In order for a database like that to be eventually consistent, you need to do read-repair to enforce consistency. what databases you're talking about? any specific example?
  - nathanmarz 15y ago
    Dynamo, Riak, Cassandra
    - VladRussian 15y ago
      so this is more complicated than your schema ? : http://wiki.basho.com/Replication.html#Read-Repair http://wiki.basho.com/Replication.html#Read-Repair "Read repair occurs when a successful read occurs — that is, the quorum was met — but not all replicas from which the object was requested agreed on the value. There are two possibilities here for the errant nodes: 1. The node responded with a “not found” for the object, meaning it doesn’t have a copy. 2. The node responded with a vector clock that is an ancestor of the vector clock of the successful read. When this situation occurs, Riak will force the errant nodes to update their object values based on the value of the successful read."
      - nathanmarz 15y ago
        Yes. First of all, not every algorithm is amenable to read-repair. Imagine, for example, storing a unique count in the database. There's no way to know how to combine divergent values in that case. (If the root value is 4, and you have two divergent values of 5, you have no idea if the increment was due to the same element or not. The right answer is either 5 or 6, but you have no idea). More importantly, if you make a mistake, you corrupt the database. The system I described based on immutable data is human fault-tolerant, which is a critical property. If you mess up, you can always correct things.

herge 15y ago

You add a version number or timing information to each update. Node A says Atlanta, with version 42. Node B says Chicago, with version 41. 42 > 41, so you go with Atlanta.

VladRussian 15y ago
when you have fault in the system so you can't access node A, node B returns Chicago with version 41 and you proceed with it if your system choice is Availability at the price of Consistency, or you wait for the node A if you choice Consistency at the price of Availability.

IgorPartola 15y ago

This is the key point. You either set your writes to be synchronous or asynchronous, depending on whether you want consistency or high availability. The point of having no updates means that you have less possibility for conflicts when sites A and B are appended to simultaneously. This means robust replication even with async writes.

nathanmarz 15y ago

What you're describing is a query. "What is Sally's current location?" Queries can be inconsistent during partitions. This is what eventual consistency means. But once the partition clears, the queries will be consistent again. The data is immutable. Both "Sally lives in Atlanta as of time X" and "Sally lives in Chicago as of time Y" are true. This is far, far different from databases based on mutable state. In order for a database like that to be eventually consistent, you need to do read-repair to enforce consistency. This is besides the other problems I brought up with mutable databses, such as a lack of human fault-tolerance.

VladRussian 15y ago
>Both "Sally lives in Atlanta as of time X" and "Sally lives in Chicago as of time Y" are true. >This is far, far different from databases based on mutable state. In order for a database like that to be eventually consistent, you need to do read-repair to enforce consistency. what databases you're talking about? any specific example?
- nathanmarz 15y ago
  Dynamo, Riak, Cassandra
  - VladRussian 15y ago
    so this is more complicated than your schema ? : http://wiki.basho.com/Replication.html#Read-Repair http://wiki.basho.com/Replication.html#Read-Repair "Read repair occurs when a successful read occurs — that is, the quorum was met — but not all replicas from which the object was requested agreed on the value. There are two possibilities here for the errant nodes: 1. The node responded with a “not found” for the object, meaning it doesn’t have a copy. 2. The node responded with a vector clock that is an ancestor of the vector clock of the successful read. When this situation occurs, Riak will force the errant nodes to update their object values based on the value of the successful read."
    - nathanmarz 15y ago
      Yes. First of all, not every algorithm is amenable to read-repair. Imagine, for example, storing a unique count in the database. There's no way to know how to combine divergent values in that case. (If the root value is 4, and you have two divergent values of 5, you have no idea if the increment was due to the same element or not. The right answer is either 5 or 6, but you have no idea). More importantly, if you make a mistake, you corrupt the database. The system I described based on immutable data is human fault-tolerant, which is a critical property. If you mess up, you can always correct things.