Object oriented programming in Graph databases

Question

Graph databases store data as nodes, properties and relations. If I need to retrieve some specific data from an object based upon a query, then I would need to retrieve multiple objects (as the query might have a lot of results).

Consider this simple scenario in object oriented programming in graph-databases:

I have a (graph) database of users, where each user is stored as an object. I need to retrieve a list of users living in a specific place (the place property is stored in the user object). So, how would I do it? I mean unnecessary data will be retrieved every time I need to do something (in this case, the entire user object might need to be retrieved). Isn't functional programming better in graph databases?

This example is just a simple analogy of the above stated question that came to my mind. Don't take it as a benchmark. So, the question remains, How great is object oriented programming in graph-databases?

Answer 1

A graph database is more than just vertices and edges. In most graph databases, such as neo4j, in addition to vertices having an id and edges having a label they have a list of properties. Typically in java based graph databases these properties are limited to java primatives -- everything else needs to be serialized to a string (e.g. dates). This mapping to vertex/edge properties can either be done by hand using methods such as getProperty and setProperty or you can something like Frames, an object mapper that uses the TinkerPop stack.

Answer 2

Each node has attributes that can be mapped to object fields. You can do that manually, or you can use spring-data to do the mapping.

Answer 3

Most graph databases have at least one kind of index for vertices/edges. InfiniteGraph, for instance, supports B-Trees, Lucene (for text) and a distributed, scaleable index type. If you don't have an index on the field that you're trying to use as a filter you'd need to traverse the graph and apply predicates yourself at each step. Hopefully, that would reduce the number of nodes to be traversed.

Answer 4

Blockquote I need to retrieve a list of users living in a specific place (the place property is stored in the user object).

There is a better way. Separate location from user. Instead of having a location as a property, create a node for locations. So you can have (u:User)-[:LIVES_IN]->(l:Location) type of relationship.

it becomes easier to retrieve a list of users living in a specific place with a simple query:

match(u:User)-[:LIVES_IN]->(l:Location) where l.name = 'New York'.
return u,l.

This will return all users living in New York without having to scan all the properties of each node. It's a faster approach.

Answer 5

Why not use an object-oriented graph database?

InfiniteGraph is a graph database built on top of Objectivity/DB which is an massively scalable, distributed object-oriented database.

InfiniteGraph allows you to define your vertices and edges using a standard object-oriented approach, including inheritance. You can also embed a defined data type as an attribute in another data type definition.

Because InfiniteGraph is object-oriented, it give you access to query capabilities on complex data structures that are not available in the popular graph databases. Consider the following diagram:

In this diagram I create a query that determines the inclusion of the edge based on an evaluation of the set of CallDetail nodes hanging off the Call edge. I might only include the edge in my results if there exists a CallDetail with a particular date or if the sum of the callDurations of all of the CallDetails that occurred between two dates is over from threshold. This is the real power of object-oriented database in solving graph problems: You can support a much more complex data model.

I'm not sure why people have comingled the terms graph database and property graph. A property graph is but one way to implement a graph database, and not particular efficient. InfiniteGraph is a schema-based database and the schema provides several distinct advantages, one of which object placement.

Disclaimer: I am the Director of Field Operation for Objectivity, Inc., maker of InfiniteGraph.