>
> Actuallly, I think my math was faulty, it's actually 800 billion keys, so
> that's many more servers than expected.
A few billion? Pssh. You know what's cool? A Trillion.
A few things jump off the page from the comments on this thread:
Static allocation of ring_creation_size. Once you set it you can not change it.
Although I'm sure that is on the drawing board. As Jeremiah pointed out, that
means you will have a ton of vnodes on each physical machine while your cluster
is still small.
Data migration. As you add nodes to the cluster some fraction of the data will
have to move around the ring. This could be a lot of data in your case.
N-val. I'm not entirely sure about this but if you think about how riak does
its map/reduce, search and index querying you have to think about how wide a
net riak casts to get results. Is querying more nodes good or bad? And how good
or bad is it in different cluster sizes. And how does that change with the
number of vnodes on each physical node. I'm not sure but I think it should be
explored.
Frankly, the hardware at play does not really factor into my decision on
whether or not to use riak. I think the only real question is how riak as a
system accommodates the kind of data you want to collect and the ways in which
you want to access it. The physical implementation is simply some scale
function in regards to performance. Ie. more money = more performance.
Would love to hear where you go with this.
Cheers,
Alexander
_______________________________________________
riak-users mailing list
riak-users@lists.basho.com
http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com
