Modeling Social Network Relationships about vespa HOT 6 CLOSED

This could probably be modelled by simply having follows as it's own document type with the fields: followee, follower and position. Then you can:

SELECT * FROM follows 
WHERE followee = "BigBob"
ORDER BY position;

from vespa.

@lesters do you mean, follows should be a struct data type with {followee, follower, and position} fields? I'm not sure I follow how that would work, considering array can't be indexed. Also, in your pseudo sql example above -- am I expecting to get back a list of profile IDs, or the actual profiles?

from vespa.

Yes, not much you can do with structs in Vespa other than storing and retrieving them.
You either need to do as Lester suggests, which gives you a lot of power at the expense of a higher document count, or

To retrieve all followers:
Add a new field followsHandle of type array which you can index and search.

To sort by follow time of the matching follower, you can either

Retrieve it from the "follows" array of struct in Java Searcher plugin (or in the client. This will be slow if you have a high number of followers.

or,

Add a
field handletimes type tensor(handle{})
to the document, where the value of each element is the add time, and pass a tensor(handle{}) in the query (say, query(follower)) with a single element {{handle:BigBob}:1}, and then rank by the ranking expression

sum(query(handles)*attribute(handletimes))

(i.e take the dot product).
This will work fine, but if the above is your one main use case it may be a bit complicated.

from vespa.

To elaborate on what I meant, by having follows as it's own document type, each edge in your social graph would be represented by a document. This allows some flexibility in maintaining the graph as well as the types of queries you can run (e.g. "who am I following" and "who is following me"). You could also attach additional information to the relationship if you needed that. Queries would return user id's. If you needed actual profile information you could retrieve that in a secondary query in a searcher (kind of like a fill) before returning to the user.

The downside is as Jon mentions a higher document count.

I guess this depends on the type of queries you would like to run?

from vespa.

Thanks for the pointers, guys.

Sounds like the best approach is in-fact a multiphase searcher. As I understand it, the searcher lives in the container cluster, and runs once (as opposed to living container, and running once for each bucket). I'm slightly worried about the memory footprint a searcher might need for a "supernode" query (e.g. a BarackObama type account with 50M followers). We'll try out various methods and report back to this thread later.

from vespa.

@schonfeld Still, if in 1 document, the BarackObama document will be huge!?
So you want to search only inside "follows" or you also want to search the top document "handle=Barack" ?

from vespa.