<html><head>

 And the API doesn’t allow user to specify WRITE consistency level.</div><div><br></div><div><a href="http://www.allthingsdistributed.com/2012/01/amazon-dynamodb.html">http://www.allthingsdistributed.com/2012/01/amazon-dynamodb.html</a></div><div><br></div><div>Considering the above factors and what Cassandra’s capabilities, I propose we use the following model. </div><div><br></div><div>READ: </div><ul><li>Strong consistency (synchronously replicate to all, maps to Cassandra READ All consistency level) </li><li>Eventual consistency (quorum read, maps to Cassandra READ Quorum)</li><li>Weak consistency (not in DynamoDB, maps to Cassandra READ ONE)</li></ul><div>WRITE:</div><ul><li>Strong consistency (synchronously replicate to all, maps to Cassandra WRITE All consistency level) </li><li>Eventual consistency (quorum write, maps to Cassandra WRITE Quorum)</li><li>Weak consistency (not in DynamoDB, maps to Cassandra WRITE ANY)</li></ul><div>For conditional writes (conditional putItem/deletItem), only strong and eventual consistency should be supported.</div><div><br></div><div>Thoughts?</div><div><br></div><div>Thanks,</div><div><br></div><div>Charles</div><div><br></div><span id="OLK_SRC_BODY_SECTION"><div style="font-family:Calibri; font-size:11pt; text-align:left; color:black; BORDER-BOTTOM: medium none; BORDER-LEFT: medium none; PADDING-BOTTOM: 0in; PADDING-LEFT: 0in; PADDING-RIGHT: 0in; BORDER-TOP: #b5c4df 1pt solid; BORDER-RIGHT: medium none; PADDING-TOP: 3pt"><span style="font-weight:bold">From: </span>Dmitriy Ukhlov <<a href="mailto:dukhlov@mirantis.com">dukhlov@mirantis.com</a>><br><span style="font-weight:bold">Reply-To: </span>"OpenStack Development Mailing List (not for usage questions)" <<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>><br><span style="font-weight:bold">Date: </span>Tuesday, April 29, 2014 at 10:43 AM<br><span style="font-weight:bold">To: </span>Illia Khudoshyn <<a href="mailto:ikhudoshyn@mirantis.com">ikhudoshyn@mirantis.com</a>><br><span style="font-weight:bold">Cc: </span>"OpenStack Development Mailing List (not for usage questions)" <<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>><br><span style="font-weight:bold">Subject: </span>Re: [openstack-dev] [MagnetoDB] Configuring consistency draft of concept<br></div><div><br></div><div dir="ltr"><div><div>Hi Illia,<br>

WEAK/QUORUM instead of true/false it is ok for me.<br><br></div><div>But we have also STRONG.<br><br></div><div>What does STRONG mean? In current concept we a using QUORUM and say that it is strong. I guess it is confusing (at least for me) and can have different behavior for different backends.<br><br></div><div>I believe that from user point of view only 4 usecases exist: write and read with consistency or not.<br></div><div>For example if we use QUORUM for write what is usecase to use read with STRONG one? QUORUM read is enought to get consistent data. Or if we use WEAK (ONE) for consistent write what is the use case to use read from QUORUM? we need to read from ALL.<br><br></div><div>But we can to use different kinds of backend's abilities to implement consistent and incosistent operation. To provide the best flexibility of backend  specific features I propose to use backend specific configuration section in table schema. In this case

 you can get much more then in initial concept. For example specify consistensy level ANY instead of ONE for WEAK consistency if you want concentrate on performance of TWO if you want to provide more fault tolerant behavior.<br><br></div><div>With my proposal we will have only one limitation in comparison with first proposal - We have

<span id="result_box" class="" lang="en"><span class="">maximally </span></span>flexible consistency, but  per table, not per request. We have only 2 choices to specify consistensy per request (true or false). But I believe that it is enough to cover user usecases<br></div><div><br></div></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Tue, Apr 29, 2014 at 6:16 AM, Illia Khudoshyn <span dir="ltr">

<<a href="mailto:ikhudoshyn@mirantis.com" target="_blank">ikhudoshyn@mirantis.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div>Hi all,<br><br></div>

Dima, I think I understand your reasoning but I have some issues with that. I agree that binary logic is much more straightforward and easy to understand and use. But following that logic, having the only one hardcoded consistency level is even easier and more

 understandable. <br>

As I can see, the idea of the proposal is to provide user a more fine-grained control on consistency to leverage backend features AND at the same time to not bound ourselves with only this concrete backend's features. In scope of Maksym's proposal choice between

 WEAK/QUORUM for me is pretty much the same as your FALSE/TRUE. But I'd prefer to have more.<br><br></div>

PS Eager to see your new index design<br></div><div class="gmail_extra"><div><div class="h5"><br><br><div class="gmail_quote">On Tue, Apr 29, 2014 at 7:44 AM, Dmitriy Ukhlov <span dir="ltr">

<<a href="mailto:dukhlov@mirantis.com" target="_blank">dukhlov@mirantis.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div><div><div><div><div><br></div>

Hello Maksym,<br><br></div>

Thank you for your work!<br><br></div>

I suggest you to consider more general approach and hide backend specific staff. I have the next proposal:<br></div>

