Social network data / Graph properties of Riak

Jeroen van Dijk jeroentjevandijk at gmail.com
Fri Nov 18 14:50:40 EST 2011


And I also didn't include the riak user list for this reply:


On Fri, Nov 18, 2011 at 7:04 PM, Aphyr <aphyr at aphyr.com> wrote:

> Depending on whether you think it will be more efficient to store the
> graph or its dual, consider each node a vertex and write the adjacency list
> as a part of its data. You can store whatever weights, etc. you need on the
> edges there.
>
> Don't use links; they're just a thin layer on top of mapreduce, so there's
> really not much advantage to using them. Links are subject to the HTTP
> header lengths too, so storing more than a thousand on any node is likely
> to break down.
>
>
Thank you for this suggestion. Also thanks for the warning on not using
links for what I want. So you are saying each vertex will have a list of
the other vertices that it is connected to? And save each edge as key/value
pair? Or are you saying each vertex should embed the adjacent edges,
meaning duplicated edges?

I'm guessing you mean the former, because that makes sense to me. So you
would save a graph assuming users and items like the following key/value
pairs:

//Vertices
user1: properties
user2: properties
item1: properties

//Edges
user1-owns-item1: properties
user1-follows-user2: properties
user2-follows-user1: properties

To be able to find the available edges, each vertices would need to
reference the keys of the edges. Is this what you mean?

If so, one more question about a possible problem. Say I have an item with
many many outgoing edges, so it needs to embed these references. This would
make it really costly to fetch this item from Riak I assume, even if you
are only interested in normal properties. Wouldn't that mean you will have
to save the properties seperately from the edges references to it feasible?

Did I grasp what you were proposing Kyle?

Thanks,
Jeroen



> --Kyle
>
>
> On 11/18/2011 07:38 AM, Jeroen van Dijk wrote:
>
>> Hi all,
>>
>> I'm currently evaluating whether Riak would fit as the main storage of
>> my current project, a social network. The reason I am attracted to Riak
>> and less to a Graph database as main storage is that I want the easy
>> horizontal scalability and multi-site replication that Riak provides.
>> The only thing I doubt is whether the key-value/link model of Riak is
>> flexible enough to be able to store a property graph
>> (http://arxiv.org/abs/1006.**2361 <http://arxiv.org/abs/1006.2361>). I
>> am not asking whether the
>> querying/graph traversing will be easy; I'm probably going to use a
>> graph database or a Pregel like platform (e.g.
>> http://www.goldenorbos.org/) for that problem. I guess my main question
>> is whether it would be easy/feasible to import and export a property
>> graph in and from Riak? Has someone done this before?
>>
>> I realize the above might be too specific, so here are two more
>> questions that I think are relevant:
>>
>> - Is there a known upper limit of links that can be stored (I don't want
>> to add them all at once so 1000 per request is fine,
>> http://lists.basho.com/**pipermail/riak-users_lists.**
>> basho.com/2010-March/000786.**html<http://lists.basho.com/pipermail/riak-users_lists.basho.com/2010-March/000786.html>
>> )
>> - Is there a way to add meta data to links (edges)? E.g. weigths and
>> other attributes.
>>
>> Any other ideas or advise are also highly appreciated.
>>
>> Cheers,
>>
>> Jeroen
>>
>>
>>
>> ______________________________**_________________
>> riak-users mailing list
>> riak-users at lists.basho.com
>> http://lists.basho.com/**mailman/listinfo/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/20111118/1930f975/attachment.html>


More information about the riak-users mailing list