[
https://issues.apache.org/jira/browse/CASSANDRA-2540?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13023190#comment-13023190
]
Sylvain Lebresne commented on CASSANDRA-2540:
---------------------------------------------
bq. At least to me, "significantly improved latency" refers to the expected
behavior in the event of a single node being slow or individual messages being
dropped, etc. At least to me, this isn't about avoiding another network
round-trip to improve latency by a few milliseconds (or at least that is a
small part of it), but rather about experiencing a much more consistent latency
over time by removing outliers.
Yes, it will make for a more consistent latency upon failures, but failures are
not the norm overall (not saying they are not happening regularly nor what we
shouldn't try to handle them as well as we could) and it's unclear latency will
be better *on average*. So depends on what you want. As for GC and saturated
node, let's not forget that we have a dynamic snitch that is supposed to handle
that.
Again, I do agree there is room for improvements and let's totally explore that.
What I'm saying however is that it would be nice if we could avoid rushing into
expressions like "significantly improved latency" or "the potential latency
improvement is huge" before having tried anything and in general keep some
healthy amount of skepticism over what's an improvement and what's not. This is
not just about wording, this is about taking the time to validate we're not
screwing some people along the way. If you convince yourself too quickly that
something 'is the best thing ever', you're less likely to actually check that
it is. Anyway, just saying.
> Data reads by default
> ---------------------
>
> Key: CASSANDRA-2540
> URL: https://issues.apache.org/jira/browse/CASSANDRA-2540
> Project: Cassandra
> Issue Type: Bug
> Reporter: Stu Hood
> Fix For: 0.8.0
>
>
> The intention of digest vs data reads is to save bandwidth in the read path
> at the cost of latency, but I expect that this has been a premature
> optimization.
> * Data requested by a read will often be within an order of magnitude of the
> digest size, and a failed digest means extra roundtrips, more bandwidth
> * The [digest reads but not your data
> read|https://issues.apache.org/jira/browse/CASSANDRA-2282?focusedCommentId=13004656&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13004656]
> problem means failing QUORUM reads because a single node is unavailable, and
> would require eagerly re-requesting at some fraction of your timeout
> * Saving bandwidth in cross datacenter usecases comes at huge cost to
> latency, but since both constraints change proportionally (enough), the
> tradeoff is not clear
> Some options:
> # Add an option to use digest reads
> # Remove digest reads entirely (and/or punt and make them a runtime
> optimization based on data size in the future)
> # Continue to use digest reads, but send them to {{N - R}} nodes for
> (somewhat) more predicatable behavior with QUORUM
> \\
> The outcome of data-reads-by-default should be significantly improved
> latency, with a moderate increase in bandwidth usage for large reads.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
