The title of this post does not reflect the content of the groups discussion. It sounds like Titan will be largely handed off to the community, while the former Titan team will start to work on a new product (DSE Graph).
Titan in my opinion is the most promising Big Data graph DB around, due to the fact that it works on top of Cassandra (and HBase).
But, there are other very good graph DBs out there too, like OrientDB.
What is important in my opinion, is for all of these graph DBs to embrace the Tinkerpop Blueprints graph API (which Titan and OrientDB do). https://github.com/tinkerpop/blueprints/wiki
I didn't have any performance issues with OrientDB, but it's worth noting that I worked with relatively small datasets (e.g. graphs with ~1000 edges).
Titan, given that it runs on HBase or Cassandra, is on a whole different level compared to these two graph DBs. If you're working on a small app which needs an ebedded graph DB, you'll definitely not use Titan.
I've used both. Titan is not anywhere near production ready. And now it seems like they won't ever be. It's not even a real database. It's a library. You can't even delete indexes once you create them. I don't get why anyone would go with them. (Is this still the case or did they resolve that index issue?) Either way, OrientDB is more mature/stable and was much faster than Titan. Then, OrientDB is a multi-model, so it just has so much more capabilities compared to just a graph database. IMHO, Titan seemed like a toy in comparison.
We started a project a while ago using Titan that is starting to come to fruition, and we went with Titan because it looked to be one of the only options that could scale to where we needed (around ~500M vertices, probably 10x that in edges) and worked on top of our existing infrastructure (HBase). Neo4J definitely wouldn't work for that, though looking at OrientDB again it seems like it might, though we'd have to figure out the operational implications of a new clustered technology.
Fortunately we've been using the Tinkerpop API so it should be fairly inter-changable on the back end, we're definitely going to have to look into other options now that Aurelius has been acquired.
I don't know where you got the impression from that Neo4j can't handle graphs of this size. We have users and customers running much larger graphs in production. So that _definitive fact_ is not true :)
I'm willing to believe that Neo4j could handle it (admittedly this research is 18 months old), but everything I see about the Neo4J licensing model indicates we could not link to it without also opensourcing our code, which is a no go for us.
The submitted title was "DataStax's new DSE Graph Database will be based on Titan". We changed it to the article title in the absence of anything more objective.
That is kind of an odd move, going away from OSS? I guess people have to pay the bills somehow. I'm working on a graph database as well (with realtime push notifications built in, https://github.com/amark/gun ) but thankfully I've gotten funding for it. Sad to see proprietary DSE absorb focus.
Title really should be updated since I can think of a half dozen things called "Titan" from the last two decades and there's no hint as to which one this is.
The fact that DataStax, the company behind Cassandra (the main db where Titan runs), analyzed Titan and said "Hey, this software is crap. Let's put it in the trashcan and redo it from scratch with the support of our team" means something, right?
I can't understand people that appreciate Titan: it's just a library on top of a DBMS that is not even Graph. It's definitely not a Graph Database. People love buzzwords, but who is using it in production? I mean, real production? If you wanna do just Graph Processing you have plenty of choices like Spark+GraphX, Giraph, etc.
If people are using Cassandra already why not just use Titan?
If it's built on top of something you're already maintaining why not. It make sense.
GraphX last I check was in beta, at least last databrick meetup stated so.
GraphX would make sense if you're stack is cassandra + spark.
For me personally, I have time to wait to see if Flink will mature and interop with Cassandra before I invest my time in Spark or Flink (or both if I have the luxury).
I think everyone should evaluate the options with your own data to see which graph database fits their needs. Depending if you just want to run private or research projects or production applications you use different factors for deciding if a technology is good and mature enough. There are more than enough options to chose from: http://db-engines.com/en/ranking/graph+dbms
I personally had a project almost ready for beta when the news came out. I jumped ship to OrientDB. Titan was very buggy but we all awaited in hope for the 1.0 release. That's not going to be good now if it's not released from the original devs. Orient can handle 9 trillion records, Neo4j 34 billion. There is a benchmark with Orient outperforming 10x neo and can also handle docs like mongo. I regretted that I chose Titan.
22 comments
[ 2.6 ms ] story [ 70.4 ms ] threadTitan was (design-wise) by far the most promising FLOSS graph database around, it's really sad to see it going away.
But, there are other very good graph DBs out there too, like OrientDB.
What is important in my opinion, is for all of these graph DBs to embrace the Tinkerpop Blueprints graph API (which Titan and OrientDB do). https://github.com/tinkerpop/blueprints/wiki
I didn't have any performance issues with OrientDB, but it's worth noting that I worked with relatively small datasets (e.g. graphs with ~1000 edges).
Titan, given that it runs on HBase or Cassandra, is on a whole different level compared to these two graph DBs. If you're working on a small app which needs an ebedded graph DB, you'll definitely not use Titan.
http://thinkaurelius.com/2013/11/24/boutique-graph-data-with... (good in-memory performance -- like Neo4j)
http://thinkaurelius.com/2013/03/30/titan-server-from-a-sing... (if you do grow, its easy to add more machine)
Fortunately we've been using the Tinkerpop API so it should be fairly inter-changable on the back end, we're definitely going to have to look into other options now that Aurelius has been acquired.
That ~5B edges is roughly where we're currently at, however that is growing and the limit of 34B is under 10x of where we're currently at.
http://thinkaurelius.github.io/titan/
which was recently acquired
http://venturebeat.com/2015/02/03/datastax-acquires-aurelius...
I can't understand people that appreciate Titan: it's just a library on top of a DBMS that is not even Graph. It's definitely not a Graph Database. People love buzzwords, but who is using it in production? I mean, real production? If you wanna do just Graph Processing you have plenty of choices like Spark+GraphX, Giraph, etc.
If it's built on top of something you're already maintaining why not. It make sense.
GraphX last I check was in beta, at least last databrick meetup stated so.
GraphX would make sense if you're stack is cassandra + spark.
For me personally, I have time to wait to see if Flink will mature and interop with Cassandra before I invest my time in Spark or Flink (or both if I have the luxury).