Consolidating graphs and other matters

The graph database market is starting to show signs of consolidation. Which is not surprising when you consider that there are far too many vendors and/or projects in this space. The first to go, as far as I am aware, was 4Store, which was acquired by Experian for internal use – so that’s been lost to the market (as has 5Store). Most recently (today as I am writing) DataStax has announced that it has acquired Aurelius, the developer of the Titan graph database.

DataStax will be well known for Cassandra and its NoSQL offerings, so this is an interesting move into an associated area. As it happens, one of the platforms that Titan runs on is Cassandra but it also runs on Berkeley DB and HBase and, in principle, it can run on any version of BigTable. The question is whether the product will be developed henceforward as specifically a Cassandra implementation or not. Another question derives from the fact that Titan is being used in a number of projects under development by a rather well known relational database vendor (which will remain nameless) that might consider DataStax to be competitive with its own NoSQL offering. Will this relationship with Titan continue now that it has changed owners?

One almost certainly good thing to come out of this acquisition is that Titan is likely to be much more aggressively marketed – not that I like aggressive marketing per se but Titan deserves to be better known than it is (I like it a lot) – and as Matthias Broecheler (the lead developer of Titan) said to me recently, the guys at Aurelius are good at technology but not so hot on marketing, so we can expect DataStax to give it a shot in the arm in that respect.

Moving on to other matters, AllegroGraph has announced version 5.0 of its triple store (RDF database) with some particular additions to enhance geospatial processing using what it calls nD (N-dimensional). In fact it is introducing a general n-dimensional ordinate system that has potential application in other areas as well, such as semiconductor manufacturing and biology.

This is interesting not only for its own sake but also because the approach taken by Franz (the developers of AllegroGraph) has been likened to that used in AtomicDB. In due course I plan to write in more detail about AtomicDB but, briefly, this is an associative database targeted at data warehousing environments (and others). Note that the essential difference between a graph or RDF (resource description framework) database and associative database is that the former is organised on the basis of relationships between entities while the latter allows relationships between relationships. The upside of an associative approach is that it requires fewer entities and relationships to be defined, thereby saving on storage and, other things being equal, improving performance. The downside is that the resulting “association graphs” may be more difficult to understand, because of those relationships between relationships. Anyway, I shall explore this more at a later date.