[
https://issues.apache.org/jira/browse/CASSANDRA-7032?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14594566#comment-14594566
]
Benedict commented on CASSANDRA-7032:
-------------------------------------
Ok, it's looking good to me. A couple of final things to do before commit:
# Swap order of "static {access scope}" to "{access scope} static" - this
doesn't appear to be in our code style, which looks like an oversight, but
there are thousands of occurrences of the latter, and only your occurrences of
the former :)
#* It may be worth sneaking in the swap for your CL code as well, although I
can ninja that separately
# Rebase, modify CHANGES.txt and get clean cassci runs
We should then file a follow up for improving how users can access this
functionality. It may be helpful to introduce a nodetool command for
rebalancing the cluster through gradual application of this algorithm to more
nodes. It would be neat to potentially introduce a modification to this
algorithm for evaluating token _removal_, so that we could reduce the number of
vnodes in an existing cluster, adding just the necessary number to get a good
result. A more simple goal be to support bootstraping a vnode cluster without a
keyspace present.
> Improve vnode allocation
> ------------------------
>
> Key: CASSANDRA-7032
> URL: https://issues.apache.org/jira/browse/CASSANDRA-7032
> Project: Cassandra
> Issue Type: Improvement
> Components: Core
> Reporter: Benedict
> Assignee: Branimir Lambov
> Labels: performance, vnodes
> Fix For: 3.x
>
> Attachments: TestVNodeAllocation.java, TestVNodeAllocation.java,
> TestVNodeAllocation.java, TestVNodeAllocation.java, TestVNodeAllocation.java,
> TestVNodeAllocation.java
>
>
> It's been known for a little while that random vnode allocation causes
> hotspots of ownership. It should be possible to improve dramatically on this
> with deterministic allocation. I have quickly thrown together a simple greedy
> algorithm that allocates vnodes efficiently, and will repair hotspots in a
> randomly allocated cluster gradually as more nodes are added, and also
> ensures that token ranges are fairly evenly spread between nodes (somewhat
> tunably so). The allocation still permits slight discrepancies in ownership,
> but it is bound by the inverse of the size of the cluster (as opposed to
> random allocation, which strangely gets worse as the cluster size increases).
> I'm sure there is a decent dynamic programming solution to this that would be
> even better.
> If on joining the ring a new node were to CAS a shared table where a
> canonical allocation of token ranges lives after running this (or a similar)
> algorithm, we could then get guaranteed bounds on the ownership distribution
> in a cluster. This will also help for CASSANDRA-6696.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