1) add support for inconsistent write operation by adding PutItem, UpdateItem and DeleteItem request parameters "consistent" = True of False (as well as GetItem and Query requests)

<br></div>

2) add possibility to set backend specific metadata (it would be nice to use some generic format like json) per table in scope of create table request. I suggest to specify mapping for Cassandra consistency level per operation type (consistent read, inconsistent

 read, consistent write, inconsistent write)<br><br></div>

I agree that now we have a limitation for inconsistent write operation on tables with indexed fields and for requests with specified expected conditions. I have thought about how to overcome this limitation and it seems that I found out solution for index handling

 without CAS operation. And maybe it is reasonable to redesign it a bit.<br><br><div><div><div><div><div><div class="gmail_extra"><div class="gmail_quote"><div><div>On Mon, Apr 28, 2014 at 8:33 AM, MAKSYM IARMAK (CS) <span dir="ltr"><<a href="mailto:Maksym_Iarmak@symantec.com" target="_blank">Maksym_Iarmak@symantec.com</a>></span> wrote:<br></div></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div><div><div style="direction:ltr;font-size:x-small;font-family:Tahoma"><div><font face="Times New Roman" size="3">Hi,</font></div><div><font face="Times New Roman" size="3"></font> </div><div><font face="Times New Roman" size="3">Because of we can't use inconsistent write if we use indexed table and condition operations which indexes based on (this staff requires the state of data), we have one more issue.</font></div><div><font face="Times New Roman" size="3"></font> </div><div><font face="Times New Roman" size="3">If we want to make write with consistency level ONE (WEAK) to the indexed table, we will have 2 variants:</font></div><div><font face="Times New Roman" size="3">1. Carry out the operation successfully and implicitly make write to the indexed table with minimally possible consistency level for it (QUORUM);</font></div><div><font face="Times New Roman" size="3">2. Raise an exception, that we can not perform this operation and list all possible CLs for this operation.</font></div><div><font face="Times New Roman" size="3"></font> </div><div><font face="Times New Roman" size="3">I personally prefer the 2nd variant. So, does anybody have some objections or maybe another ideas?</font></div><div dir="ltr"><font color="#000000" face="Times New Roman" size="3"></font> </div><div style="DIRECTION:ltr"><font face="Times New Roman" size="3"><hr></font><font color="#000000" face="Tahoma"><b>From:</b> MAKSYM IARMAK (CS) [<a href="mailto:Maksym_Iarmak@symantec.com" target="_blank">Maksym_Iarmak@symantec.com</a>]<br><b>Sent:</b> Friday, April 25, 2014 9:14 PM<br><b>To:</b> <a href="mailto:openstack-dev@lists.openstack.org" target="_blank">openstack-dev@lists.openstack.org</a><br><b>Subject:</b> [openstack-dev] [MagnetoDB] Configuring consistency draft of concept<br></font><br></div><div><div></div><div><div style="direction:ltr;font-size:x-small;font-family:Tahoma"><div><font size="4">>So, here is specification draft of concept.</font></div></div></div></div></div></div><br></div></div>

_______________________________________________<br>

OpenStack-dev mailing list<br><a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.org</a><br><a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br><br></blockquote></div><span><font color="#888888"><br><br clear="all"><br>

-- <br><div dir="ltr"><div><div>Best regards,<br></div>

Dmitriy Ukhlov<br></div>

Mirantis Inc.<br></div></font></span></div></div></div></div></div></div></div></blockquote></div><br><br clear="all"><br></div></div>

-- <br><div dir="ltr"><p style="margin:0in 0in 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif">

Best regards,</p><p style="margin:0in 0in 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif">

Illia Khudoshyn,<br>

Software Engineer, Mirantis, Inc.</p><p style="margin:0in 0in 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif">

 </p><p style="margin:0in 0in 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif">

38, Lenina ave. Kharkov, Ukraine</p><p style="margin:0in 0in 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif"><span style="font-size: 10pt; font-family: Arial, sans-serif; color: rgb(136, 136, 136);"><a href="http://www.mirantis.ru/" style="color:rgb(17,85,204)" target="_blank">www.mirantis.com</a></span></p><p style="margin:0in 0in 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif"><span style="font-size: 10pt; font-family: Arial, sans-serif; color: rgb(136, 136, 136);"><a href="http://www.mirantis.ru/" style="color:rgb(17,85,204)" target="_blank">www.mirantis.ru</a></span></p><p style="margin:0in 0in 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif"><span style="font-size: 10pt; font-family: Arial, sans-serif; color: rgb(136, 136, 136);"> </span></p><p style="margin:0in 0in 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif"><span style="font-size:11pt">Skype: gluke_work</span><br></p><p style="margin:0in 0in 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif"><span style="font-size: 10pt; font-family: Arial, sans-serif; color: rgb(136, 136, 136);"><a href="mailto:ikhudoshyn@mirantis.com" style="color:rgb(17,85,204)" target="_blank">ikhudoshyn@mirantis.com</a></span></p></div></div></blockquote></div><br><br clear="all"><br>

-- <br><div dir="ltr"><div><div>Best regards,<br></div>

Dmitriy Ukhlov<br></div>

Mirantis Inc.<br></div></div></span></div></div></span></body></html>