AWS NoSQL or AWS RDS, what are the good ways to store social graph?

Question

Recently I want to store some social graph information into our database, and user discovers new social nodes by an automatic "mapping" that happens on the server end which has the social graph.

Background: Each time a new client visits, I store his/her existing social nodes from some other sources, one good example is Facebook. So I have a list of Facebook friends as well as the Facebook ID of that client and I store those in my database. The server then tries to match each item in the client's list of friends with existing clients. If there is a match, it means this client has friends using my service. The server then returns a matched list and marks the match on the other side of the edges. The next time the clients' friends come back, they will receive a notice as well of a done matching.

Obstacles: My problem is that this mechanism requires the server to store the complete list of clients' social graph, in my example this is the clients' complete list of Facebook friends. Since this social graph can be arbitrarily large, I certainly cannot store it into one single item, but span it across multiple items or rows with client ID and friend ID pair. If I store it this way, then the keys can be distributed pretty unevenly which means I cannot use DynamoDB. However I want to explore the possibilities of storing it in some AWS NoSQL services to gain the fast access advantage.

So are there good ways to store these data in AWS NoSQL servers? Or what are the optimizations that we can do to put them in RDS but not losing too much efficiency?

Answer 1

Actually, DynamoDB might work quite well for your use case... DynamoDB supports multi-value fields and has a maximum record size of 64k.

So you would create a 'friends' table of two columns with 'clientId' as your hashkey, and then 'friendId' as multi-value field.

This means you would only need to one record to store the complete friends list for a user (up to about 4,000 friends assuming a GUID as a 'friendId'). And if needed you could use multiple records for your users with more than 4,000 friends...