Routing type differences

[ctasada]

Hi,

I'm trying to understand the difference between the client and server routing (as in stores.xml <store>/<routing>) I see that the options are client or server and I found this description in one of the wiki pages

Routing can be done either on the client side or the server side. If routing is done on the client side the client must calculate the a list of the appropriate servers on which to store or retrieve a given key and then deliver/request the value to/from those nodes. If routing is done on the server side, the client just makes the request to a random node and that node handles the routing of the request. Each request comes with a should_route flag telling whether or not the server is expected to reroute the request. 

But I'm still clueless about the benefits of each of these options. 

In fact, checking the code I saw that the whole client/server routing is just a wrapper around the RequestRoutingType class (Normal, Routed and Ignore_Checks) there we can even see that the previously mentioned 'should_route flag' is enabled, the 'ignore_checks' flag takes preference.

Can someone throw a bit of light on this?

Thanks.

[Chinmay Soman]

In general client side routing has the obvious advantage of one less
hop and hence better for applications that are latency sensitive.

But thanks much for initiating this discussion. Personally I prefer
server side routing, here's why :

* Lightweight clients make code / service evolution easy. We can keep
changing things on the server side (maybe even drastic changes)
without affecting old client portability.
* Less config to manage on the client side. Currently we see that
tuning the client is pretty cumbersome and very iterative. Again
config should be tunable (hence the name) but not this frequently.
* Topological changes become completely transparent to the client (the
requirement to bounce / re-bootstrap the client is removed)
* Super simple failure detection on the client side (currently failure
detection operation is critical on the client side).
* Connections optimization (we might not need to open so many
connections - currently it seems unbounded. In fact, we're discussing
whether to remove the #connections config completely from the client
side).

Of course, server side routing has problems / issues that need to be
handled
* Extra hop
* Intra cluster communication must be correctly done (batching
requests, connection management)
* currently DR (Disaster Recovery: i.e. writing to another zone) is
done entirely by the client. This must now be handled by the server).
* Extra memory usage on the coordinator - It not only has the BDB
cache overhead but also needs to keep track of the client requests.

What do you guys think ?

[Carlos Tasada]

Hi Chinmay,

I understand the advantages and even I agree with removing the #connections from the client config (I never understood why was there), but I have some questions regarding the disadvantages of the server side routing

* Extra hop: Does this mean that the clients are always connecting to the same server? I imagine is the first one in the bootstrap. If that's the situation, is this server also answering for those gets that has this server replicated?

* DR: How is now working the use of zones with server routing? You say that the client is doing it.

Thanks

--
You received this message because you are subscribed to the Google Groups "project-voldemort" group.

To post to this group, send email to project-...@googlegroups.com.
To unsubscribe from this group, send email to project-voldem...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/project-voldemort?hl=en.

[Chinmay Soman]

To be clear, with server side routing, we can potentially do away with
the bootstrap overhead. In bootstrap we obtain the cluster and stores
metadata so that client can do the hash routing by itself. With server
side routing, all the client needs to do is connect to any random node
in the cluster (not the same node every time) and issue the request.
This random node or "coordinator" will then do the actual routing.
Thus the extra hop is because the request is done via the coordinator.

DR: Well with server side routing - the coordinator will do it. Its
not like it cannot do DR. What I meant is the cross colo connections
can be optimized so that every server in one cluster does not open a
connection (or two) to every server in another (or more) cluster (s).

On Apr 30, 10:36 pm, Carlos Tasada <ctas...@gmail.com> wrote:
> Hi Chinmay,
>
> I understand the advantages and even I agree with removing the #connections
> from the client config (I never understood why was there), but I have some
> questions regarding the disadvantages of the server side routing
>
> * Extra hop: Does this mean that the clients are always connecting to the
> same server? I imagine is the first one in the bootstrap. If that's the
> situation, is this server also answering for those gets that has this
> server replicated?
> * DR: How is now working the use of zones with server routing? You say that
> the client is doing it.
>
> Thanks
>

[Carlos Tasada]

Ok, so if I'm taking it right we have basically 2 scenarios:

- From a development point of view it's better the server routing, since simplifies the coding

- From a user point of view it's better the client routing, since has better performance (basically because goes directly to the correct node)

I'm asking all these questions because I'm trying to understand properly the pros/cons of the different options.

Thanks again for your detailed explanations.

[Chinmay Soman]

Questions are good . I"m really glad you initiated this discussion.
This is one of the things which we're planning for our roadmap. Pretty
soon, I'll create a separate topic which enumerates all those features/
action items for better visibility to the open source community.

FYI: I dont think the extra hop is a big deal if you are in the same
data centre. The network round trip is like 1 ms (very conservative
estimate - probably upper bound). I think the biggest advantage is
that it will improve the client usability and thus Voldemort
usability. Currently people see it as rocket science to properly
configure a client.

On May 1, 11:40 am, Carlos Tasada <ctas...@gmail.com> wrote:
> Ok, so if I'm taking it right we have basically 2 scenarios:
>
> - From a development point of view it's better the server routing, since
> simplifies the coding
> - From a user point of view it's better the client routing, since has
> better performance (basically because goes directly to the correct node)
>
> I'm asking all these questions because I'm trying to understand properly
> the pros/cons of the different options.
>
> Thanks again for your detailed explanations.
>

[Carlos Tasada]

I'm really looking forward for this roadmap :)

I'm only working with Voldemort since 3 months ago and I can confirm that at the beginning it really looked like "rocket science", now a lot of topics are more clear, but I still keep learning new things every day ;)