Resizing the ring is a well known issue. A singleton riak with stock 64 ring size should only consume more fd's.
What concerns me is the reluctance to change the n_val (replication factor). I was under the impression this was not an issue and could be changed at any time. I thought read repair would read a value and adjust its replication as necessary. Please elaborate why this isn't the case. For the following reasons and the fact that developing apps for riak is pretty simple, I've been using singleton riak deployments for a long time. I use this type of setup mostly for throwaway development projects but also because if your project does get big or need more power it's trivial to ramp up. Thoughts? -Alexander @siculars http://siculars.posthaven.com Sent from my iRotaryPhone > On Sep 11, 2014, at 9:32, Tom Santero <tsant...@gmail.com> wrote: > > (bringing this back to the list) > > So the largest challenge you face is when you attempt to optimize Riak for a > single-node installation what you end up doing is introducing new issues down > the line in the event that you need to scale out. For example, should you > reduce the n_val to 1 and drop the ring_size to something like 8 (in order to > keep the # of databases running on that single VM low) you're going to face a > few issues. > > 1) As John Daily already mentioned, changing the replication factor after the > fact will almost certainly lead to odd and unexpected behavior. > > 2) Ring resizing is Riak's dirty little secret, and pretty expensive. > > Should you do these hacks in an attempt to reduce the cost of maintaining two > separate codebases, the most reasonable approach when you need to scale would > be to perform a data migration from the hacky-1-node-cluster to a cluster > optimized for a multi-node environment and availability. Note, that its much > easier for me to type "do a data migration" than to actually perform one--so > take recommendations with a grain of salt. > > Regards, > Tom > > >> On Thu, Sep 11, 2014 at 8:41 AM, Henning Verbeek <hankipa...@gmail.com> >> wrote: >> On Thu, Sep 11, 2014 at 1:38 PM, Tom Santero <tsant...@gmail.com> wrote: >> > Running a singleton instance of Riak throws away all of the advantages aims >> > to provide. >> >> I understand that. But are there any penalties? Does Riak as a >> single-node-instance run worse than in a full cluster? >> >> > If you need a single database server, why not use something >> > designed for that end and rock solid, like PostgreSQL? >> >> My problem is "scaling down". We have developed something very similar >> to RiakCS (implementing our special business logic) where we store >> arbitrarily large data in Riak (in chunks, in a multi-node-cluster, >> with eventual consistency, nval=3, etc.), and thanks to HAProxy and >> Riak, we can scale up as much as we want. >> >> But, our application is sometimes installed on customer premises, >> scaled down, on a single VM. They don't *need* scalability (yet), they >> often don't need (read: want to pay for) higher availability. We don't >> want to have to maintain two versions of our application, one that >> uses Riak, another that uses ... say a local filesystem for the >> chunks. Two versions would mean more code to maintain, test, >> package... >> >> Hence the idea of using Riak in a single-node setup, nval=1 (so not to >> consume tripple diskspace). >> >> Cheers, >> Henning > > _______________________________________________ > riak-users mailing list > riak-users@lists.basho.com > http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com
_______________________________________________ riak-users mailing list riak-users@lists.basho.com http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com
