DHT/Riak [was RE: Redis stores]
Jeff Rousseau <jrousseau@aptima.com>
At the risk of having virtual rocks thrown at me for bringing up an old thread that seems to be resolved (with Redis):
Has anyone looked-into/worked-with any key stores that use a distributed hash-table approach (Dynamo, Riak)? Before my funding got put on hold I spent some time researching DHTs as a possible way to solve the ROS-resource data-sync problem in a decentralized way. Something like Riak, a DHT-based key store has some nice benefits:
- Inherently master-less
- zero-effort data synchronization (keys are shared among all joined Riak ‘nodes’)
- supports key expiration and in-memory storage
In theory you would just have one “public” key store ever on a ROS network, since the entire store is “sharded” over all your separate ROS machines, each hosting their piece of the pie.
Perhaps a crackpot idea—but one I was toying around with. The idea came from looking at how large decentralized networks like bittorrent work (they employ a DHT).
I’m not advocating for this over Redis--it’s just an idea I want to throw out there. Now that we have some traction with a new prototype (Redis-based) system, the absolute last thing I want to do is to derail our progress so take this suggestion with several large grains of salt.
**ducks from virtual rocks**
-Jeff
From: ros-s...@googlegroups.com [mailto:ros-s...@googlegroups.com]
On Behalf Of Daniel Stonier
Sent: Monday, September 03, 2012 12:54 PM
To: ros-s...@googlegroups.com
Subject: Re: [ros-sig-mm] Redis stores
On 4 September 2012 00:57, Piyush <piy...@gmail.com> wrote:
+1 for redis as well.
I believe the warehouse stack(http://www.ros.org/wiki/warehousewg)
using mongodb is supposed to accomplish the same things as redis. Are
there pros/cons to using one or the other?
Piyush
I didn't realise mongodb existed in RAM as well.
Keeping in mind that I have zero past experience with these....;)
It seems that their characteristics serve quite different use cases. Redis is about having temporary key stores which are just what we need for storing multimaster related runtime information - topics, node uri's, platform info etc. Redis also has some pubsub messaging, which would be quite convenient (and I think - testing tomorrow) parallels the usage of xmlrpc handlers. TTL is built in. It's faster.
On the other side, mongodb is more aligned with data storage. Easier to do permanent storage?
Daniel.
On Mon, Sep 3, 2012 at 10:54 AM, Jack O'Quin <jack....@gmail.com> wrote:
> On Mon, Sep 3, 2012 at 1:12 AM, Ken Conley <k...@kwc.org> wrote:
>> A long time ago I had spec'd Red is for the next version of the master, for
>> many reasons, including multi master and TTL. So,
>>
>> +1
>>
>> On Sep 2, 2012 11:10 PM, "Daniel Stonier" <d.st...@gmail.com> wrote:
>>>
>>>
>>> Hi,
>>>
>>> While hacking around a multi-gateway solution, I'm finding it will need
>>> alot of xmlrpc nodes, zeroconf advertising of all of these and interaction
>>> between all of them.
>>>
>>> Which brought me back to thinking about redis. I don't know much about
>>> redis yet, but probably pertinent points for us include:
>>>
>>> Server side it runs like a database stored in ram (lists, dictionaries,
>>> ...). Fast and convenient.
>>> It has pubsub style connections which I believe allow clients to receive
>>> callbacks on data store changes.
>>> Many client languages supported.
>>>
>>> If this works, then zeroconf advertisements would be reduced to just
>>> advertising the redis server. Clients autodiscover the redis server and dump
>>> gateway and monitoring information there.
>>> All multimaster data and synchronisation processes could be accumulated
>>> and triggered from there.
>>>
>>> The advantages - much simpler, far less code, easy to introspect and has
>>> other potential uses.
>>> The disadvantages - requires launching of a separate component (the redis
>>> server) to do multimaster synchronisations.
>>>
>>> Note that the alternative, with xmlrpc nodes launched at each robot, no
>>> additional infrastructure is needed for multimaster synchronisations. Is
>>> launching a separate component inconvenient enough to disregard this option?
>>>
>>> Thoughts?
>
> I just took a first look at redis. Seems like a good fit.
>
> Availability is good, Ubuntu has packaged redis-server for quite a long time.
> --
> joq
--
Phone : +82-10-5400-3296 (010-5400-3296)
Home: http://snorriheim.dnsdojo.com/
Yujin R&D:
http://rnd.yujinrobot.com/
The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from any computer.
Jihoon
I agree you that DHT like Dynamo, Riak has definite advantage to implement master-less multi-master system. Replacing Redis with DHT would also be good for later to provide fault-tolerance. Redis has been chosen for proto-typing because it was just really easy to use, provides pub/sub, and provides many client libraries.
I am currently trying to design gateway model to be separable from database. So Redis will be replacable with other database implementation like Riak later. Once gateway model is fixed, let's see which database model is the most appropriate one :)
Cheers,
Jihoon