Question

I am doing a system similar to a social network. The number max of users must be eventually 50.000 or 70.000 at best.

At the moment i am using mysqli+prepared statments. The ERD have now 30 tables, eventually may reach to 40 tables.

So, my question is: i never used a graph database…i have the ERD done by mysql workbench and some code already developed. For the number expected of the users in this project, is recommended change from MySQL to a graph database? my sql code and database model can be availed? there is any advantage with this change?

what do you think ?

thanks

Answer 1

Graphs are nice and fast when stored in SQL, if you’ve access to recursive queries (which is not the case in MySQL, but which are available in PostgreSQL) and your queries involve a max-depth criteria (which is probably your case on a social network), or if they’re indexed properly.

There are multiple methods to index graphs. In your case your graph probably isn’t dense, as in you’re dealing with multiple forests which are nearly independent (you’ll usually be dealing with tightly clustered groups of users), so you’ve plenty options.

The easiest to implement is a transitive closure (which is, basically, pre-calculating all of the potential paths is called). In your case it may very well be partial (say, depth-2 or depth-3). This allows to fully index related nodes in a separate table, for very fast graph queries. Use triggers or stored procedures to keep it in sync.

If your graph is denser than that, you may want to look into using a GRIPP index. Much like with nested sets, the latter works best (as in updated fastest) if you drop the (rgt - lft - 1) / 2 = number of children property, and use float values for lft/rgt instead of integers. (Doing so avoids to reindex entire chunks of the graph when you insert/move nodes.)