Neo4j Graph Design - Header/Category nodes?

Question

What is the best design for allowing thousands of relationships for a single user?

(Working on a social networking app - if you know of any "generic" social network designs, please point them out.. would be helpful)

See this image - the status updates represent a linked list, while the interests represent misc interests.. Those interests could really blow up to thousands of nodes for a single user - wouldn't that lead to a sort of supernode problem?

Figure 1

Would it be a better design to have a category, or "header" node for those interests, and then have these two interests fall under that category node? I'm thinking that as you initially deal with the user node and just a few relationships/header nodes, it might be more efficient instead of having potentially thousands of nodes directly related to the user node.

Example: FIGURE 2 User
|
+ interests+
+----- interest
+----- interest
+----- etc...

And shouldn't interests also have "sub header" category nodes, such as "books", "movies", "products" like such:

**FIGURE 3**
User
|
+ interests+ 
           + books+
           |      + interest
           |      + interest
           |      + interest
           + movies+<br>
                   + interest
                   + interest
                   + interest

(Obviously I'm a n00b to neo)

Here are my questions:

1. Which model works best for a high performance, scalable, facebook like system - one without categories, or one with? Keep in mind performance..
   

2. interests may not always blow up to thousands of nodes - could be a dozen or 100 - does the adding categories designs add too much overhead? Consider trying to find friends who like the same bood you do - does adding categories add too much overhead?
   

3. Do the latter images - those with category and sub category nodes - do they simply look better but do nothing for performance, organization etc?
   

4. Instead of category nodes, should there just be a category property describing what category it is in? And would would adding nodes with the category property on an index be just as good as having category nodes?
   

5. In regards to question 4, would adding nodes with categories on an index be a better solution?
   

6. What are the disadvantages to this type of structure? Are they any real advantages?
   

Answer 1

I think that the interest categories are a good idea when your interests blow up to hundreds of thousands or millions of connections, if it is only a few thousand it should still work good enough. Perhaps that's even something you can evolve your user-nodes to when you actually need it. (Like a different handling of superstars on twitter).

It all depends also on your use-cases, what kinds of queries would you want to answer with the model, would those be limited to the categories or always query across all categories to the interests below?

Something you always have to take into account, is that the number of relationships touched will grow exponentially with each step you traverse out into the graph. So be aware that if you query from a user to all its friends or friends of friends and all their interests, the number of elements touched grows pretty quickly. Make sure your server has enough memory to keep large enough portions of the graph in memory to answer your requests quickly.

And make sure to do performance and load tests early on (e.g. with a data-generator).

Btw. to filter eagerly it might even be sensible to have a distinct relationship-type per interest, so that you can filter early on without actually following the rels that you are not interested in.

Indexes usually help for global categories, you might index your categories both with their name and the user-id but then you have users times categories index entries which can grow pretty quickly too.

I think the category approach should scale well if your use-case is really about per category and not across all interests (esp. across all users and all interests).