Mailing-List: contact commits-help@cassandra.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cassandra.apache.org
Date: Thu, 16 Feb 2017 19:38:42 +0000 (UTC)
From: "Connor Warrington (JIRA)" <jira@apache.org>
To: commits@cassandra.apache.org
Message-ID: <JIRA.13043345.1487185594000.102843.1487273922103@Atlassian.JIRA>
In-Reply-To: <JIRA.13043345.1487185594000@Atlassian.JIRA>
References: <JIRA.13043345.1487185594000@Atlassian.JIRA> <JIRA.13043345.1487185594594@jira-lw-us.apache.org>
Subject: [jira] [Commented] (CASSANDRA-13225) Best Consistency Level
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
archived-at: Thu, 16 Feb 2017 19:38:48 -0000


    [ https://issues.apache.org/jira/browse/CASSANDRA-13225?page=3Dcom.atla=
ssian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=
=3D15870573#comment-15870573 ]=20

Connor Warrington commented on CASSANDRA-13225:
-----------------------------------------------

Looks like this JIRA ticket is what I should be looking at: https://issues.=
apache.org/jira/browse/CASSANDRA-9318

> Best Consistency Level
> ----------------------
>
>                 Key: CASSANDRA-13225
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-1322=
5
>             Project: Cassandra
>          Issue Type: New Feature
>            Reporter: Connor Warrington
>            Priority: Minor
>
> When writing data into a cluster there are a few consistency levels to ch=
oose from. When choosing the consistency level to write with you are making=
 a tradeoff between consistency and failover availability. If you choose co=
nsistency level ALL then all replicas have to be up and when a write succee=
ds all replicas received the write. If you choose consistency level QUORUM =
then a quorum number of replicas have to be up and when a write succeeds at=
 quorum number of replicas received the write. The tradeoff comes in when t=
here are more then quorum nodes available for the write. We would like a wr=
ite to succeed only when all replicas that are up have received the write. =
Hence the suggestion of best as a consistency level. This would be availabl=
e for the existing consistency levels. The main idea behind this feature re=
quest is that we are okay with a replica going down (fault tolerance) but w=
hen the cluster is in a good state we don't mind waiting for all nodes to g=
et the write. This would enable the writer to operate at speed of the slowe=
st node instead of potentially getting into a state where that slow node ge=
ts even further behind. This would also enable back pressure to be better p=
ropagated through the system as the slowest node likely has back pressure w=
hich is trying to tell the client about but if we don't wait for that node =
the writer loses that information.
> Example scenarios:
> If we have replication factor of 3:=20
> ALL consistency means 3 replicas have to be up and 3 replicas have to suc=
cessfully get the write.=20
> QUORUM consistency means 2 replicas have to be up and 2 replicas have to =
successfully get the write.=20
> BEST_QUORUM consistency means 2 replicas have be up and all up replicas h=
ave to successfully get the write.
> If 3 replicas are up with replication factor of 3:=20
> ALL would succeed as all 3 replicas are up and would return success when =
all 3 replicas get the write=20
> QUORUM would succeed as all 3 replicas are up and would return success wh=
en 2 replicas get the write=20
> BEST_QUORUM would succeed as all 3 replicas are up and would return succe=
ss when all 3 replicas get the write
> If 2 replicas are up with replication factor of 3:=20
> ALL would fail as only 2 replicas are up=20
> QUORUM would succeed as 2 replicas are up and would return success when 2=
 replicas get the write=20
> BEST_QUORUM would succeed as 2 replicas are up and would return success w=
hen 2 replicas get the write


--
This message was sent by Atlassian JIRA
(v6.3.15#6346)