NoSQL Zone is brought to you in partnership with:

Davy Suvee is the founder of Datablend. He is currently working as an IT Lead/Software Architect in the Research and Development division of a large pharmaceutical company. Required to work with big and unstructured scientific data sets, Davy gathered hands-on expertise and insights in the best practices on Big Data and NoSql. Through Datablend, Davy aims at sharing his practical experience within a broader IT environment. Davy is a DZone MVB and is not an employee of DZone and has posted 27 posts at DZone. You can read more from them at their website. View Full User Profile

Get Started with Tinkerpop Blueprints with Concrete Bindings for MongoDB and Datomic

07.25.2012
| 6606 views |
  • submit to reddit

Last week, Datablend open-sourced two new Tinkerpop Blueprints implementations: blueprints-mongodb-graph and blueprints-datomic-graph. Tinkerpop is an open source project that provides an entire stack of technologies within the Graph Database space. At the core of this stack is the Blueprints framework. Blueprints can be considered as the JDBC of Graph Databases. By providing a collection of generic interfaces, it allows to develop graph-based applications without introducing explicit dependencies on concrete Graph Database implementations. Additionally, Blueprints provides concrete bindings for the Neo4J, OrientDB and Dex Graph Databases. On top of Blueprints, the Tinkerpop team developed an entire range of graph technologies, including Gremlin, a powerful, domain-specific language designed for traversing graphs. Hence, once a Blueprints binding is available for a particular Graph Database, an entire range of technologies can be leveraged.

 

1. mongoDB Graph

The mongoDB Blueprints implementation provides users with a scalable, distributed Graph Database implementation. mongoDB graph does not require any information on the underlying physical mongoDB setup, so read/write scalability can easily be achieved through mongoDB’s natively supported replication and sharding functionalities. Some initial benchmarks (writing/reading 100.000 vertices where each 2 vertices are connected through an edge) on a single mongoDB node shows the following performance:

Writing 100.000 vertices and 50.000 edges ...
Writing took: 2760 ms

Reading 100.000 vertices and 50.000 edges ...
Reading took: 646 ms

Not too shabby for running it on a single mongoDB instance. Currently, each write is executed as a singular commit to the mongoDB store. Although this process could be improved by performing writes through optimized batches, we need to ensure that the transactional semantics of the Blueprints stack are still respected. Further performance optimizations will be released soon, so keep an eye on the blueprints-mongodb-graph github project.

 

2. Datomic Graph

Datomic is a novel distributed database system designed to enable scalable, flexible and intelligent applications, running on next-generation cloud architectures. Datomic employs a powerful data model (based upon the concept of Datoms) and an expressive query language (based upon the concept of Datalog. Additionally, it introduces an explicit notion of time, which allows for the execution of queries against both the previous and future states of the database. The RDF and SPARQL feel of the Datomic data model and query approach makes it an ideal target for implementing a property graph. Hence, the blueprints-datomic-graph Blueprints implementation.

Clever use the time-aware nature of the Datomic datastore, makes Datomic Graph the very first distributed, temporal graph database: users can perform queries against a specific version of the graph in the past. The code sample below illustrates how a time-aware social graph can be created, stored and queried through the Datomic Graph implementation.

// Create the datomic-based graph
DatomicGraph graph = new DatomicGraph("datomic:mem://tinkerpop");

// Create the vertex for Davy
Vertex davy = graph.addVertex(null);
davy.setProperty("name","Davy");

// Create the vertex for Marko
Vertex marko = graph.addVertex(null);
marko.setProperty("name","Marko");

// Add the knows-relationship between Davy and Marko
Edge davy_marko = graph.addEdge(null, davy, marko, "knows");

Thread.sleep(1000);
Date checkpoint = Calendar.getInstance().getTime();
Thread.sleep(1000);

// Reset the name of Davy
davy.setProperty("name","DavyUpdated");

// Create the vertex for Peter
Vertex peter = graph.addVertex(null);
peter.setProperty("name","Peter");

// Add the knows-relationship between Marko and Peter
Edge marko_peter = graph.addEdge(null, marko, peter, "knows");

// Retrieve all "knows" relationships that are "currently" in the database
System.out.println("Current relationships:");
Iterator<Edge> edgesit = graph.getEdges().iterator();
while (edgesit.hasNext()) {
    Edge edge = edgesit.next();
    System.out.println(edge.getVertex(Direction.OUT).getProperty("name") + " -> " + edge.getLabel() + " -> " +
                       edge.getVertex(Direction.IN).getProperty("name"));
}

// Set the checkpoint in the past
graph.setCheckPoint(checkpoint);

// Retrieve all "knows" relationships that were in the database at the specified checkpoint
System.out.println("Relationships at checkpoint " + checkpoint + ":");
edgesit = graph.getEdges().iterator();
while (edgesit.hasNext()) {
    Edge edge = edgesit.next();
    System.out.println(edge.getVertex(Direction.OUT).getProperty("name") + " -> " + edge.getLabel() + " -> " +
                       edge.getVertex(Direction.IN).getProperty("name"));
}

As one would expect, this outputs the following information:

Current relationships:
DavyUpdated -> knows -> Marko
Marko -> knows -> Peter

Relationships at checkpoint Tue Jul 23 20:21:17 CEST 2012:
Davy -> knows -> Marko

Datomic Graph does not only support versioning of the vertices and edges, but also on the properties of individual vertices/edges. Pretty slick, not? We are currently enhancing the implementation with additional time-based operations, including the easy comparison of subgraphs over time. So stay tuned!

Published at DZone with permission of Davy Suvee, author and DZone MVB. (source)

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)