If you can help us what goal is trying to be achieved by taking that approach, perhaps we can refute the logic (or find a better solution). It sounds suspiciously like someone is trying to avoid the complexities of siblings and conflict resolution (a goal which your architecture doesn't actually achieve).
If the argument can't be won, at least use a load balancer (software like haproxy would do fine) in front of riak1 for writes so that you can redirect traffic in the case of a node failure. However, seriously, if your company is willing to sacrifice write availability, Riak probably isn't the best choice. Riak's tradeoffs are oriented around making certain it remains available even with network and server failures; if you don't need high availability, making those tradeoffs is usually not worth the trouble. -John On Wed, Oct 8, 2014 at 1:03 AM, Geoff Garbers <ge...@totalsend.com> wrote: > Nope, the reads will be randomly distributed through the other four > nodes (riak2 through to riak5 - selected from within a hard-coded list > of host names). > > I sincerely doubt our workload would require some sort of complicated > workload set-up. As for your question as to why I'm doing this - I > don't want to. > > This decision has been made higher up, but I don't agree with it. I'm > wanting to gather as much information as possible & understand as much > as possible before I motivate for why it's a bad idea. > > The biggest pitfall of this (in my opinion) is that should riak1 go > down (even for maintenance), we're unable to write without first > updating our code to point to another riak host. > > Thanks for the feedback. Much appreciated :) > > > > Geoffrey Garbers > Senior Developer > > > Cell: +27 (0)766 476 920 > Skype: geoff.garbers > ge...@totalsend.com > www.totalsend.com > > +1 347-431-0494 > +44 (0)203 519 1082 > +61 (0)3 9111 5760 > +27 (0)21 200 6981 > > > On Tue, Oct 7, 2014 at 11:49 AM, Sargun Dhillon <sar...@sargun.me> wrote: > > When you do read / modify / writes, are you also planning on sending > > the relevant read through one node only? In that case, your update > > latency might suffer if the egress queues of your designated node get > > backed up on writes, waiting for a very low cost read query. > > > > You're more likely to get awkward load on riak1, and the vnodes that > > that node hosts are going to suffer as a result. Although, you may not > > see that in the common case where n=3, and r=quorum, (r=2), but if > > another vnode in a preflist is degraded, it's likely to be > > problematic. > > > > There are potential performance benefits given some very specific > > workloads where you can sacrifice a node, or alternatively you can > > configure Riak not to put any vnodes on that node, but these are > > advanced options that are not for the faint of heart. > > > > My question would be why are you doing this? > > > > P.S. The way you asked your question of the list is fine. > > > > On Tue, Oct 7, 2014 at 2:09 AM, Geoff Garbers <ge...@totalsend.com> > wrote: > >> Hi all. > >> > >> Apologies if I'm not using the mailing list correctly - this is the > >> first time I'm posting to a mailing list. > >> > >> We're in the process of redeveloping our systems using Riak, and will > >> be using five nodes initially. Let's call these nodes riak1 through to > >> riak5. Our read/write/delete distribution is weighted more towards > >> reads than writes, with few deletes (if I have to hazard a guess, I > >> would say 60/35/5 read/write/deletes). > >> > >> A technical decision has been made to ensure that all writes are sent > >> to riak1, and all reads are done from riak2 through riak5. The read > >> hosts are selected completely at random. > >> > >> Apart from the obvious write availability concern, is there any > >> performance benefit or penalty to be had from writing to a specific > >> node, and reading from the rest? I haven't been able to perform a test > >> on this myself, so any input from the community would be appreciated > >> for the time being. > >> > >> Thanks in advance, > >> Geoff > >> > >> _______________________________________________ > >> 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 >
_______________________________________________ riak-users mailing list riak-users@lists.basho.com http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com
