Get Even More Visitors To Your Blog, Upgrade To A Business Listing >>

Why we specialize in graph databases?

Modeling geographical and social networks are a problem for traditional relational databases. It is inherently more difficult to model interconnected networks using SQL and tables compared to the naturalness of how graph databases perform. Let us explain why using a practical example.

For the sake of example, let's model a simple friendship relationship in a social network between two Users. For expressing this relationship in SQL we would start by defining a User-table:

CREATE TABLE USER (
id INT(11) NOT NULL AUTO_INCREMENT,
PRIMARY KEY (id)
);


A reference table is needed to keep track of friends:


CREATE TABLE `friends` (
`from_id` int(11) NOT NULL,
`to_id` int(11) NOT NULL
);


That was the definition of the data model, let's insert some data:

insert into user values (1);
insert into user values (2);
insert into friends values (1,2);
insert into user values (3);
insert into friends values (2,3);


To query this data in order to extract friends 1 level down we would need a SQL query like this:

SELECT *
From USER u
LEFT OUTER JOIN FRIENDS f ON f.from_id = u.id
LEFT OUTER JOIN FRIENDS f2 ON f.to_id = f2.from_id
WHERE u.id = ?


Doing 3 levels would look something like:

SELECT *
FROM USER u
LEFT OUTER JOIN FRIENDS f ON f.from_id = u.id
LEFT OUTER JOIN FRIENDS f2 ON f.to_id = f2.from_id
LEFT OUTER JOIN FRIENDS f3 ON f2.to_id = f3.from_id
WHERE u.id = ?


As we can see the number of joins increases per level we go down, and these simplified SQL statements are specific to finding friends at a specific depth. With time the traditional model grows in complexity and error rate as the network grows larger. How would we even make this more dynamic so as to achieve unlimited levels of friendships?

The underlying problem is not even the SQL language itself (inexpressive, but also useful, as it is), but the data structure itself. As you can see expressing interdependent networks in SQL becomes difficult and complex because such networks are by nature actually graphs.

Graph databases and graph based data modeling can express such relationships in a natural and programmer friendly way. This is how we do in Cypher to drill down infinite levels of friendships:

START n = node({id}) MATCH n-[:FRIEND*]->u RETURN n

Expressing the relationship FRIEND in code is done by annotating the data properties of entities, like this:

@RelatedTo(type = FRIEND, direction = Direction.BOTH)
Set friends = new HashSet();


While the relational database performance dies after drilling into a few levels of friendships a graph database is still thriving, as shown by this performance test between MySQL and a leading graph database. An example out of that report is that MySQL never finishes processing a network of a million users while the graph database performs the traversal in 2.1 seconds.

Because graph databases are so fast we a able to perform real time live searches through any network in real time, while publishing the results to a live map.

With the adaptation of the application programming model to a graph based structure we also gain ease of development of social functions and solutions. This is how we can be inherently more social. We want to enable you to navigate and to discover, while maintaining control over your data as well as your privacy.







This post first appeared on GeomarketingFactory, please read the originial post: here

Share the post

Why we specialize in graph databases?

×

Subscribe to Geomarketingfactory

Get updates delivered right to your inbox!

Thank you for your subscription

×