cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jonathan Ellis (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (CASSANDRA-2045) Simplify HH to decrease read load when nodes come back
Date Tue, 17 May 2011 20:55:47 GMT

    [ https://issues.apache.org/jira/browse/CASSANDRA-2045?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13035041#comment-13035041
] 

Jonathan Ellis commented on CASSANDRA-2045:
-------------------------------------------

bq. Doesn't this mean that, given a very unstable cluster (e.g. EC2) writes using CL.ANY can
cause nodes to fill up with data unexpectedly quickly?

Sort of.  It means you can fill up by at most 1/RF faster than you thought, yes, since rows
can only be stored on at most once node that is not a replica (the coordinator). The correct
fix to that is "stabilize your cluster." :)

bq. It's probably a good idea to try to retain backwards compatibility here as much as possible
so that rolling upgrades of a cluster is possible

Right, but as discussed above we're not planning to move to materialized-hints entirely, so
ripping out "classic" hints isn't an option anyway.

bq. I think Edward's idea of storing hints in a per-node CommitLog is a pretty elegant solution,
unfortunately it's quite a lot more invasive and would be a nightmare for maintaining backwards
compatibility.

serialized mutation objects as columns in a row is pretty close to commitlog format, only
you can query it w/ normal tools.

> Simplify HH to decrease read load when nodes come back
> ------------------------------------------------------
>
>                 Key: CASSANDRA-2045
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-2045
>             Project: Cassandra
>          Issue Type: Improvement
>            Reporter: Chris Goffinet
>             Fix For: 1.0
>
>
> Currently when HH is enabled, hints are stored, and when a node comes back, we begin
sending that node data. We do a lookup on the local node for the row to send. To help reduce
read load (if a node is offline for long period of time) we should store the data we want
forward the node locally instead. We wouldn't have to do any lookups, just take byte[] and
send to the destination.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

Mime
View raw message