[
https://issues.apache.org/jira/browse/CASSANDRA-11637?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15256949#comment-15256949
]
lvh commented on CASSANDRA-11637:
---------------------------------
I have no opinions on the rarity of the use-case for C*, other than "I've hit
it with Riak" and "it was important enough for Riak to implement it"; it's
entirely possible that it's not worth adding the feature at all, either because
it's not worth it in Riak or Riak is sufficiently different from C* in a way
that makes this feature useless. The use case is certainly narrow: it's for the
subset of things where you care about some amount of low latency,
read-(immediately)-after-write, and high availability (since this will return
success in more cases than e.g. upgrading the consistency level will), and
you're willing to amend your data model (immutability) in order to get it. Many
of those seem like Cassandra features, though -- hence why I filed the issue :)
The main benefit other than the "works in more cases" and "is faster" benefits
outlined above is that solving this at a coordinator level would mean not
having to solve it in the application or in each driver. It's of course true
that the application itself can do whatever it wants, but that's generally true
(and IIRC also true for other consistency levels; having the coordinator do it
is mostly just a convenience).
You raise an excellent point re: the combinatorial explosion that can result
from parametrization. I think the common case (how a hypothetical consistency
level would behave) is:
1. Try hitting one node
2. Try hitting QUORUM worth nodes in the local DC
3. Try hitting remaining DCs
It should definitely fail after 1 expired TTL (the data is intended to be
immutable, and only works for that specific case). Also, for exactly 1 row;
this is intended for KV-y things; although that's a more interesting point...
I guess the real remaining question is "is it worth implementing the common
case as a consistency level" vs "just solve this in the driver/application".
It's unclear to me how much parametrization people actually want, and if maybe
it's possible to cover 90% of cases with 1 consistency level, which would have
the benefit that a lot more people get to use this model faster.
> Immutable-friendly read consistency level
> ------------------------------------------
>
> Key: CASSANDRA-11637
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11637
> Project: Cassandra
> Issue Type: New Feature
> Reporter: lvh
> Priority: Minor
>
> Many Cassandra applications use immutable, append-only models. For those
> models, you can accept read consistency {{ONE}}, since the data either exists
> (and then it's the data you want) or it doesn't. However, it's possible that
> the data hasn't made it to that node yet, so "missing" data might mean
> "actually missing" or "not here".
> Riak has a convenient read consistency option for this, called notfound_ok
> (default true). When false, the first succeeding read will succeed the
> operation (a la consistency level {{ONE}}), but a missing read from any node
> will keep trying up to the normal consistency level (e.g. {{QUORUM}}).
> The workaround for this is for applications to implement an
> "UpgradingConsistencyPolicy" (dual to DowngradingConsistencyPolicy) that
> tries e.g. {{QUORUM}} after {{ONE}} fails, and then writes with e.g.
> {{QUORUM}}.
> This is related to CASSANDRA-9779; but it seems that ticket only explores the
> compaction/collation/materialized view angle, not the fast & safe read
> consistency angle.
> Thanks to [~jjirsa]] for helping me dig through this, find the related
> ticket, and confirm Cassandra currently does not support this.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
