3 ms·

Dynamo strongly consistent transactions are still limited to a single region, and are eventually consistent outside of that region. For example, in Dynamo, it i

Dynamo strongly consistent transactions are still limited to a single region, and are eventually consistent outside of that region. For example, in Dynamo, it is not possible to enforce uniqueness via multi-region strongly consistent transactions. Fauna can do this. The Dynamo transactions do increase latency, but not to the same degree as Fauna. However, they are not achieving the same level of transactional correctness either, or really any correctness at all in a multi-region context.

k__ 5y ago
Yes, I know. I was just interested if a ConsistentRead would change the latency.
- evanweaver 5y ago
  It has to to acquire and release locks, so yes.
  - deleted 5y ago
    [deleted]
  - deleted 5y ago
    [deleted]
  - ec109685 5y ago
    Are you sure about that? DynamoDB is paxos based, so that seems unnecessary. Given data is always replicated to at least 2 of 3 storage nodes before ACK’ing, you can always just read from 2 different replicas and be sure you have the latest data.
    - evanweaver 5y ago
      Oh, I thought you were referring to the multi-key consistent transactions, not single key strong consistency mode. I think you are correct.
confuser 5y ago
I struggle to think of a scenario where cross-region transactions would be useful. Why not just pick a primary region where transactions will be carried out for a given piece of data if consistency guarantees are needed?
- redis_mlc 5y ago
  I'm a DBA, and I agree. Cross-region transactions rarely make sense because if one region is not reachable (down, network-partitioned for more than 1 minute), then you can't do writes to any region. Think about it. :) I guess if your partition time interval was known to be very short, like a flaky ISDN link, it could make sense for some use cases using retries, but then you should just get a better link. CockroachDB discusses a multi-city vehicle sharing use case where multi-region transactions could be worth consideration, but I'm skeptical: https://www.cockroachlabs.com/docs/stable/multi-region-use-case.html https://www.cockroachlabs.com/docs/stable/multi-region-use-c... (Developers and students get all excited about distributed systems, CAP, etc. but as a DBA, network partitions are largely not solvable from both technical and business standpoints. The solutions that do work include using vector clocks, or investing in a very reliable network, which is what Google is doing with dedicated fiber.)
  - evanweaver 5y ago
    You can indeed perform writes in other regions; this is the entire point of Calvin, Spanner, and other modern distributed transaction algorithms: maintaining consistency and maximizing availability in the face of partitions. Your perspective is about a decade out of date.
    - redis_mlc 5y ago
      > You can indeed perform writes in other regions Those aren't multi-region transactions.

k__ 5y ago

Yes, I know. I was just interested if a ConsistentRead would change the latency.

evanweaver 5y ago
It has to to acquire and release locks, so yes.
- deleted 5y ago
  [deleted]
- deleted 5y ago
  [deleted]
- ec109685 5y ago
  Are you sure about that? DynamoDB is paxos based, so that seems unnecessary. Given data is always replicated to at least 2 of 3 storage nodes before ACK’ing, you can always just read from 2 different replicas and be sure you have the latest data.
  - evanweaver 5y ago
    Oh, I thought you were referring to the multi-key consistent transactions, not single key strong consistency mode. I think you are correct.

confuser 5y ago

I struggle to think of a scenario where cross-region transactions would be useful. Why not just pick a primary region where transactions will be carried out for a given piece of data if consistency guarantees are needed?

redis_mlc 5y ago
I'm a DBA, and I agree. Cross-region transactions rarely make sense because if one region is not reachable (down, network-partitioned for more than 1 minute), then you can't do writes to any region. Think about it. :) I guess if your partition time interval was known to be very short, like a flaky ISDN link, it could make sense for some use cases using retries, but then you should just get a better link. CockroachDB discusses a multi-city vehicle sharing use case where multi-region transactions could be worth consideration, but I'm skeptical: https://www.cockroachlabs.com/docs/stable/multi-region-use-case.html https://www.cockroachlabs.com/docs/stable/multi-region-use-c... (Developers and students get all excited about distributed systems, CAP, etc. but as a DBA, network partitions are largely not solvable from both technical and business standpoints. The solutions that do work include using vector clocks, or investing in a very reliable network, which is what Google is doing with dedicated fiber.)
- evanweaver 5y ago
  You can indeed perform writes in other regions; this is the entire point of Calvin, Spanner, and other modern distributed transaction algorithms: maintaining consistency and maximizing availability in the face of partitions. Your perspective is about a decade out of date.
  - redis_mlc 5y ago
    > You can indeed perform writes in other regions Those aren't multi-region transactions.