5 ms·

> By sacrificing consistency you enter a realm where logic and cause and effect no longer apply - it's hell to program with that model - and the resulting bugs

• eloff 5y ago
  Eventually consistent generally means things can be all over the place. You can temporarily see extremely weird and unintuitive things and then modify data based on that incorrect world view. That means eventually consistent turns into permanently inconsistent in unpredictable ways. CRDTs are interesting, but over hyped. They only work for very simple situations and very limited data structures.
  • lostcolony 5y ago
    Eventual consistency is a stronger guarantee than you get with a remote git repo. It actually works fine for a large number of use cases. CRDTs are just a way of implementing eventual consistency in provably predictable and 'reasonable' manners. I will agree they are very limited data structures, but I disagree that they only work for very simple situations. I'd liken them to an immutable list in FP. Very limited data structure, but can be used cleverly to create very complicated ones that maintain the same invariants.
    • loopz 5y ago
      If it's anything used by Netflix, Amazon Prime, Facebook, etc. it's inconsistent in practice. Maybe some of them does it right, but updates seems to be lost often. Perhaps something else than CRDTs is used though.
      • lostcolony 5y ago
        So, CRDTs are just a tool at the data layer to provide a way to resolve inconsistencies. A simple and easily understood example is an add-only set; in the event there is inconsistency it can be automatically resolved; the consistent state is just the union of the sets. Now, while that model will give you predictable behavior to resolve inconsistencies, it's still eventually consistent (well, hopefully; CRDTs, being a data structure, also don't enforce that the system actually resolves those inconsistencies, just guarantees that it can do so in a correct way). And it doesn't tell you anything about the rest of the system. I.e., even using CRDTs, if I have an internal netsplit, if you write to one partition, and read from the other, you will miss data (and if I try to read again, I might read from the partition I wrote to, so some reads return state T, and some reads return state T-1, until the consistency is resolved). The benefit to CRDTs is that when the consistency is resolved (no guarantees on when that will be, or that the system as a whole ensures it!), I've definitely moved forward in time. Not all conflict resolution mechanisms provide that guarantee. For instance, Cassandra's (which came out of Facebook) old default (maybe current, I haven't used it in a while) of "Last Write Wins" meant that clock drift could lead to weirdness. I.e., at my time T I write X = 1. At my time T+1 I write X = 2. HOWEVER, the clock providing the timestamp of the change for the second is lagging, and thinks it's actually T-1. When the system deconflicts, T > T-1, so X will remain equal to 1, even though from a true temporal sense I know that X should be equal to 2.
  • im3w1l 5y ago
    I don't think that necessarily follows? I don't see why you can't have very intuitive and logical inconsistency. To give a super simple example, imagine a database on two servers A and B. A is the canonical copy, and updates are streamed to B. All responses from A and B are of the form "the data as of <time> was x". During a partition B will simply serve increasingly stale data.
    • eloff 5y ago
      I'm not exactly sure what your point is. Inconsistent systems are not always horrible? Mostly they behave well. It's really that they have edge cases that are unintuitive. In your example of a user is switching between A and B all the time, imagine their confusion as their changes keep getting lost and reappearing. Now imagine they make other changes based on that situation. This can also happen with different users communicating via a side channel.
      • loopz 5y ago
        In practice infrastructure is more complex than client-server, even if distributed. So inconsistencies may propagate in semi-random ways. Interestingly this happens in physical systems too, something accounting and banks provide means to mitigate.
    • ithkuil 5y ago
      What you're describing is a single writer distributed system, which is one way to achieve consistency. Since you can't write directly to server B, the system is unavailable for writes when a writer happens to live on the side of the network partition where B is located. Often when discussing "availability", it's very important to qualify for whom and for which operations.
  • deleted 5y ago
    [deleted]
  • lmm 5y ago
    > You can temporarily see extremely weird and unintuitive things and then modify data based on that incorrect world view. No you can't, not without breaking the rules of the system, because as you say, that would lead to an actually inconsistent system. > CRDTs are interesting, but over hyped. They only work for very simple situations and very limited data structures. Nonsense. CPUs only work on very limited data structures (sequences of bits), but that's not a concern in practice because we can build up more complicated datastructures on top of them. The same is true for CRDTs.
    • eloff 5y ago
      > No you can't, not without breaking the rules of the system, because as you say, that would lead to an actually inconsistent system. If you want to redefine eventually consistent to prohibit that behavior then you've just reclassified most real life AP systems as eventually inconsistent. Eventually consistent systems allow stale reads of older data plus deleted data for an undefined period of time. If you turn around and issue a write based on that you get inconsistency. Eventually consistent systems do not prohibit this. > Nonsense. CPUs only work on very limited data structures (sequences of bits), but that's not a concern in practice because we can build up more complicated datastructures on top of them. The same is true for CRDTs. You're talking like there are no downsides to CRDTs. There are huge downsides to them, which is why they're rarely used in practice. Your analysis is only valid in theory.
      • ledauphin 5y ago
        I would appreciate some information specifically about the problems that cannot be solved by building abstractions on top of CRDTs. I don't don't they exist.
        • eloff 5y ago
          What data structures can't be implemented efficiently? Or what applications can't be architected differently to utilize CRDTs?
      • lmm 5y ago