ArangoDB

Figure 2 – ArangoDB Multi-model approach

ArangoDB is a native multi-model database. That is, it was designed from the outset to support documents, key-values and graphs. The product is written in C++ and the storage layer has been ported onto the RocksDB database). This too is written in C++ and should provide improved performance along with a smaller footprint (making it potentially appropriate for Internet of Things environments). AQL, an example of which is provided in Figure 2, is similar to SQL. It is especially notable as it allows you to access any stored datatype within a single query. The database also supports many language bindings, including Java, GO, Python, Node.js, .NET, Scala and many others.

Figure 3 – ArangoDB distributed architecture

Also unusual are the support for the Foxx framework and Apache Mesos and Kubernetes. The first of these – illustrated in Figure 3 – is a Google V8 engine-based JS framework enabling the creation of JavaScript-based micro-services, while Mesos is an open-source cluster management solution and the company is also a partner of Mesosphere, which provides container orchestration based on Mesos and which helps to support very large datasets. The support for Kubernetes is via a specialised operator that dramatically simplifies deployments of large clusters. The company is also investigating the possibility of supporting other orchestration technologies, such as Docker Swarm. ArangoDB also supports the GraphQL API, which is gaining increased traction in this space, and there is an ArangoSearch capability, which does what its name suggests.

The SmartGraphs mentioned above mean that ArangoDB is one of the very few databases capable of sharding a graph to a cluster and handling graph-traversals in a performant manner, while Satellite Collections support fast joins across sharded collections.

There are a lot of applications where you would like to combine different types of data that would otherwise require multiple databases. For example, combining graphs with documents. For a while it looked like polyglot persistence (multiple databases) might be the best way to do this. However, it is now clear that a multi-model approach is easier to manage and less expensive. Nevertheless, most such implementations suffer from the lack of a single method for accessing data, which is a significant drawback. Microsoft CosmosDB, for example, requires you to use a different language for each type of data accessed. And then you have to join the results together. While there is a learning curve involved with adopting AQL, users report that it is relatively short. Conversely, the benefits in developer productivity are huge, though it would be remiss of us not to comment that the use of AQL means that it is difficult for ArangoDB to attract partners that specialise in graph visualisation.

The Bottom Line

ArangoDB has come a long way since we last formally reviewed the product a couple of years ago. There is significantly more awareness of the product in the market. In our opinion, deservedly so. Graphs should not be a siloed adjunct to other environments but should be integral to them. ArangoDB enables this in a way that is ahead of what other vendors can offer.