[
https://issues.apache.org/jira/browse/CASSANDRA-8119?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15330484#comment-15330484
]
Tyler Hobbs commented on CASSANDRA-8119:
----------------------------------------
Randy Fradin and I had a discussion about this at NGCC, and I think we have a
decent plan now.
The basic idea is to allow custom consistency levels to be defined similarly to
user-defined functions. Essentially, a consistency level will be a user
defined function that:
* Takes two arguments:
** A set of all nodes in the cluster, where a "node" is a tuple or UDT of the
form {{(broadcast_address, datacenter, rack)}}.
** The name of the "local" datacenter, which is the DC the coordinator is in.
* Returns a set of tuples of the form {{(node_set, num_replies)}}.
The return value defines disjoint sets of nodes, and gives each node set a
number of replicas that must respond. For example, you might return one set
per datacenter, pairing each set with {{1}} to indicate that at least one
replica from each DC must respond.
I'm imagining a CQL syntax like this (perhaps without the parameter
definitions):
{noformat}
CREATE CONSISTENCY LEVEL four (nodes set<node>, local_dc text) AS $$
Set<Tuple<Set<Node>, Integer>> results = new Set<>();
results.add(new Tuple<Set<Node>, Integer>(nodes, 4));
return results;
$$;
{noformat}
This is reasonably powerful without being terribly complex to implement or use.
One limitation of this approach is that it does not support disjunctions (e.g.
"I either want a quorum from DC1 or a quorum from DC2"). I believe we could
add support for this later by extending the {{CREATE CONSISTENCY LEVEL}}
statement, but I can't see a lot of demand for this. Additionally, it's not
clear to me how a coordinator would pick replicas to send read requests to when
disjunctions are used.
It's also a little painful to deal with sets, tuples, and UDTs in UDFs. I
think we could pre-define some utility functions and add them to the scope of
the CL UDF to ease this pain.
To implement this, we would need a new schema table to keep track of
user-defined CLs. At the native protocol level, we might accept a special
consistency level value which indicates that the CL is custom, followed by the
string CL name. Drivers could parse the new schema table and store
representations of the custom CLs somewhere in their metadata, making it easy
for users to use the CLs.
> More Expressive Consistency Levels
> ----------------------------------
>
> Key: CASSANDRA-8119
> URL: https://issues.apache.org/jira/browse/CASSANDRA-8119
> 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
(v6.3.4#6332)
