cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Tyler Hobbs (JIRA)" <>
Subject [jira] [Commented] (CASSANDRA-8119) More Expressive Consistency Levels
Date Wed, 15 Jun 2016 16:07:09 GMT


Tyler Hobbs commented on CASSANDRA-8119:

bq. this is a niche requirement

I disagree. Good multi-datacenter support is one of Cassandra's most popular features.  Having
the ability to control consistency levels per-DC can be very useful.

bq. Additionally, you can't really encapsulate it in a UDF, as there are more factors that
are CL-dependent. The behaviour of read repair, and speculative retry, can/should wary a lot
depending on a CL

I don't think the CL should be _only_ a UDF.  Other options could be specified through {{WITH}}
clauses.  For example, something like {{WITH READ REPAIR = 'dclocal'}}.  I'm just making that
up, but we do have a lot of flexibility here.

bq. Also, while you could stick it to schema, I don't see how it's a fit, conceptually, and
not a (conceptually) dirty hack.

I'm not sure what you mean.  Care to elaborate?

> More Expressive Consistency Levels
> ----------------------------------
>                 Key: CASSANDRA-8119
>                 URL:
>             Project: Cassandra
>          Issue Type: New Feature
>          Components: CQL
>            Reporter: Tyler Hobbs
>             Fix For: 3.x
> For some multi-datacenter environments, the current set of consistency levels are too
restrictive.  For example, the following consistency requirements cannot be expressed:
> * LOCAL_QUORUM in two specific DCs
> * LOCAL_QUORUM in the local DC plus LOCAL_QUORUM in at least one other DC
> * LOCAL_QUORUM in the local DC plus N remote replicas in any DC
> I propose that we add a new consistency level: CUSTOM.  In the v4 (or v5) protocol, this
would be accompanied by an additional map argument.  A map of {DC: CL} or a map of {DC: int}
is sufficient to cover the first example.  If we accept a special keys to represent "any datacenter",
the second case can be handled.  A similar technique could be used for "any other nodes".
> I'm not in love with the special keys, so if anybody has ideas for something more elegant,
feel free to propose them.  The main idea is that we want to be flexible enough to cover any
reasonable consistency or durability requirements.

This message was sent by Atlassian JIRA

View raw message