Consistency is Consistently Undervalued • Hacker News Board

Re: Consistency is Consistently Undervalued

#101

Post by knucklesandwich » Sat, Sep 17, 2016, 7:16 PM UTC

SomeStupidPoint wrote: post #100

knucklesandwich wrote: post #98

Earlier quoted context omitted.

It's a cool metaphor, and I'm sure there are occasions where its easy to pass this off as innocuous. But inconsistent semantics can produce blemishes and bugs that can be difficult to anticipate and can very negatively impact user experience if you aren't careful. The typo explanation is acceptable when I just see some comment I posted being reordered after a page refresh. It's less so if I get locked out of my accou…

> The typo explanation is acceptable when I just see some comment I posted being reordered after a page refresh. It's less so if I get locked out of my account because my password change hasn't fully replicated to all servers (and even less so if my consistency model doesn't converge). The typo model is merely meant to explain why it happened. You'd be no more happy if you were locked out of a door because a locksmit…

Oh apologies, I misunderstood what you were saying! Yes, agreed, this is a good method for communicating what's occurring in weakly consistent systems to stakeholders. Definitely going to use this in the future.

Re: Consistency is Consistently Undervalued

#102

Post by karmakaze » Sat, Sep 17, 2016, 7:35 PM UTC

vidarh wrote: post #25

My opinion is exactly opposite: Consistently is overvalued. Requiring consistency in distributed system generally leads to designs that reduces availability. Which is one of the reasons that bank transactions generally do not rely on transactional updates against your bank. "Low level" operations as part of settlement may us transactions, but the bank system is "designed" (more like it has grown by accretion) to func…

For the specific case of distributed datastores, by threshold for considering any NoSQL/NewSQL is scaled writes and consistent reads. Designing a system based on consistent reads is much simpler without quirks that need to be explained to end-users.

Re: Consistency is Consistently Undervalued

#103

Post by superuser2 » Sat, Sep 17, 2016, 7:38 PM UTC

vidarh wrote: post #25

My opinion is exactly opposite: Consistently is overvalued. Requiring consistency in distributed system generally leads to designs that reduces availability. Which is one of the reasons that bank transactions generally do not rely on transactional updates against your bank. "Low level" operations as part of settlement may us transactions, but the bank system is "designed" (more like it has grown by accretion) to func…

>designs that reduces availability.

It's a slimy abuse of language to call a service "available" when it's giving incorrect output and corrupting its persistent state.

I can write a program with lots of nines that is blazingly faster than its competitors if its behavior is allowed to be incorrect.

Re: Consistency is Consistently Undervalued

#104

Post by user5994461 » Sat, Sep 17, 2016, 8:27 PM UTC

knucklesandwich wrote: post #82

vidarh wrote: post #68

Earlier quoted context omitted.

> You can't do this in general, because we often want to build applications where the user expects their actions won't be reordered. The key being they don't expect their actions to be reordered. In most systems this is trivially handled by logging event time as seen from the users system and ensure the user sees a consistent view of their own operations . There are exceptions, naturally, but the point is not that yo…

> Your privacy settings is a local concern to your account, it most certainly does not need to be globally consistent. All you need to do to avoid problems with that is to ensure consistency in routing requests for a given session, and enforce local consistency of ordering within a given user account or session depending on requirements. I think you're misunderstanding what the problem is here. I want global consiste…

> I think you're misunderstanding what the problem is here. I want global consistency (really I want two party consistency) to prevent the said user from witnessing the unkind thing I posted about them.

You don't want global consistency and you're saying it yourself.

What you want is to be presented with a view that is consistent with the actions you've done. [it's really basics101 for user experience.]

The internals of the system don't matter to you. It only matter to us, as the builders. We can make it so that it is internally 'inconsistent'[0] yet it always presents a 'consistent'[0] view to the user.

[0] I don't think the word consistent describes well the situation. Nothing is ever strictly perfectly consistent.

Re: Consistency is Consistently Undervalued

#105

Post by user5994461 » Sat, Sep 17, 2016, 8:32 PM UTC

superuser2 wrote: post #103

vidarh wrote: post #25

My opinion is exactly opposite: Consistently is overvalued. Requiring consistency in distributed system generally leads to designs that reduces availability. Which is one of the reasons that bank transactions generally do not rely on transactional updates against your bank. "Low level" operations as part of settlement may us transactions, but the bank system is "designed" (more like it has grown by accretion) to func…

>designs that reduces availability. It's a slimy abuse of language to call a service "available" when it's giving incorrect output and corrupting its persistent state. I can write a program with lots of nines that is blazingly faster than its competitors if its behavior is allowed to be incorrect.

> I can write a program with lots of nines that is blazingly faster than its competitors if its behavior is allowed to be incorrect.

Congratulations! You just understood distributed systems, or put more simply the real world of app development.

Most of the programs in the real world ARE allowed to be incorrect at times.

Corollary: Most of the programs in the real world do NOT need to be correct every single time.

These statements should be on top of system design and requirement gathering classes.

Re: Consistency is Consistently Undervalued

#106

Post by knucklesandwich » Sat, Sep 17, 2016, 8:48 PM UTC

user5994461 wrote: post #104

knucklesandwich wrote: post #82

Earlier quoted context omitted.

> Your privacy settings is a local concern to your account, it most certainly does not need to be globally consistent. All you need to do to avoid problems with that is to ensure consistency in routing requests for a given session, and enforce local consistency of ordering within a given user account or session depending on requirements. I think you're misunderstanding what the problem is here. I want global consiste…

