For some time the OpenNTF Domino API has included Tinkerpop and an implementation to store content in a graph database structure. Recently I’ve been digging into that further for potential projects, prompted also by a redevelopment of that area of the OpenNTF Domino API and Nathan’s upcoming session at DanNotes.
Graph databases are a common concept outside of Domino and an alternative to RDBMS, as Nathan Freeman recently explained in his Modern Domino session at MWLUG. A couple of stand-out points of that session are its use for big data and query performance comparisons to RDBMS.
But from a limited awareness of technologies like OrientDB and Neo4j, many Domino developers may wonder how applicable graph databases are to Domino. I’ve got an NSF, why would I need a different database?
But the question about a different database instead of the NSF is the first key point. Graph databases are more a concept of how to structure and access non-hierarchical content within a database, particularly with Tinkerpop, and less so about where the data is stored. The data itself is stored as separate objects containing key/value pairs, with unique IDs to link Vertices (or Nodes) and Edges. This presentation from Caleb Jones is a good introduction on grpah databases and Tinkerpop.
The second key aspect is that navigating a graph database is not done by browsing a list of all documents of a particular type. For Domino developers, that’s what we’ve been constrained to, because the entry point to documents in the Notes Client is typically a view, scrolled through. Searching is not commonly used as a key method of access. But on the other hand one of the key concepts of graph databases – navigating from a vertex (document) to related vertices – is common in Domino development: embedded views showing child documents.
So why Tinkerpop and the inclusion in OpenNTF Domino API?
Tinkerpop is a Java framework that is an umbrella for various sub-projects. Blueprints is the fundamental aspect and uses Java to handle vertices and edges as Java objects, with a variety of implementations for different back-end data stores (e.g. Neo4j, MongoDB, OrientDB). OpenNTF Domino API has for some time provided another implementation to that – Domino.
But that implementation is currently in the process of being re-written to take advantage of Frames. Frames is the extremely powerful part of Tinkerpop that allows the vertices and edges to be coded using Java interfaces with annotations. It basically rapidly speeds up development of the underlying data model. And it gives a lot of potential for extensibility, to make the concept of using graphs even more appealing.
But for a while now I’ve been trying to use Eclipse Modeling Framework to create UML diagrams that can then be converted into Java classes that can not only be documentation of my application but also speed up development. But EMF cannot be used to create a diagram and document graph databases.
Yet Blueprints not only has implementations but ouplementations, one of which is JUNG, which includes algorithms and visualizations. Over the last few days I’ve been adding that to OpenNTF Domino API and trying to get it work. The outcome is the following diagram of a movie graph database’s structure based on sample data, generated in Eclipse and using AWT:
A couple of points worth noting are that functionality uses an in-memory graph database. It failed when trying to pick up serialized data (i.e. trying to read from a Domino database rather than in-memory objects). And it creates a graph based on actual data objects rather than the abstract interfaces themselves, which is why I created a small, standalone script to create an in-memory graph of sample data rather than querying actual data. The third point is that if any of the labels being passed is blank, the attempt to draw the diagram fails – understandable really and one of the big mistakes I had.
But for documentation and visualization of a data model, it gives a powerful, automated, data-driven alternative to manually creating data models of your systems.