6 ms·

How is OrientDB compared to Titan? Whenever I have looked, I've only seen people saying how it underperforms in comparison.

moondowner 12y ago
OrientDB is more similar to Neo4j, http://www.orientechnologies.com/orientdb-vs-neo4j/ http://www.orientechnologies.com/orientdb-vs-neo4j/ and some folks think of it as a decent alternative to it https://medium.com/@KevinHoffman/first-exposure-to-orientdb-9e6f3aeabd63 https://medium.com/@KevinHoffman/first-exposure-to-orientdb-... 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.
- okram 12y ago
  There are some compelling reasons to use Titan at smaller scales: http://thinkaurelius.com/2013/11/24/boutique-graph-data-with-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-single-server-to-a-highly-available-cluster/ http://thinkaurelius.com/2013/03/30/titan-server-from-a-sing... (if you do grow, its easy to add more machine)
vlad72 12y ago
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.
- amp 12y ago
  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.
  - jexp 12y ago
    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 :)
    - amp 12y ago
      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.
    - amp 12y ago
      On a another note, I do recall a bit about where I had the capacity impressions from: http://neo4j.com/docs/stable/capabilities-capacity.html http://neo4j.com/docs/stable/capabilities-capacity.html 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.
- deleted 12y ago
  [deleted]

moondowner 12y ago

OrientDB is more similar to Neo4j, http://www.orientechnologies.com/orientdb-vs-neo4j/ http://www.orientechnologies.com/orientdb-vs-neo4j/ and some folks think of it as a decent alternative to it https://medium.com/@KevinHoffman/first-exposure-to-orientdb-9e6f3aeabd63 https://medium.com/@KevinHoffman/first-exposure-to-orientdb-... 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.

okram 12y ago
There are some compelling reasons to use Titan at smaller scales: http://thinkaurelius.com/2013/11/24/boutique-graph-data-with-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-single-server-to-a-highly-available-cluster/ http://thinkaurelius.com/2013/03/30/titan-server-from-a-sing... (if you do grow, its easy to add more machine)

vlad72 12y ago

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.

amp 12y ago
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.
- jexp 12y ago
  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 :)
  - amp 12y ago
    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.
  - amp 12y ago
    On a another note, I do recall a bit about where I had the capacity impressions from: http://neo4j.com/docs/stable/capabilities-capacity.html http://neo4j.com/docs/stable/capabilities-capacity.html 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.
deleted 12y ago
[deleted]