Cambridge Semantics

AnzoGraph’s key claim to fame is its analytic performance while running on low cost cloud or on-premise commodity servers. To support its performance, the database uses various constructs. To begin with, all queries are compiled (into C++). Secondly, it uses forward chaining in its inference engine which, while consuming more memory than backward chaining, provides better performance. Thirdly, it supports both materialised and dynamic views. More fundamentally, it uses a shared nothing, massively parallel architecture.

Query processing is via an extended version of SPARQL. In addition to complete support for SPARQL 1.1, AnzoGraph supports many additional BI analytics functions, conditional expressions, Windowed Aggregates, Named Queries, Views and multi-graphs. Being a declarative language, there is an appropriate database optimiser for SPARQL and it is noteworthy that the personnel in Cambridge Semantics have a significant history in this subject. As mentioned, while you can use AnzoGraph purely as an RDF graph, you can also implement it as a labelled property graph. To enable graph traversal in this context, the company plans to introduce support for OpenCypher in due course.

Although its emphasis is squarely on analytic processing and OLAP, AnzoGraph does share a query language (SPARQL and, in future, Cypher) with many OLTP products. In fact, the product can be used for transactional processing, and even supports ACID transactions. However, it is not optimised for this, and this approach is not recommended. Instead, AnzoGraph is intended to be used in conjunction with a full-fledged OLTP product. In this scenario, a shared query language provides significant benefits and advantages. In particular, it makes it much easier for users of one product to understand the other, resulting in improved collaboration and reduced training time. RDF-based transactional graphs are particularly well supported (regardless of whether they use SPARQL). For example, you can directly import OLTP data into AnzoGraph, or export results data from AnzoGraph into your OLTP system. Further capabilities, such as the ability to synchronise Change Data Capture between your OLTP and OLAP systems, are under development.

As far as direct analytics support is concerned, various BI and analytic functions are provided out of the box, including graph algorithms such as PageRank and Shortest Path. As one would expect, inferencing is built-in, and there is support for integration to third party tools and vendors including R, SAS, Qlik, Tableau and Spotfire.

There are relatively few vendors in the graph database market that have the performance to focus specifically on analytics and, of those that do, apart from Cambridge Semantics they tend to either not be semantically oriented and/or leverage proprietary languages and/or rely on (very expensive) hardware acceleration to get their performance. The most significant of these concerns is probably the semantic orientation. If for, example, you want to do discovery analytics within a pharmaceutical environment, then you really need the sort of semantic capabilities that an RDF graph can provide. The upshot of this is that Cambridge Semantics can do things that analytically oriented property graph products cannot do, but the reverse does not apply.

In addition, although AnzoGraph specialises in analytics, and does not provide significant transactional capabilities, it takes care to make sure that it complements any transactional systems you might have or acquire. Thus, it enables a well-integrated two-pronged solution to graph processing. This is particularly true if the transactional system in question is also based on RDF, and even more so if it supports SPARQL, making AnzoGraph especially appealing in these cases.

The Bottom Line

Cambridge has achieved some significant success with Anzo though it is still early days for AnzoGraph. Nevertheless, the product has significant strengths for analytic graph processing. Historically, this has been an underserved market, but it is now becoming much more active. AnzoGraph looks to be well positioned.

AnzoGraph’s key claim to fame is its analytic performance and scalability while running on low cost cloud or on-premises commodity servers.
To support its performance, the database uses various constructs. To begin with, all queries are compiled (into C++). Secondly, it uses forward chaining in its inference engine which, while consuming more memory than backward chaining, provides better performance. Thirdly, it supports both materialised and dynamic views. More fundamentally, it uses a shared nothing, massively parallel architecture.

Apart from its support for OpenCypher query processing is via an extended version of SPARQL. AnzoGraph supports many additional BI analytics functions such as conditional expressions, windowed aggregates, named queries, views and multi-graphs. Being a declarative language, there is an appropriate database optimiser for SPARQL, and it is noteworthy that the personnel at Cambridge Semantics have a significant history in this subject.

As far as direct analytics support is concerned, various BI and analytic functions are provided out of the box, including graph algorithms such as PageRank and Shortest Path. As one would expect, inferencing is built-in, and there is support for integration to third party tools and vendors including R, SAS, Qlik, Tableau and Spotfire as well as specialist graph products such as Keylines. Notably, the company has announced a partnership with ESRI with all of that company’s geospatial library of (approximately) 150 functions available inside the AnzoGraph database. This is a fully 3D (not just 2D) implementation and supports features such as shape files, polygon handling and so forth.

Two further significant capabilities are also in beta as of the time of writing. The first of these is support for data virtualisation, which will allow you to query external data sources without any requirement to move relevant data into AnzoGraph. And the second is support for Kafka. While there are existing facilities to directly import OLTP data into AnzoGraph (and to export results data from AnzoGraph into your OLTP system) using traditional ACID functions such as inserts, this is not fast enough when transaction volumes are high, hence the move to support Kafka, which will allow transactions to be posted in micro-batches.

We do not believe that users want to agonise over whether they should choose an RDF graph or a property graph. Both have advantages and, in the longer term, we expect these markets to merge. However, that hasn’t happened yet. Nevertheless, Cambridge Semantics is in the vanguard of vendors saying that you don’t have to make that choice, that you can have both.

Another significant capability, once it is out of beta, is the geospatial support that AnzoGraph will be offering. This is significantly in advance of the (relatively few) other graph products that offer geospatial support and it will enable Cambridge Semantics to address IoT and other use cases that have not historically been well served by graph database suppliers.

And finally, from a purely technical perspective, a major reason for liking AnzoGraph is that there are relatively few vendors in the graph database market that have the performance and scalability to focus on analytics. Moreover, of those few competitors that are in this space they tend to be either not be semantically oriented and/or leverage proprietary languages and/or rely on (very expensive) hardware acceleration to get their performance.

The Bottom Line

In our last report into the graph database market we reported that “AnzoGraph looks to be well positioned” to capitalise on the growth in demand for analytic graph processing. Our view today is that the product is fulfilling that promise and it is unquestionably a leader within its market segment.