cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "lvh (JIRA)" <>
Subject [jira] [Commented] (CASSANDRA-11637) Immutable-friendly read consistency level
Date Mon, 25 Apr 2016 17:10:13 GMT


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:
>             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.
> 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

View raw message