> I think you're misunderstanding what the problem is here. I want global consistency (really I want two party consistency) to prevent the said user from witnessing the unkind thing I posted about them. You don't want global consistency and you're saying it yourself. What you want is to be presented with a view that is consistent with the actions you've done. [it's really basics101 for user experience.] The internals…

You seem to be assuming that I'm a UX designer. I'm not, I'm a backend engineer. Just a note though: I wouldn't say something like "The internals of the system don't matter to you. It only matter to us, as the builders." to a UX designer, since that's super condescending.

Sequential consistency is basically the most lax model you can get away with in this case (and have it generalize to other similar operations). This is a very strong consistency model and weakening linearizability to this basically provides no advantage for availability. There is a proof that anything stronger than causal consistency cannot provide "total availability", which I'd argue is somewhat mythical anyways (except when you're colocated with where data is being stored).

My point here is that this is clearly a case where many of the strongest ordering guarantees are required to get the desired behavior, and subsequently availability must be sacrificed.

Re: Consistency is Consistently Undervalued

#107

Post by user5994461 » Sat, Sep 17, 2016, 9:16 PM UTC

knucklesandwich wrote: post #106

user5994461 wrote: post #104

Earlier quoted context omitted.

> I think you're misunderstanding what the problem is here. I want global consistency (really I want two party consistency) to prevent the said user from witnessing the unkind thing I posted about them. You don't want global consistency and you're saying it yourself. What you want is to be presented with a view that is consistent with the actions you've done. [it's really basics101 for user experience.] The internals…

You seem to be assuming that I'm a UX designer. I'm not, I'm a backend engineer. Just a note though: I wouldn't say something like "The internals of the system don't matter to you. It only matter to us, as the builders." to a UX designer, since that's super condescending. Sequential consistency is basically the most lax model you can get away with in this case (and have it generalize to other similar operations). Thi…

I was making the distinction on being the user VS being the builder of the system. The user doesn't need to know or understand the internals.

> consistency... consistency... consistency

What if I am not aiming for consistency in the first place?

We both understand that "total availability" is mythical. So why not target partial availability in the first place?

Re: Consistency is Consistently Undervalued

#108

Post by wpietri » Sat, Sep 17, 2016, 9:32 PM UTC

knucklesandwich wrote: post #95

wpietri wrote: post #92

Earlier quoted context omitted.

Do you really need global consistency for that? I think you can get by with user-consistent ordering as long as your data model's right. It sounds like you're saying that the friend-state for a given post are part of the permissions for the post, and therefore part of the post itself. In which case, when a user posts, I'd include the version number of their friend-state in the post's permissions. Then on view attempt…

There are definitely solutions for handling this with consistency semantics that are something weaker than linearizable consistency. But they usually become expensive in other ways and loose a lot of the availability benefits to recover the consistency properties you do need. Most of the models we're even talking about here are something in the realm of sequential or causal consistency, which are still considered str…

Do you perhaps have a different example that might make the problem more apparent here? Because if I post something you don't want to see, give you permission to see it, and then take it away again, I can live with you seeing it. I probably won't even know if you saw it because there was some sort of system glitch or if you just happened to look during friend state 2.

Re: Consistency is Consistently Undervalued

#109

Post by betenoire » Sat, Sep 17, 2016, 9:52 PM UTC

knucklesandwich wrote: post #95

wpietri wrote: post #92

Earlier quoted context omitted.

Do you really need global consistency for that? I think you can get by with user-consistent ordering as long as your data model's right. It sounds like you're saying that the friend-state for a given post are part of the permissions for the post, and therefore part of the post itself. In which case, when a user posts, I'd include the version number of their friend-state in the post's permissions. Then on view attempt…

There are definitely solutions for handling this with consistency semantics that are something weaker than linearizable consistency. But they usually become expensive in other ways and loose a lot of the availability benefits to recover the consistency properties you do need. Most of the models we're even talking about here are something in the realm of sequential or causal consistency, which are still considered str…

I'm seeing a lot of comments that are basically saying, "we don't need no stinking transactions because we can mostly reinvent them in the app." And the point of the article was, yeah, or you could pick a solution that already solves this.

Re: Consistency is Consistently Undervalued

#110

Post by knucklesandwich » Sat, Sep 17, 2016, 9:52 PM UTC

user5994461 wrote: post #107

knucklesandwich wrote: post #106

Earlier quoted context omitted.

You seem to be assuming that I'm a UX designer. I'm not, I'm a backend engineer. Just a note though: I wouldn't say something like "The internals of the system don't matter to you. It only matter to us, as the builders." to a UX designer, since that's super condescending. Sequential consistency is basically the most lax model you can get away with in this case (and have it generalize to other similar operations). Thi…

I was making the distinction on being the user VS being the builder of the system. The user doesn't need to know or understand the internals. > consistency... consistency... consistency What if I am not aiming for consistency in the first place? We both understand that "total availability" is mythical. So why not target partial availability in the first place?

I'm not saying you should not have availability. On the contrary, many strongly consistent algorithms actually have very good availability characteristics. The whole point of being distributed is often to increase availability. Algorithms like raft and multi-paxos can provide availability so long as a majority of nodes remain reachable to the client, which I think is pretty acceptable in many cases. This is sort of why the availability vs consistency dichotomy is a false dilemma. Sure, having linearizability means you cannot have total availability and vice versa, but generally you can have very good availability and preserve strongly consistent semantics. What I disagree with is that trading strong consistency to achieve total availability is useful in many domains. To be fair, there are some, and for write-heavy workloads that tend to materialize a readable view in the future or for things like immutable caches, it can be extremely useful to weaken consistency, I just have often found that for the bulk of business logic, weaker consistency semantics make unacceptable tradeoffs to users.