big cache vs. many partitions and replicas placement
christian at basho.com
Mon Jan 28 12:23:56 EST 2013
By cache size, I am assuming you are referring to the leveldb internal cache. Is this correct?
The arguably most important parameter in your configuration is the ring size. Defining an appropriate ring size is very important as it can't change later on and determines how far you can scale. It is recommended that you allow for at about 10 partitions per physical node (http://docs.basho.com/riak/1.3.0/references/appendices/Cluster-Capacity-Planning/#Ring-Size-Number-of-Partitions), which means that if you are preparing for a cluster of around 20 nodes, you should probably use 256 partitions.
At the moment we do not recommend tuning the eleveldb cache_size at all, so it would be best to leave it at the default value.
With an n_val of 3, Riak will store every record on 3 consecutive vnodes in the ring. The case where multiple copies may end up on less than 3 different physical servers primarily applies to cases where there are less than 4 nodes in the cluster as nodes will repeat around the ring wrap around point.This is one of the reasons we recommend using at least 5 nodes in the cluster.
On 28 Jan 2013, at 15:47, "Effenberg, Simon" <seffenberg at team.mobile.de> wrote:
> we want to save plenty of mails in riak which are in average 14k big. Our cluster will become between 10 to 20 nodes so the question is: what is better, having more partitions but each has less cache or is it the other way around so having less partitions with more cache size?
> Also with an n_val of 3 it is always said, that there is no guarantee for having this on 3 physical nodes but also that it should be distributed evenly. What does it mean? Is there any calculation I can do to get a feeling how often 3 replicas are only on 2 nodes? Or can you say: with 6 nodes and an n_val of 3 it should be the case that almost 99.9 percent is distributed over different physical nodes?
> riak-users mailing list
> riak-users at lists.basho.com
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the riak-users