cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Nicholas Telford (JIRA)" <>
Subject [jira] [Commented] (CASSANDRA-2045) Simplify HH to decrease read load when nodes come back
Date Wed, 29 Jun 2011 20:30:28 GMT


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

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:
Hints: {                    // cf
  <dest ip>: {              // key
    <key>-<table>-<cf>: {   // super-column
      <version>: <mutation> // column

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


View raw message