Comments on: On Eventual Consistency– An interview with Justin Sheehy. http://www.odbms.org/blog/2012/08/on-eventual-consistency-an-interview-with-justin-sheehy/ Trends and Information on Big Data, New Data Management Technologies, and Innovation. Wed, 17 Apr 2013 21:47:18 +0000 hourly 1 http://wordpress.org/?v=3.1.1 By: Reinhold Thurner, http://www.odbms.org/blog/2012/08/on-eventual-consistency-an-interview-with-justin-sheehy/comment-page-1/#comment-7445 Reinhold Thurner, Sun, 02 Sep 2012 09:55:56 +0000 http://www.odbms.org/blog/?p=1671#comment-7445 On "banking and eventual consistency": I was directly involved in the payment system of a bank and must say that "eventual consistency" would certainly not be an option. I am used to look at subjects from a conceptual view of the "things" and their relationship (no surprise – since my primary interest is Metasafe): A funds transfer affects four accounts (mine, myBanks, hisBanks, his), a payment order and needs three consistent transactions – independent whether it is made by a computer or manually on paper. I wonder if "eventual consistency" means AeCID or AID or just D? I always thought that a system is either ACID or it is not (like being pregnant). Michael Stonebraker says (and explains) in his keynote (http://www.youtube.com/watch?v=uhDM4fcI2aI) on NewOLTP and NewSQL – that "eventual consistency may create garbage". In this presentation Michael uses the term "newSQL" as a name for the architecture of an in core relational DBMS in contrast to the in core emulation of a disk based relational DBMS. It is not that: "The “NewSQL” term is, much like “NoSQL”, a marketing term that doesn’t usefully define a technical category". "Precisely where concepts fail you, A timely word will come to mind." (GOETHE, Faust I:1995–1996). Fiddling with words can create the impression (for users) that ACID may be turned into a sort of jelly and endanger our credibility. I can accept that a superior level of availability means no guaranteed consistency. We have to accept that "One size does not fit all" (Stonebraker). A taxonomy (see page 189 in the paper of David Maier http://www.odbms.org/download/clouddbms2011.pdf) and a true and fair description about the properties and tradeoffs would help to position new solutions and to make the right choice in any given situation. On “banking and eventual consistency”:
I was directly involved in the payment system of a bank and must say that “eventual consistency” would certainly not be an option. I am used to look at subjects from a conceptual view of the “things” and their relationship (no surprise – since my primary interest is Metasafe): A funds transfer affects four accounts (mine, myBanks, hisBanks, his), a payment order and needs three consistent transactions – independent whether it is made by a computer or manually on paper.

I wonder if “eventual consistency” means AeCID or AID or just D? I always thought that a system is either ACID or it is not (like being pregnant). Michael Stonebraker says (and explains) in his keynote (http://www.youtube.com/watch?v=uhDM4fcI2aI) on NewOLTP and NewSQL – that “eventual consistency may create garbage”.

In this presentation Michael uses the term “newSQL” as a name for the architecture of an in core relational DBMS in contrast to the in core emulation of a disk based relational DBMS. It is not that: “The “NewSQL” term is, much like “NoSQL”, a marketing term that doesn’t usefully define a technical category”.

“Precisely where concepts fail you, A timely word will come to mind.” (GOETHE, Faust I:1995–1996). Fiddling with words can create the impression (for users) that ACID may be turned into a sort of jelly and endanger our credibility. I can accept that a superior level of availability means no guaranteed consistency. We have to accept that “One size does not fit all” (Stonebraker). A taxonomy (see page 189 in the paper of David Maier http://www.odbms.org/download/clouddbms2011.pdf) and a true and fair description about the properties and tradeoffs would help to position new solutions and to make the right choice in any given situation.

]]> By: Mirco Bianco http://www.odbms.org/blog/2012/08/on-eventual-consistency-an-interview-with-justin-sheehy/comment-page-1/#comment-7444 Mirco Bianco Sat, 01 Sep 2012 17:23:13 +0000 http://www.odbms.org/blog/?p=1671#comment-7444 In my opinion, the distinguishing feature of Riak is the soft real-time as evidenced in Q7. Riak, due to its soft real-time capabilities, could be also employed in financial applications like financial intelligence applications, wherein it necessary to fulfill time-contraints imposed by the stock markets in order to success in the business. This is probably done by Trifork (https://www.trifork.com/), one of the Basho's customers. Correct? In my opinion, the distinguishing feature of Riak is the soft real-time as evidenced in Q7. Riak, due to its soft real-time capabilities, could be also employed in financial applications like financial intelligence applications, wherein it necessary to fulfill time-contraints imposed by the stock markets in order to success in the business. This is probably done by Trifork (https://www.trifork.com/), one of the Basho’s customers. Correct?

]]>