11–19 of 19 posts
This might a stupid question but is this competing with Neo4j or Giraph? I didn't see a mention of comparison with either in the docs. I believe graph data storage and graph processing are two different things - is TItan doing both?
Might find this interestign: http://euranova.eu/upl_docs/publications/an-empirical-compar...
I would love to hear about peoples experiences working with Titan (or other graph dbs, for that matter) - I've been following the project with interest for some time now. If you don't want to comment on HN I'd really appreciate an email to craig dot glennie gmail
We like it so far, but are having some issues with the server crashing. I'll update to this release and see if it fixes our issues.
For those interested in Titan 1.0 roadmap and the evolution of the Titan OLTP/OLAP story. Titan will be implementing TinkerPop3 API http://www.tinkerpop.com/docs/current/ ... Currently, Titan 0.5.0 leverages the Faunus Gremlin compiler ( http://faunus.thinkaurelius.com ), but with TinkerPop3, TinkerPop3 provides an OLAP compiler for Gremlin that will make things easier for Titan as well as other graph computing engin…
IMHO the project made a critical design error by trying to be backend agnostic. From a technical perspective, that gives the worst of all worlds for everyone involved.
Graph Computing at Scale http://www.infoq.com/presentations/scaling-graphs
For those interested in Titan 1.0 roadmap and the evolution of the Titan OLTP/OLAP story. Titan will be implementing TinkerPop3 API http://www.tinkerpop.com/docs/current/ ... Currently, Titan 0.5.0 leverages the Faunus Gremlin compiler ( http://faunus.thinkaurelius.com ), but with TinkerPop3, TinkerPop3 provides an OLAP compiler for Gremlin that will make things easier for Titan as well as other graph computing engin…
We are getting a bunch of exceptions because of the Gremlin complier, I hope that TinkerPop complier performs better.
Does this one work? I spent a bit of time playing with Titan earlier this year before passing and moving on. IMHO the project made a critical design error by trying to be backend agnostic. From a technical perspective, that gives the worst of all worlds for everyone involved.
Does this one work? I spent a bit of time playing with Titan earlier this year before passing and moving on. IMHO the project made a critical design error by trying to be backend agnostic. From a technical perspective, that gives the worst of all worlds for everyone involved.
Yes, it works :-) Support for multiple storage backends gives Titan a lot of deployment flexibility and allows it to inherit some great features like multi DC support. Software component reuse is pretty standard these days. What lead you to the conclusion that it is the worst of all worlds?
Why do you need both a BerkeleyDB and PersistIt backend? At the absolute most you should have 2 or 3. Single Machine, AP Cluster, ACID Cluster.
7 backends means 7 different database products, with the same API facade. Duh right? Well the problem is that constrains your API to a least common denominator feature set, limiting access to the unique attributes and capabilites of the underlying backend. Not to mention completely abstracting away memory/disk issues. This is a really big issue with your approach. You have some sunken costs here but I think eventually you will see the value in tightening up your focus.