{"id":1782,"date":"2012-10-23T11:10:06","date_gmt":"2012-10-23T11:10:06","guid":{"rendered":"http:\/\/www.odbms.org\/blog\/?p=1782"},"modified":"2012-10-23T11:10:06","modified_gmt":"2012-10-23T11:10:06","slug":"on-eventual-consistency-interview-with-monty-widenius","status":"publish","type":"post","link":"https:\/\/www.odbms.org\/blog\/2012\/10\/on-eventual-consistency-interview-with-monty-widenius\/","title":{"rendered":"On Eventual Consistency– Interview with Monty Widenius."},"content":{"rendered":"

\u201cFor analytical things, eventual consistency is ok (as long as you can know after you have run them if they were consistent or not). For real world involving money or resources it’s not necessarily the case.\u201d<\/em> — Michael \u201cMonty\u201d Widenius.<\/strong><\/p>\n

In a recent interview, I asked Justin Sheehy<\/a>, Chief Technology Officer at Basho Technologies, maker of Riak<\/a>, the following two questions, related to the subject of eventual consistency<\/strong>:<\/p>\n

Q1. “How do you handle updates if you do not support ACID<\/a> transactions? For which applications this is sufficient, and when this is not?”<\/em><\/p>\n

Q2. “You said that Riak takes more of the \u201cBASE\u201d <\/a> (Basically Available, Soft state, Eventual consistency) approach. Did you use the definition of eventual consistency by Werner Vogels<\/a>? Reproduced here: \u201cEventual consistency: The storage system guarantees that if no new updates are made to the object, eventually (after the inconsistency window closes) all accesses will return the last updated value.”
\nYou would not wish to have an \u201ceventual consistency\u201d update to your bank account. For which class of applications is eventual consistency a good system design choice? “<\/em><\/p>\n

On the same subject, I did a follow up interview with Michael \u201cMonty\u201d Widenius<\/strong>, the main author of the original version of the open-source MySQL<\/a> database, and currently working on a branch of the MySQL code base, called MariaDB<\/a>.<\/p>\n

RVZ<\/p>\n

Q.<\/strong> Justin Sheehy`s reply to Q1<\/strong>: \u201cRiak takes more of the \u201cBASE\u201d approach, which has become accepted over the past several years as a sensible tradeoff for high-availability data systems. By allowing consistency guarantees to be a bit flexible during failure conditions, a Riak cluster is able to provide much more extreme availability guarantees than a strictly ACID system.”<\/em>
\nWhen do you think a \u201cBASE\u201d approach to consistency is justified?<\/strong><\/p>\n

\u201cMonty\u201d Widenius: <\/strong> The big questions are:
\na) How are conflict’s solved? Who will win when there are conflicting updates on two nodes and the communication between the nodes are temporarily down?
\nb) Can a user at any point read data that is not consistent?
\nc) How long can the conflicting window be?<\/p>\n

The answers to the above questions tells us how suitable the solution is for different applications. For analytical things, eventual consistency is ok (as long as you can know after you have run them if they were consistent or not). For real world involving money or resources it’s not necessarily the case.<\/p>\n

Q.<\/strong> How do you handle consistency in MariaDB and at the same time ensuring scalability and availability? Aren’t you experiencing the limitations of the CAP Theorem<\/a>?<\/strong><\/p>\n

\u201cMonty\u201d Widenius:<\/strong> We are using the traditional approaches with transactions or synchronous replication when you need guaranteed consistent answers.<\/p>\n

We also provide asynchronous updates to slaves when you can tolerate a log for the data on the slaves. However, as we are only making things visible when the total transaction is run on either master\/slave you have always things consistent.<\/p>\n

So when it comes to CAP, it’s up the user to define where he wants to have his tradeoff; Speed, reliability or easy to manage.<\/p>\n

Q.<\/strong> Justin Sheehy`s reply to Q2: <\/strong>“That definition of Eventual Consistency certainly does apply to Riak, yes. I would most certainly include updates to my bank account as applications for which eventual consistency is a good design choice. In fact, bankers have understood and used eventual consistency for far longer than there have been computers in the modern sense. Traditional accounting is done in an eventually-consistent way and if you send me a payment from your bank to mine then that transaction will be resolved in an eventually consistent way. That is, your bank account and mine will not have a jointly-atomic change in value, but instead yours will have a debit and mine will have a credit, each of which will be applied to our respective accounts.\u201d<\/em><\/p>\n

\u201cMonty\u201d Widenius:<\/strong> The question is time spent between the consistency and where things will be inconsistent. For example, at no point in time should there be more money on my account than I have the right to use.
\nThe reason why banks in the past have been using eventual consistency is that the computer systems on the banks simply has not kept up with the rest of the word.
\nIn many places there is still human interaction needed to get money on the account! (especially for larger amounts).
\nStill, if you ask any bank, they would prefer to have things always consistent if they could!<\/p>\n

Q. <\/strong>Justin says that <\/strong>\u201cthis question contains a very commonly held misconception. The use of eventual consistency in well-designed systems does not lead to inconsistency. Instead, such systems may allow brief (but shortly resolved) discrepancies at precisely the moments when the other alternative would be to simply fail\u201d.<\/em><\/p>\n

\u201cMonty\u201d Widenius: <\/strong> In some cases it’s better to fail. For example it’s common that ATM will not give out money when the line to the bank account is down. Giving out money is probably always the wrong choice. The other question is if things are 100 % guaranteed to be consistent down to the millisecond during normal operations.<\/p>\n

Q.<\/strong> Justin says: <\/strong> \u201cto rephrase your statement, you would not wish your bank to fail to accept a deposit due to an insistence on strict global consistency.\u201d<\/em><\/p>\n

\u201cMonty\u201d Widenius: <\/strong> Actually you would, if you can’t verify the identity of the user. Certainly the end user would not want to have the deposit be accepted if there is only a record in a single place of the deposit.<\/p>\n

Q.<\/strong> Justin says:<\/strong> \u201dIt is precisely the cases where you care about very high availability of a distributed system that eventual consistencymight be a worthwhile tradeoff.\u201d<\/em>
\nWhat is your take on this? Is Eventual Consistency a valid approach also for traditional banking applications?<\/strong><\/p>\n

\u201cMonty\u201d Widenius: <\/strong>That is what banks have traditionally used. However, if they would have a choice between eventual consistency and always consistent they would always choose the later if it would be possible within their resources.<\/p>\n

———————
\nMichael \u201cMonty\u201d Widenius<\/a><\/strong> is the main author of the original version of the open-source MySQL database and a founding member of the MySQL AB company. Since 2009, Monty is working on a branch of the MySQL code base, called MariaDB<\/a>.<\/p>\n

Related Posts<\/strong><\/p>\n

On Eventual Consistency\u2013 An interview with Justin Sheehy.<\/a><\/strong> by Roberto V. Zicari, August 15, 2012<\/p>\n

MariaDB: the new MySQL? Interview with Michael Monty Widenius.<\/a><\/strong> by Roberto V. Zicari on September 29, 2011<\/p>\n

##<\/p>\n","protected":false},"excerpt":{"rendered":"

\u201cFor analytical things, eventual consistency is ok (as long as you can know after you have run them if they were consistent or not). For real world involving money or resources it’s not necessarily the case.\u201d — Michael \u201cMonty\u201d Widenius. In a recent interview, I asked Justin Sheehy, Chief Technology Officer at Basho Technologies, maker […]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":[],"categories":[1],"tags":[5,6,35,57,59,66,89,328,357,382,395,412,413,446,502],"_links":{"self":[{"href":"https:\/\/www.odbms.org\/blog\/wp-json\/wp\/v2\/posts\/1782"}],"collection":[{"href":"https:\/\/www.odbms.org\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.odbms.org\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.odbms.org\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.odbms.org\/blog\/wp-json\/wp\/v2\/comments?post=1782"}],"version-history":[{"count":0,"href":"https:\/\/www.odbms.org\/blog\/wp-json\/wp\/v2\/posts\/1782\/revisions"}],"wp:attachment":[{"href":"https:\/\/www.odbms.org\/blog\/wp-json\/wp\/v2\/media?parent=1782"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.odbms.org\/blog\/wp-json\/wp\/v2\/categories?post=1782"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.odbms.org\/blog\/wp-json\/wp\/v2\/tags?post=1782"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}