Hi Geoff,
It may not even be a logic issue. "Higher up" management may not fully
understand Riak. Might I suggest while listening to their reasons, pay
close attention to whether they are approaching Riak configuration with
an older thought process (i.e. "this is how we did it in the past, so
this is how we're going forward").
One could explain your situation like this:
You're at the airport and ready to fly out along with thousands of other
people. You and every other flyer approach a security gate checkpoint
with 10 screening lanes available. At each of these screen lanes there
are agents waiting to push scores of passengers through. Now suppose
out of all of those available screening lanes, only a single screening
lane was being utilized to receive and screen flyers, one by one. The
other screening lanes are just sitting there with agents ready at hand,
but not being utilized. You can push through all of those passengers
waiting to fly... but at a terrible cost.
Cars are designed to drive forward, not sideways. Riak is designed to
balance load, obtain maximum efficiency, and sustain operation during
one or more node interruption.
-Lukas
On 10/8/14, 9:00 AM, riak-users-requ...@lists.basho.com wrote:
Send riak-users mailing list submissions to
riak-users@lists.basho.com
To subscribe or unsubscribe via the World Wide Web, visit
http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com
or, via email, send a message with subject or body 'help' to
riak-users-requ...@lists.basho.com
You can reach the person managing the list at
riak-users-ow...@lists.basho.com
When replying, please edit your Subject line so it is more specific
than "Re: Contents of riak-users digest..."
Today's Topics:
1. Re: Connecting to a single host vs balancing requests
(Geoff Garbers)
2. Re: Connecting to a single host vs balancing requests (John Daily)
----------------------------------------------------------------------
Message: 1
Date: Wed, 8 Oct 2014 07:03:51 +0200
From: Geoff Garbers <ge...@totalsend.com>
To: Sargun Dhillon <sar...@sargun.me>
Cc: "riak-users@lists.basho.com" <riak-users@lists.basho.com>
Subject: Re: Connecting to a single host vs balancing requests
Message-ID:
<caaeh1ddklrlkpv40xjas-zs_yuucqs_xnrkc6xoamn7x6qk...@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8
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
------------------------------
Message: 2
Date: Wed, 8 Oct 2014 09:07:11 -0400
From: John Daily <jda...@basho.com>
To: Geoff Garbers <ge...@totalsend.com>
Cc: "riak-users@lists.basho.com" <riak-users@lists.basho.com>
Subject: Re: Connecting to a single host vs balancing requests
Message-ID:
<cabpjnfu-5srfsyyxqb7647_i4ud5sm5sygds+8uyavzchyw...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.basho.com/pipermail/riak-users_lists.basho.com/attachments/20141008/f92841a3/attachment-0001.html>
------------------------------
Subject: Digest Footer
_______________________________________________
riak-users mailing list
riak-users@lists.basho.com
http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com
------------------------------
End of riak-users Digest, Vol 63, Issue 7
*****************************************
_______________________________________________
riak-users mailing list
riak-users@lists.basho.com
http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com
