A quick history lesson
Back in February 2015, Aurelius – the organization behind the Titan graph database – was acquired was acquired by DataStax. It was unclear whether the Titan project had a future. Would it be carried on by the community? Would DataStax through their enterprise might behind it?
What actually happened was more confusing. In the end, the Titan project did slow, resulting in a number of competing spinouts. Here’s the Cliffnotes version:
- February 2015: DataStax acquire Aurelius, the company behind nascent the TitanDB. Aurelius promise Titan ‘is not going away’.
- September 2015: Titan 1.0 is released, making use of the Apache-incubated TinkerPop3 stack. To date, this is the first and last stable TitanDB release. The Aurelius team presumably turn their attentions back to DataStax, which is planning its own graph database announcement…
- April 2016: DataStax Enterprise (DSE) Graph database is launched. DSE Graph incorporates TitanDB’s distributed graph setup, but with even closer integration with Cassandra.
- July 2016: Perhaps sensing a little frustration in the Titan community (or just the strength of interest in graph databases) IBM releases their own fork of the Titan project: IBM Graph. It’s a fully managed and hosted distributed graph database.
- January 2017: An on-premise distributed graph database called JanusGraph database is released. It’s a fork of TitanDB, backed by The Linux Foundation with participants from Expero, Google, IBM and Hortonworks.
- October 2017: IBM announces the deprecation of IBM Graph, encouraging users to switch to JanusGraph on Compose instead.
That’s where today’s blog post begins.
The JanusGraph database may have a complex heritage, but beneath the surface it’s running on the Titan graph database. That means you get Titan’s scalability, performance and back-end flexibility, with the reassurance of big-name backers in the community.
It also means it’s remarkably easy to integrate with KeyLines to help you visualize your graph data.
Let’s see how it works.
Integrating KeyLines with JanusGraph
Step 1: Install JanusGraph
We found this process pretty straightforward, using JanusGraph’s own documentation.
Out of the box, JanusGraph has a handy range of different configs. It supports all the same persistence engines as Titan (Apache Cassandra, HBase and Oracle BerkeleyDB) plus Google Bigtable. It also supports Spark, Giraph and Hadoop for analytics, and Elasticsearch, Solr and Lucene for as ‘index backends’ for search.
In this example, I chose to use Cassandra as my persistence engine with Elasticsearch as the indexing system, but the JanusGraph documentation explains all the different combinations.
Step 2: Connect to JanusGraph
Next up, I need to create my client to connect KeyLines to the JanusGraph instance I’ve got running. Like TitanDB, JanusGraph is queried using Gremlin. It uses a Websocket connection, giving performance that’s ideal for real-time or data streaming scenarios.
To make life easier, there’s a Gremlin JavaScript client available to bridge between KeyLines and the JanusGraph Gremlin server, so my integration code is straightforward:
import { createClient } from 'gremlin';
const client = createClient(8182, 'janusgraph.server.address');
client.execute('g.V().has("name", name)', { name: 'Alice' }, (err, results) => {
if (err) {
return console.error(err)
}
console.log(results);
});
Or if you prefer your JavaScript ES6 flavored…
import { createClient, makeTemplateTag } from 'gremlin';
const client = createClient(8182, 'janusgraph.server.address');
const gremlin = makeTemplateTag(client);
const fetchByName = async (name) => {
const results = await gremlin`g.V().has('name', ${name})`;
console.log(results);
}
fetchByName('Alice');
At this point, we have a running JanusGraph instance, and an interface between it and our KeyLines application to fetch data back and forth.
Step 3: Format the data
KeyLines is a database agnostic visualization tool, so you’re able to fetch data from any source and visualize it in a KeyLines chart. The only requirement is that your data be parsed into KeyLines’ required JSON format first.
As a graph database, JanusGraph is well suited to this. Our data is already stored and queried as nodes and links (or vertices and edges, at least) and the data already comes back as JSON.
We just need to format it into KeyLines JSON, defining nodes, links and properties:
function makeKeyLinesItems(results) {
var items = [];
json.forEach(function(data) {
var objects = data.objects;
objects.forEach(function(object) {
if (object.type === 'vertex') {
items.push({
id: object.id,
type: 'node',
// Get the `title` property from the returned dataset
t: object.properties.title[0].value,
ci: true,
// Save the item on the node in case we need more info
d: item.properties
});
} else if(object.type === 'edge') {
items.push({
id: object.id,
type: 'link',
id1: object.outV,
id2: object.inV,
// Show a link label
t: object.properties.role,
// Save the entire edge on the link for future use
d: object
});
}
});
});
return items;
}
Step 4: Load the data into KeyLines
The final step is to run some code that submits a Gremlin query to load your JanusGraph data into the KeyLines chart. It would look similar to this:
import { createClient } from 'gremlin';
const client = createClient(8182, 'janusgraph.server.address');
client.execute('g.V().has("name", name)', { name: 'Alice' }, (err, results) => {
if (err) {
return console.error(err)
}
var keyLinesItems = makeKeyLinesItems(results);
chart.load(keyLinesItems);
});
Step 5: Customize your KeyLines app
And that’s it! That’s all you need to do to get KeyLines communicating with a JanusGraph backend.
There are some further steps required to customize your KeyLines application’s styling and UX. There’s plenty of inspiration and demos to get you started on the KeyLines SDK.
FREE: Start your KeyLines trial today
Visualize your data! Request full access to our KeyLines SDK, demos and live-coding playground.
