cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jeremy Hanna (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (CASSANDRA-4658) Explore improved vnode-aware replication strategy
Date Mon, 25 Apr 2016 20:05:13 GMT

    [ https://issues.apache.org/jira/browse/CASSANDRA-4658?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15256943#comment-15256943
] 

Jeremy Hanna commented on CASSANDRA-4658:
-----------------------------------------

The resolution of duplicate is only for improving the existing support.  The improvement has
to do with hot spotting as a result of the random token assignment as talked about in the
description.  An obvious way to do that is to explore using a distribution factor - hence
the resolution of duplicate.

To be clear, the replication itself with vnodes + racks works fine with the caveat that you
need an equal number of nodes in each rack to avoid hotspotting.  That is, with the way that
replication happens within a replica set, it will ensure that all replicas are not in a single
rack.

> Explore improved vnode-aware replication strategy
> -------------------------------------------------
>
>                 Key: CASSANDRA-4658
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-4658
>             Project: Cassandra
>          Issue Type: New Feature
>    Affects Versions: 1.2.0 beta 1
>            Reporter: Nick Bailey
>
> It doesn't look like the current vnode placement strategy will work with people using
NTS and multiple racks.
> For reasons also described on CASSANDRA-3810, using racks and NTS requires tokens to
alternate racks around the ring in order to get an even distribution of data. The current
solution for upgrading/placing vnodes won't take this into account and will likely generate
some hotspots around the ring. 
> Not sure what the best solution is. The two immediately obvious approaches appear to
be quite complicated at first.
> * Fixing NTS to remove the requirement for rack ordering
> ** No idea how this would be accomplished
> ** Presents challenges for people upgrading. Would need to deprecate NTS for a new strategy
that replaces it, then have a clear upgrade path to that strategy which would need to be in
a pre 1.2 release.
> * Changing vnode placement strategy
> ** Ordering vnodes would require quite a bit of additional logic. Adding a new node or
rack would also need to maintain ordering which could cause enough data movement to remove
any benefits vnodes have already.
> ** We could potentially adjust vnode token placement to offset any imbalances caused
by NTS but this would require a fairly intelligent mechanism for determining vnode placement.




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Mime
View raw message