Titan: Distributed Graph Database | Hacker News Reader

Titan: Distributed Graph Database

thinkaurelius.github.io

48 pointsnawazdhandala17 comments

For those who, like me, were looking at the master branch and assumed the codebase was inactive, this is apparently the branch where development is happening:

https://github.com/thinkaurelius/titan/tree/titan09

This is version 0.9, and they are gearing up for a 1.0 release.

Anyone here using it who can summarize their experience? Production-readiness, performance, general usability as an alternative to other NoSQL databases?

It got acquired by DataStax, for better or worse. So it will be actively developed, but might get harder to use in pure OSS (documentation, howtos, etc)

The company was acquired, but according to the original announcement, it wasn't to work on Titan, but on a new graph database product. Sounds like maybe that didn't work out?

There's no mention of this in their READMEs, but Titan can work with Dynamo DB as a storage back-end: http://www.allthingsdistributed.com/2015/08/titan-graphdb-in...

Is there a list of backends? Is PostgreSQL supported?

For graph-based PostgreSQL, check out Sqlg (http://umlg.org/sqlg.html).

As another commentator mentioned, http://orientDB.com/ looks interesting as well.

Those complaining about Titan being abandoned, don't worry. Getting better graph features into the Cassandra family is one of the best things they could do. So consider this a win-win.

For those looking for a javascript variant, check out my project http://gunDB.io/ which is a browser based graph database. Definitely not as "academic" leaning as Titan, but it is more friendly towards web developers which Titan is not.

gunDB looks like mozilla's kinto: https://kinto.readthedocs.org/en/latest/

why would you post a link to a project that the founders abandonded to go to work for Datastax? It was all over the news some months ago

It's not abandonned, they are working on releasing a new version [1] and amazon support officially a backend for dynamodb [2] and IBM use it too [3]

[1] https://groups.google.com/forum/#!topic/aureliusgraphs/A53p9...

[2] http://www.allthingsdistributed.com/2015/08/titan-graphdb-in...

[3] It seems like IBM forked the project

The original devs said they would work to release version 1 and then stop and let it be with open source but you know well that open sources projects when all the devs go usually die or are forked like in case of IBM. The future will show

Titan 1.0 will be released this month (September). It will support TinkerPop 3.0.1.

I suppose our communication around Titan has caused some confusion after the acquisition by DataStax. As one of the Titan devs I can say that we have no plans to abandon Titan. What we were trying to say is that we will have less time to dedicate to the project in order to encourage others in the community to step up and contribute. That has happened. Over the last couple of months, other Titan users have actively helped out on the mailing list to get newcomers started and contributed bugfixes and features via pull requests. This has allowed us to keep the Titan 1.0 release on its original plan date. What we are trying to do is make the Titan project less dependent on Dan and myself and more open and inviting to other developers who wish to contribute. For instance, we have dedicated more time than usual to reviewing PRs then before. I realize there is still more work that we need to do here but so far the increased contributions have been an encouraging sign that we are heading in the right direction. So, Titan is here to stay and - as others have pointed out - there is more momentum than ever behind the project.

I need a distributed, scalable solution for querying set intersections. Before rolling my own I may give this a chance, though Apache accumulo looks like the first option.

I suppose it's a difference in terminology, but it seems strange for them to state:

> Support for ACID and eventual consistency.

As ACID typically implies strong consistency. To quote the wikipedia page on eventual consistency that they link to:

> Eventually consistent services are often classified as providing BASE (Basically Available, Soft state, Eventual consistency) semantics, in contrast to traditional ACID (Atomicity, Consistency, Isolation, Durability) guarantees.

"Support for" implies it's capable of these guarantees independently but doesn't necessarily mean it's capable of both of them simultaneously, IE it may be configured for one or the other.

another very interesting project http://orientdb.com/orientdb/

Reply on news.ycombinator.com