http://www.datastax.com/support-forums/topic/scalability-strategy Software, Support, and Training for Apache Cassandra en-US Mon, 20 May 2013 07:46:26 +0000 http://bbpress.org/?v=1.0.3 q http://www.datastax.com/support-forums/search.php http://www.datastax.com/support-forums/topic/scalability-strategy#post-213 Tue, 21 Jun 2011 17:37:28 +0000 ZFabrik 213@http://www.datastax.com/support-forums/ <p>Hi blueplastic, </p> <p>thank's a lot for this fast and formidable response :-)</p> <p>Udo </p> http://www.datastax.com/support-forums/topic/scalability-strategy#post-212 Tue, 21 Jun 2011 17:03:10 +0000 blueplastic 212@http://www.datastax.com/support-forums/ <p>Yeah, depending on your partitioner and data model, there's different strategies you can consider.</p> <p>If you're using the random partitioner (MD5 hash is used to determine where to place keys on the node ring), then you can assume that your data is evenly spread across all nodes. So, when all of the nodes are evenly getting full, you can opt to easily double the cluster size by bisecting each node's range in the ring. If you want, you could also just add like 3 additional nodes to an existing 20 node cluster. But then you would potentially have to just pick 3 nodes to bisect, or if you want an even spread of the data, you would have to change the token range on all 20 nodes and then have them redistribute data, which could be heavy on the network.</p> <p>If you're using an Order-preserving partitioner (OPP), then adding 3 nodes to a 20 node cluster makes more sense. As you may know, with OPP rows are stored by key order, aligning the physical structure of the data with the sort order (giving you the ability to perform range slices with ordering). So, if you're down with OPP, then your ring could potentially be very lopsided. When one node grows a hot spot, you can bisect its range in half.</p> <p>Also, keep in mind that you should only plan on using 50% of the free space on the Cassandra data volume. The other half needs to remain free to accommodate compaction. And on the Apache Mailing list, the general consensus is that each Cassandra node should store no more than maybe 500 GB of data. That's just a rule of thumb, so depending on your use case, you may be able to store more.</p> <p>Someone from DataStax might be able to provide some more guidance...</p> <p>I assume you've seen the DataStax post on adding nodes? :<br /> <a href="http://www.datastax.com/docs/0.8/install/adding_nodes" rel="nofollow">http://www.datastax.com/docs/0.8/install/adding_nodes</a> </p> http://www.datastax.com/support-forums/topic/scalability-strategy#post-211 Tue, 21 Jun 2011 15:41:46 +0000 ZFabrik 211@http://www.datastax.com/support-forums/ <p>Hi, </p> <p>On <a href="http://www.datastax.com/solutions/scaleable-elastic-datacenter" rel="nofollow">http://www.datastax.com/solutions/scaleable-elastic-datacenter</a> you write that is very easy to add new hardware on demand to a Cassandra cluster.<br /> I wonder on the best strategy here. Given a cluster with n nodes, does it makes sense to just add 1,2,3 or so, or should one always add exactly n nodes, i.e. should one always double the cluster size?<br /> Since Cassandra arranges the data in a logical ring, new nodes can always be placed between two existing nodes, right?<br /> This means however the token range of the successor neighbor is bisected.<br /> Thus if not adding exactly n nodes the token ranges will become unbalanced across the ring, leading to different load factors for different nodes.</p> <p>Thanks in advance and best regards</p> <p>Udo </p>