Pretty much all graph databases support analytics. However, the type of analytics supported varies widely. Some are better suited to operational analytics while others are more oriented towards batch processing in what we might think of as a data warehouse. In addition to this level of differentiation we can also (thanks to Donald Rumsfeld) identify three types of analytic problems at which different graph products are targeted:
Here we know about entities and their relationships but we want to explore that information further. A good example of the former are the recommendation analytics already quoted: the relationships between customers and products is known, now we need to analyse how to use this information. Another example would be influencer analytics. The graphing algorithms previously referred to typically fall into this category.
Here we don’t know either the entities we are interested in or their relationships. This is a classic “data lake” issue where you want to explore for potential relationships between entities and you’re not even really sure which entities you are interested in. In other words, very much a discovery process. Examples of use cases here include research of various kinds (finding relationships between published research papers or across legal documents), the investigation of potential terrorist plots and the discovery of cyber threats, amongst others. Analytics in this category is often within the realm of what is otherwise known as cognitive computing.
There is a growing OEM market for graph and RDF databases with IT vendors embedding graph products in order to both support and visualise complex relationships. In addition to use by companies engaged in semantics there are also a significant number of vendors in and around data governance (including MDM, matching engines, and data profiling as well as data governance per se) that have embedded graph products. The same true is for self-service data preparation platforms and metadata management.
We have already considered the relative performance advantages of using graph technology as opposed to traditional query methods. However, there are specific performance considerations that relate to different graph products.
Different vendors have adopted different approaches to handling this problem. Most common is to provide traditional methods such as MPP (massively parallel processing) and/or substantial in-memory capabilities. However, two alternate approaches are worth discussing.
Semantic inferencing, as provided by RDF databases, can be very useful within analytic environments. For example, in the
However, there are potential issues with inferencing. There are, in fact, two major types of reasoning that may be provided: forward chaining and backward chaining. The former starts with the data and then calculates a result while the latter states a desired result and the software works backward to the necessary data. Both methods have issues: forward chaining materialises inferences which impairs performance for updates and deletes. There may also be an issue with respect to what is known as “retraction”, which is the process of removing materialisations that are no longer required. In addition, user access control can also be more complex to implement when using forward chaining. Conversely, backward chaining can either (depending on the method used) lead to query processing that is difficult to optimise or to a proliferation of sub-queries, either of which can seriously impair query performance. On the other hand, because inferences are not materialised, any costs are only associated with a particular query as opposed to being across the entire environment. You will want to ensure that the vendor you select to provide your database has put appropriate measures in place to at least ameliorate these issues.
Depending on the product you can use a huge range of traditional programming languages such as Java, C, C++, Python and so forth, alongside your graph database. In addition, a number of the semantically oriented graph products support OWL (web ontology language). However, the most popular and/or important access methods are specific to graphs and these are typically declarative.
Depending on the product you can use a huge range of traditional programming languages such as Java, C, C++, Python and so forth, alongside your graph database.
There are two other declarative languages that we are aware of. One is KEL (Knowledge Engineering Language), which is a proprietary language that runs against an open source database, and the other is Cypher, which is an open source language that is only licensed for use with a proprietary but open source graph database. Both vendors provide a database optimiser that has had some significant development put behind it. There is also at least one vendor that has extended SQL rather than implementing a new declarative language.
With respect to SQL, it is possible to front-end graph queries with SQL even if you are not actually doing any processing using SQL (it is translated under the covers). The big advantage of this (as well as direct SQL implementations) is that you can use traditional (relational)
Alongside the various open source graph projects from Apache there is also TinkerPop. This was originally created by a developer group building an open source stack targeted at property graphs. However, TinkerPop has now been donated to Apache and it has become one of that organisation's projects. While the latest instantiation of TinkerPop (TinkerPop 3) consists of a single holistic environment it was previously comprised of several sub-projects and it is worth detailing these because it will give a better understanding of what is involved. So, previously, there were six “products”, of which the foundation module was Blueprints. This is an API that is analogous to JDBC but for property graphs. Running in conjunction with this are Pipes, which is a dataflow framework; Frames, which exposes elements of a Blueprints graph as Java objects; Furnace, which is a graph algorithms package; Rexter, which is a graph server which includes a REST API; and Gremlin, which is a graph traversal language.
