http://thinkaurelius.com/2013/05/13/educating-the-planet-wit... (cluster-sized graphs OLTP)
http://thinkaurelius.com/2012/11/11/faunus-provides-big-grap... (OLAP engine)
http://thinkaurelius.com/2013/11/24/boutique-graph-data-with... (single-machine sized graphs OLTP)
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.
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.
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.
Titan underwent major changes to optimize in-memory operations. Here is some up-to-date info on that: http://thinkaurelius.com/2013/11/24/boutique-graph-data-with...
IIRC, the euranova benchmark doesn't discuss scalability. This post does: http://thinkaurelius.com/2013/05/13/educating-the-planet-wit...
Graph Computing at Scale http://www.infoq.com/presentations/scaling-graphs
