5 ms·
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 t
by grizzles 12y ago
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.
- mbroecheler 12y agoYes, 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?
- grizzles 12y agoI think you've documented some of the issues on the Titan Limitations page. For us, we couldn't get Titan to work properly, which we documented in the Issue Tracker. That lead me to the conclusion that Titan was just too complex because from my perspective it's obvious that you guys are spreading yourselves too thin with the 7 different backends. 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.