A Case for Graph Databases

| by Jonathan Allen on Sep 15, 2010. Estimated reading time: 3 minutes |

We talk with Daniel Kirstenpfad, founder and CTO of sones GmbH about Graph Databases and how they can better model some types of data such as relations in a social networking application.

Can you explain what a graph databases is and why developers would choose one over a tradition database?

Unlike other databases which store their data in rows, columns or key-value pairs a graph database stores all information in a network of nodes and edges. Edges manifest the connection between nodes which effectively represent objects. Because Edges and Nodes are represented as objects (like objects developers are used to) one can assign attributes (sometimes called properties) to them. Adding a direction to an edge ultimately creates a so-called property graph which represents the explicit structure of data inside a graph database.

So unlike other database approaches which only implicitly can form a graph structure a graph database explicitly represents a graph. And while other databases need to use indices and relational helpers (like relational tables which are coupled using JOINs) a graph database can traverse from one object to the next objects because those objects are organized to have index free adjacency.

There are many use-cases where a graph database is the most natural approach. For example in social networks it's easier to use a graph data structure to represents friend relations and do traversals and queries like "get me all the friends of my friends friends". Additionally common graph based algorithms like path-searches are easy to implement by traversing through the graph.

Beside all those great features the sones GraphDB also offers an easy to learn and use query language which allows the user to run ad-hoc queries just like he was used to with SQL databases. The above example would result in a query like: FROM Users u SELECT u.Friends.Friends.Friends WHERE Name = "Daniel"

Can your product run embedded or only as a separate service?

The sones GraphDB can be embedded into almost any application. Because it's written in C# (.NET) it can naturally integrate into an existing .NET environment which can be Microsoft .NET on Windows or Mono on any other platform. With our current products we're focusing on the client-server approach offering different interfaces. For example our product comes with integrated selfhosting REST interface. Selfhosting means you won't need any 3rd party service to host a GraphDB. It comes all included in one package.

Is there a .NET API available?

A .NET API is available and included in the current publicly available release. This API can be used in an embedded environment and is demoed that way in the sonesExample source code ( -> see line 74, 94, 114, 197,...)

We are currently in the process of adding a .NET client library to allow object oriented access to a sones GraphDB server without having to leave the known space of C# and without having to parse through JSON or XML. This library is planned to be available for Java as well.

To drive things even further we're planning on making that client library useable through LINQ.

Were any changes necessary to offer the Windows Azure version?

Giving the complexity of a cloud service infrastructure it was surprisingly easy to allow our GraphDB product to run on Windows Azure. We had to add mostly glue code to help the GraphDB to communicate its status to the Windows Azure infrastructure. All in all it was only new code added to the GraphDB to offer the Windows Azure version. No code needed to be changed in the core and interfaces.

Currently we are adding several new modules to GraphDB - one of which is a module which uses the Azure Page Blob Storage technology to persist a graph database and in doing that allows even more interesting usage scenarios for our customers.

Are there any other graph databases that you would consider a competitor?

There are a number of graph databases available which are mostly tailored especially to meet one or several use-cases and as always it's great for customers to have choice. Since sones started to create an enterprise grade database management system we're aiming to ultimately achieve the goal of creating no more than that. For some use-cases we are seeing competition from products like Infogrid, Neo4j or InfiniteGraph. When it comes to features like an easy to use and intuitive query language, .NET integration or a state-of-the-art data storage technology which allows not only to store graphs but also large binary data along with versions and editions we think we have many unique selling points.

Rate this Article


Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Tell us what you think

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

1969 called... by Luke McCarthy

...they want their database model back

Neo4j by Anders Nawroth

Here's some more InfoQ content on graph databases:

Re: 1969 called... by Russell Leggett

Just because an idea isn't new, doesn't mean there's no case for it. Though it bears a close resemblance to the old "navigational database" model, look at it for what it offers. With all the data stored in memory instead of magnetic tape the approach can be extremely efficient and has a distinct advantage in many common cases. Emil Eifrem (creator of Neo4j) is always quick to point out the spectrum of database models and that they are not one size fits all. I think the whole NoSQL movement really just makes the case that relational doesn't have to be the default answer. It isn't perfect for everything.

nice news by tou cao

they want their database model back aspx file

great news by tou cao

dba want it csharp

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

5 Discuss