[
https://issues.apache.org/jira/browse/CASSANDRA-11637?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15256605#comment-15256605
]
lvh commented on CASSANDRA-11637:
---------------------------------
If you include the drivers in C* and solve it there; convenience so that people
don't have to write it themselves ;-)
More seriously; Riak produces different behavior here; "dropping" to a higher
read consistency level (e.g. QUORUM) is different because QUORUM still tries to
connect to QUORUM nodes instead of having the "first-try-wins" behavior. In a
healthy cluster, those are almost equivalent, since your read is going to
succeed in approximately the highest latency for a node in the quroum set to
respond, whereas it could have succeeded in approximately the lowest latency
for a node in the quorum set to respond. This is particularly interesting
because it fails better when your cluster is on fire. I'm familiar with but not
an expert in Cassandra's internals (and, unfortunately that knowledge is a few
years old now), but it does seem that that part would be at the coordinator
level.
It seems like a driver could get the best possible behavior as well by
contacting nodes directly to emulate this behavior.
> 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)
