cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Benedict (JIRA)" <>
Subject [jira] [Commented] (CASSANDRA-7032) Improve vnode allocation
Date Sat, 20 Jun 2015 12:22:02 GMT


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
# 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:
>             Project: Cassandra
>          Issue Type: Improvement
>          Components: Core
>            Reporter: Benedict
>            Assignee: Branimir Lambov
>              Labels: performance, vnodes
>             Fix For: 3.x
>         Attachments:,,,,,
> 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

View raw message