Skip to content 
Multi-Model Benchmark: Assessing ArangoDB’s Versatility
Claudius Weinberger, CEO ArangoDB
TL;DR Native multi-model databases combine different data models like documents or graphs in one tool and even allow to mix them in a single query. How can this concept compete with a pure document store like MongoDB or a graph database like Neo4j? I myself and a lot of folks in the community asked that question.
So here are some benchmark results: 100k reads → competitive; 100k writes → competitive; friends-of-friends → superior; shortest-path → superior; aggregation → superior.
Feel free to comment, join the discussion on HN and contribute – it’s all on Github.
Getting Unique Values: Efficient Data Retrieval in ArangoDB
While paging through the issues in the ArangoDB issue tracker I came across issue #987, titled “Trying to get distinct document attribute values from a large collection fails”.
The issue was opened around 10 months ago when ArangoDB 2.2 was around. We improved AQL performance somewhat since then, so I was eager to see how the query would perform in ArangoDB 2.6, especially when comparing it to 2.2.
For reproduction I quickly put together some example data to run the query on:
var db = require("org/arangodb").db;
var c = db._create("test");
for (var i = 0; i < 4 * 1000 * 1000; ++i) {
c.save({ _key: "test" + i, value: (i % 100) });
}
require("internal").wal.flush(true, true);
ArangoDB 2.6 Alpha3: Testing New Features & Performance
The 2.6 release preparations are on track: with a 3rd alpha release available for testing purposes today. Please download the latest alpha build and provide us your valuable feedback.
We put great efforts in speeding-up core ArangoDB functionality to make AQL queries perform much better than in earlier versions of ArangoDB.
The queries that improved most in 2.6 over 2.5 include:
FILTERconditions: simpleFILTERconditions we’ve tested are 3 to 5 times faster- simple joins using the primary index (
_keyattribute), hash index or skiplist index are 2 to 3.5 times faster - sorting on a string attribute is 2.5 to 3 times faster
- extracting the
_keyor other top-level attributes from documents is 4 to 5 times faster COLLECTstatements: simpleCOLLECTstatements we’ve tested are 7 to 15 times faster
More details on the performance improvements and the test-setup will be published in a follow-up blog post. For now, try out 2.6 alpha3 version – we’ve done our very best to make ArangoDB a lot faster. ; )
What’s new in ArangoDB 2.6
For a full list of changes and improvements please consult the change-log. Over the next week we might also add some more functionality to 2.6, mainly some improvements in the shortest-path implementation and other graph related AQL queries.
(more…)
MERII Hummingbird A80 Optimus Cluster: ArangoDB Deployment
For running ArangoDB in clusters doing performance tests we wanted to have a non virtualized set of descent hardware with fast ethernet connection, enough RAM (since thats what Arango needs) and multicore CPU. Since you need a bunch of them, cheap ARM devel boards come to mind. The original Raspberry PI (we have those) is out of the game due to V8 is not supporting it anymore. The now available PI 2 doesn’t cut it, since its ethernet NIC is connected via USB (as on the original PI). The Odroid series only have one of both: Fast ethernet or enough RAM. The Cubieboard 4 wasn’t available yet, but its Allwinner A80 SOC seemed a good choice. Then we met the Merii Optimus board, which seems to be almost the same as the PCDuino (now renamed to Arches) with the A80. While we got a bunch of them for a descent price over at Pollin, the upstream support wasn’t that good.
However, with some help of the SunXi-Linux Project we started flashing OS images to replace the preloaded Android image with the Merii Linux image. Since the userland of the Merii image is pretty sparse, we wanted something more useable. There is already a how-to on running Ubuntu which requires running a Windows host. We prefer a Linux host and want to run a Debian. Since the new Pi2 is also able to run regular Debian with ArmV7, we pick the root fs from sjoerd.
Create an ArangoDB cluster on Microsoft Azure
During the last weeks we’ve released our new deployment tool for cloud computing platforms with how-to’s for Google Compute Engine, Digital Ocean and Amazon Web Services support.
Today we show how to deploy an ArangoDB cluster on Azure with a single command.
Azure
To easy-deploy an ArangoDB cluster on Azure you just need to install the official azure-cli, download a single bash script and watch the tool take care of the rest for you. Your azure account needs permission for creating instances, adding ssh-keypairs and managing virtual networks.
wget https://raw.githubusercontent.com/ArangoDB/deployment/publish/Azure_ArangoDB_Cluster.sh
chmod 755 Azure_ArangoDB_Cluster.sh
Foxx Swagger Integration: Streamline API Documentation
The generated API documentation in ArangoDB 2.6 has been updated to Swagger 2. To see the API documentation for any of your Foxx apps, open the web admin frontend and select your app from the Applications tab. For information on how to describe your own APIs in the generated documentation, see the ArangoDB documentation.
But wait, there’s more! In addition to being shown in the web admin frontend, ArangoDB 2.6 allows you to mount your app’s documentation inside the app itself. Using the new controller method apiDocumentation you can define a mount point for the app’s own documentation and apply the same access controls you already use for other routes. Depending on your needs, you can even mount the documentation of other apps in your own Foxx app, use different assets or even your own Swagger API description files. In fact, the new API documentation viewer of the web admin frontend itself is using it.
For more information on the apiDocumentation method, see the documentation. If you want to give the feature a try yourself, check out ArangoDB 3.0 or compile the latest development version from the GitHub repository.
Diffing Two Documents in AQL: ArangoDB Data Comparison
I just stumbled upon a comment in the ArangoDB blog asking how to create a diff of two documents with AQL.
Though there is no built-in AQL function to diff two documents, it is easily possible to build your own like in the following query.
Read more on how to diff two documents in AQL.
ArangoDB 2.6 API Changes: Updates & Enhancements
ArangoDB 2.6 comes with new and changed APIs as well as changed behavior regarding document keys and several graph functions.
If you use Travis-CI for your tests you can download the Travis-CI ArangoDB build here: Travis-CI/ArangoDB-2.6.0-alpha2.tar.gz
The changes so far:
APIs added
- added batch document removal and lookup APIs:
These APIs can be used to perform multi-document lookup and removal operations efficiently. The arguments to these APIs are the name of the collection plus the array of document keys to fetch or remove.
The endpoints for these APIs are as follows:
PUT /_api/simple/lookup-by-keys PUT /_api/simple/remove-by-keysExample call to fetch documents:
curl -X PUT \ http://127.0.0.1:8529/\_db/\_system/_api/simple/lookup-by-keys \ --data '{"collection":"myCollection","keys":["test1","test3"]}'The documents will be returned in an attribute
documentsof the HTTP response.documentsis an array containing all documents found. Only those documents that were actually found will be returned. Documents that were searched but do not exist will not be returned and do not trigger any errors. (more…)
ArangoDB 2.6 Alpha2: Testing New Features & Performance
Our next major release ArangoDB 2.6 is on the finishing straight with an early alpha2 version for Linux released today.
UPDATE: New alpha3 release available.
We put great efforts in speeding-up core ArangoDB functionality to make AQL queries perform much better than in earlier versions of ArangoDB.
The queries that improved most in 2.6 over 2.5 include:
FILTERconditions: simpleFILTERconditions we’ve tested are 3 to 5 times faster- simple joins using the primary index (
_keyattribute), hash index or skiplist index are 2 to 3.5 times faster - sorting on a string attribute is 2.5 to 3 times faster
- extracting the
_keyor other top-level attributes from documents is 4 to 5 times faster COLLECTstatements: simpleCOLLECTstatements we’ve tested are 7 to 15 times faster