[
https://issues.apache.org/jira/browse/CASSANDRA-7545?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14061492#comment-14061492
]
graham sanderson commented on CASSANDRA-7545:
---------------------------------------------
Per [~jbellis]
"Unfortunately I don't think we can do much for hint partitioning.
It's too late for a schema change in 2.1, and 3.0 we're already
planning to move to file-based hint storage."
Short of doing some sort of hideous procedural mutation of the real UUID into a
fixed number of derived but likely to be unique UUIDs, there isn't much we can
do, so we will wait on CASSANDRA-6230, and hope a fix to CASSANDRA-7546 helps
> Hints for a down node are written to a single partition in system.hints on
> the coordinator leading to contention
> ----------------------------------------------------------------------------------------------------------------
>
> Key: CASSANDRA-7545
> URL: https://issues.apache.org/jira/browse/CASSANDRA-7545
> Project: Cassandra
> Issue Type: Bug
> Reporter: graham sanderson
>
> The worst side effect is potentially orders of magnitude larger than
> suspected memory allocation due to a race condition updating the columns in
> the memtable (see CASSANDRA-7546)
> That said, having so many hints in a single partition has other negative side
> effects (non linear growth of sorted tree data structure overhead in
> memtable, just plain large number of tombstones in a row etc.)
> Ideally, the hints would be partitioned by both the nodeUUID, and a fixed
> number of (say 4) bits of a hash of the original rowmutation's partition
> key... even this small spreading of load has a significant improvement.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
