The notion "eventual consistency" is bogus to me, in my mind, either it's consistent or it is not. Full stop. Which is not to say that consistency is always a requirement, there are many cases where you can do without it. But do not think that "eventual consistency" is a kind of "relaxed consistency", rather it is a lack of consistency.
Look, any kind of distributed system could claim to have "eventual consistency", in the meaning that at some point, things will be consistent. Eventual consistency does not mean that we know when things will be consistent at some known point in time. Frankly, not even if all the involved servers in a distributed system claiming "eventual consistency" would stop at the same time, would the data be consistent. But there is a way o achieve consistency: If all the application transactions running were allowed to stop in a controlled manner, and all operations are then stopped, then data should, I guess, be consistent. So is it consistent then?
Well, the system as a whole may well be, but this consistency isn't an aspect of the systems that claims to provide eventual consistency, rather this is the attribute of things as a whole. Or in other words, these servers don't provide consistency, rather they put that burden on someone else. And even that consistency is "eventual", whatever that means. But that is fine too.
Look. if I put $500 into my bank account, and I realize that only $300 was added, the explanation thar "it will get the eventually" wil not work with me at least. On the other hand, if I post a message on Facebook and I see the message as being sent, but the receiver hasn't seen it in the exact same instant, well than I don't care, even if I knew it, which I usually don't.
But in the latter case, if the Facebook message operation really was consistent, would that hurt me? The answer is no, of course. But if the overhead of making that operations in terms of performance was enormous, would that hurt me? And the answer is yes.
So, consistency is something we actually want, and eventual consistency is a comprimise that is good enough in some cases, where the performance impact of real consistency is too high. And will performance in system stay the way they are right now, and will the cost per performed consisten transaction stay the same? No, it will be lower. So there will, in time, be less reasons for not using a fully consistent system. But there will always be the case where performance requirements are really high, or developers has been sloppy or something, where a comprimise is what is needed. Which is fine with me.
If a driver on the road has his car swaying back and forth across the lanes, he will probably get caught by the police eventually. And the explanation that he was in the middle lane "eventually" will probably not work for him or her.
On the other hand, use the right tool for the job. If you need something done with the absolutely minimal overheadm and can do with the odd compromize, then fine. But don't fool yourself into thinking that you are not compromising by using 1984'ish newspeak.
/Karlsson
11 comments:
My stepdad used to tell me "You can put it off until tomorrow, but tomorrow never comes". I think about this every time someone talks about eventual consistency, because honestly, eventually never comes.
"And will performance in system stay the way they are right now, and will the cost per performed consistent transaction stay the same? No, it will be lower."
Agreed. The costs will decrease. However, the performance demands seem to be increasing at a much faster rate than the cost decreases. More users, more traffic, more data, more analysis. Is it possible that soon most jobs will require this tool and this compromise?
-Lee
Lee!
That is hardly a likely scenario. I don't think that people have that much bandwidth to interact with more than a few facebooks on average. And it's the facebooks of this world that benefits.
And that performance requirements are increasing faster I'm not so sure about. What we ARE seeing are site with a much wider audience, but also many specialized environments.
And another question to ask yourself when considering a non-consistent environment is what you are sacrificing? Can you do with non-consistent data? Really? I'm not so sure that has been thought about by everyone who has made the non-consistency compromise.
There are countries where if you pay me 500$ today, it will disappear from your bank account now, but it will only appear in my bank account days later. It does eventually get there, but in the few days in between, the banks save a little interest, which accumulates to huge amounts annually. (But I forgot which country this is. I bet USA is like this, with checks and everything?)
Henrik,
That does indeed happen in the USA, but that's not quite the same thing. In that case there are (at least) two *consistent* transactions, one from your account to a grouped reconciliation account, and another from that account to the destination account.
Regards,
Jeremy
Jeremy's right. Delay of the transfer to the final account is not at all like eventual consistency.
The problem I have with the eventual consistency concept is that it makes itself immune to bugs. If there is no way to say how long it'll take before the database will be in a consistent state, and at some point you find that the database is not in a consistent state, then you can always claim that some time later, it will be consistent. I don't see how this would allow one to distinguish between a bug that actually prevents the data from being consistent and the normal operation, where it will just take a while longer before things will be consistent.
(Or perhaps I am not understanding something about this eventual consistency concept)
Roland / Jeremy!
"Eventual" is in my bad as it means "I don't know". Banks, as I used as an example, ir probably a bad example, as although consistency isn't always imminent, there are "consistency points" defined, and one will know when, within limits, when consistency is achieved.
And Roland makes a good point: Ot is difficult, or even impossible, to tell the difference between inconsistency as the cause of a big and inconsistency as a result of "enevtual consistency".
/Karlsson
I don't really understand the objection to eventual consistency. Most people using it in distributed systems are perfectly aware that they are trading temporary inconsistency across copies for service availability. For example, would you rather have a debit card processor refuse transactions because there's a partition between sites somewhere or a master host is down? That's the price of requiring complete consistency.
@Roland / Andres
Since my other half and her team now work on eventually consistent algorithms, I asked their opinion on this, and I hope to post a guest-article by one of them.
As I understand it, the description in this post is misleading. It's true that at any given moment the system may be inconsistent. But an eventual consistent algorithm will allow you to *demand consistency*. So, if you really want to know your bank account status, you can demand to have consistency for that data. You will then pose locks and blocks until this particular data becomes consistent throughout the system.
So, you can have your consistency.
Anyway, I know little of this; like I said, I hope to have someone write on this.
Following up on Shlomi's comment, eventual consistency is not arbitrary. Workable implementations use semantics like causal dependency which means that if I do updates 1 and 2 in that order on a node they will reach other nodes in the same order regardless of intervening failures or other transactions. Also, the only time you can't test the eventual consistency part is when you have failed nodes (which is the point, BTW). Otherwise, correct eventual consistency implementations converge within a bounded period of time--if they don't that's a bug.
Shlomi, Robert - thanks for pointing this out - it seems I am indeed not understanding the eventual consistency concept, or at least my grasp of it is incomplete.
I shall try and find some papers to read to gain better understanding.
Thanks again, and kind regards,
Roland Bouman
Post a Comment