cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Kurt Greaves (JIRA)" <>
Subject [jira] [Commented] (CASSANDRA-8119) More Expressive Consistency Levels
Date Tue, 19 Sep 2017 06:05:00 GMT


Kurt Greaves commented on CASSANDRA-8119:

Is it actually necessary to have the creation of CL's through CQL? I agree we need more from
CL's. In the past I've needed LOCAL_ALL, ANY_QUORUM, and EACH_SERIAL. So this is undoubtedly
a thing. But seems to me if CL's were an extendable class people could implement the CL's
they need and make them publicly available. Might need some extra work to support the dc-wise
stuff mentioned here but I think it's more than acceptable to expect people to build a jar
with a specific CL they need and then add it to the classpath. If there are popular ones they
could be candidates for adding to the codebase.

A UDF style thing seems a bit much imo, I don't really think they are a big enough use case
to warrant the ability to define them on the fly... plus this also scares me a little bit.

> More Expressive Consistency Levels
> ----------------------------------
>                 Key: CASSANDRA-8119
>                 URL:
>             Project: Cassandra
>          Issue Type: New Feature
>          Components: CQL
>            Reporter: Tyler Hobbs
>             Fix For: 4.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

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message