3 ms·
I think you may have some misconceptions about what consistency means in this context. > In and eventually consistent system, the programmer must consider what
by mayank 9y ago
I think you may have some misconceptions about what consistency means in this context.
> In and eventually consistent system, the programmer must consider what to do in the case of data failure.
Eventually consistency has nothing to do with data failure; the real-world effect of eventually consistency is stale data, which you can't generally tell is stale.
> When building a user authentication system, who better to decide what to do when you can't access the user database than the person writing the user auth system?
I think you're talking about availability, not (eventual) consistency.
> Also, it means that joins must be done in your application.
There is nothing preventing you from doing joins in a strongly consistent database. Google Spanner supports JOINs for example [1].
> In an eventually consistent system, you know if you created a table scan, because you have to pull back a full table's worth of data
This also has nothing to do with eventual consistency.
[1] https://cloud.google.com/spanner/docs/query-syntax#join-hints https://cloud.google.com/spanner/docs/query-syntax#join-hint...
- jetcata 9y agoAgree with above, I'm not sure why that comment is most upvoted, it's poorly written and the author doesn't seem to have a good grasp of distributed systems concepts.
- hueving 9y agoVague "I agree" criticisms make for poor reading. Provide specific counter examples like the parent or don't bother commenting.
- jedberg 9y agoI was using "eventually consistent system" as a shorthand for "multi-master database that is eventually consistent" which may have been confusing.
- jedberg 9y agoI was using "eventually consistent" as a shorthand for "multi-master highly-available key-value distributed database". Most people who don't work in the space regularly consider them the same thing. Basically Cassandra/DynamoDB vs Cloud Spanner. > Eventually consistency has nothing to do with data failure; the real-world effect of eventually consistency is stale data, which you can't generally tell is stale. You're right, that is the highly available distributed part, but it goes along with eventual consistency because if you plan for dealing with stale data then those same concepts protect you from unavailable data. > I think you're talking about availability, not (eventual) consistency. Again, the two go hand in hand. Deal with stale data and you've dealt with unavailable data. > There is nothing preventing you from doing joins in a strongly consistent database. You misread -- I was saying that with a multi-master key-value system you have to do joins in the app. > This also has nothing to do with eventual consistency. Same, I was talking about Dynamo-like systems.
- mayank 9y agoHey, appreciate the attempt at clearing things up, but I’m afraid your original comment is still quite wrong. It looks like you’re conflating a well-defined term in distributed systems with properties of particular database implementations that have nothing to do with eventual consistency. Nothing in your reply is a necessary property of eventually consistent systems, although some eventually consistent systems may be built with those properties. That is quite a huge difference when we’re in the context of the blog post being discussed. The grayness of your reply should suggest that perhaps you’re misusing the term, rather than everyone else being “confused”.