[
https://issues.apache.org/jira/browse/CASSANDRA-2045?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13057451#comment-13057451
]
Nicholas Telford commented on CASSANDRA-2045:
---------------------------------------------
bq. That's bad though, because then we can't access hints efficiently on a node
up/down message (we actually did it that way in 0.6 and learned our lesson.)
Good point. I retract that idea. :-)
bq. So we denormalize but we gain not having to do
secondary-lookup-per-mutation, which is our main motivation for the change.
(And single-destination-per-hint is by far the common case.)
I'm a bit confused here. There could be many mutations for a single key, we'd
need to store each of them. I do like the idea of being able to slide the
mutations though. Perhaps we could form the key from a compound of the
key-table-cf, so it would look something like this:
{noformat}
Hints: { // cf
<dest ip>: { // key
<key>-<table>-<cf>: { // super-column
<version>: <mutation> // column
}
}
}
{noformat}
Or is it vital that the key is stored separately from the table and cf?
> 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
> Assignee: Nicholas Telford
> Fix For: 1.0
>
> Attachments:
> 0001-Changed-storage-of-Hints-to-store-a-serialized-RowMu.patch,
> 0002-Refactored-HintedHandoffManager.sendRow-to-reduce-co.patch,
> 0003-Fixed-some-coding-style-issues.patch,
> 0004-Fixed-direct-usage-of-Gossiper.getEndpointStateForEn.patch,
> 0005-Removed-duplicate-failure-detection-conditionals.-It.patch,
> 0006-Removed-handling-of-old-style-hints.patch, 2045-v3.txt,
> CASSANDRA-2045-simplify-hinted-handoff-001.diff,
> CASSANDRA-2045-simplify-hinted-handoff-002.diff
>
>
> 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
