Skip to content 
The Great AQL Shootout: ArangoDB 2.5 vs 2.6 Comparison
For the ArangoDB 2.6 release from last week we’ve put some performance tests together. The tests will compare the AQL query execution times in 2.5 and 2.6.
The results look quite promising: 2.6 outperformed 2.5 for all tested queries, mostly by factors of 2 to 5. A few dedicated AQL features in the tests got boosted even more, resulting in query execution time reductions of 90 % and more. Finally, the tests also revealed a dedicated case for which 2.6 provides a several hundredfold speedup.
Also good news is that not a single of the test queries ran slower in 2.6 than in 2.5.
ArangoDB 2.6.1: Maintenance Release for Improved Stability
The first maintenance release for ArangoDB 2.6 is available for download. This maintenance release is only relevant for Mac, Windows and the Raspberry.
Version 2.6.1 (2015-06-24)
- Add missing swagger files to cmake build. fixes #1368
- fixed documentation errors
Dockerizing a Bloom-Based Nonces Service in 10 Minutes
In this article I want to explain how to setup a nonce-microservice using docker.
Nonce are one-time tokens that are used to ensure that an action can only be taken once. In a project, we needed to ensure that a pay button is only pressed once. Note that nonces are not used to sign requests or identify a user. This is a separate mechanism.
ArangoDB contains a nonce implementation which is a variation of Bloom-filters. It allows to store nearly unlimited nonces within a limited amount of memory. Nonce are allowed to age, that is after an hour they might expire. If there is sufficient interest, I will explain the algorithm implemented in a separate blog post.
Improving Databases: Open Source Competitive Benchmark
TL;DR: Our initial benchmark has raised a lot of interest. Initially we wanted to show that multi-model can compete with other solutions. Due to the open and competitive way we have conducted the benchmark, the discussions around it have lead to improvements in all products, better algorithms, faster drivers and better ways to use the databases.
General Setup
From the outset we published all code and data and asked the vendors of all tested products as well as the general public, not only to run the tests on their own machines, but also to suggest improvements in the data models, test code, database configuration, driver usage and server configuration. This lead to a lively discussion, lots of pull requests and even to the release of improved versions of the database products themselves!
This process exceeded all our expectations and is yet another great example of community collaboration not only for fact finding but also for product improvements. Obviously, the same benchmark code will always show slightly different results when run on different hardware, operating systems, network setups and with more or less RAM. Therefore, a reliable result of a benchmark can essentially only be achieved by allowing everybody to run it on their own machines.
The technical setup is described in the above blog post. Let me briefly repeat the key facts.
Meet Patrick: ArangoDB User & Community Contributor
In April 2015, Thomas Pfeiffer, a user experience researcher and active open-source contributor, did an interview with one very active member of the ArangoDB community – J Patrick Davenport from Palatka, FL, USA. The aim was to get an idea about the open-source project ArangoDB as a whole and the development process so far – from the perspective of a developer. This interview first appeared in Thomas Pfeiffer sessellift blog on April 27th.
Thomas: Hi Patrick, to start off, could you tell me a little about yourself (your background, the job in which you’re using ArangoDB, …)?
Patrick: About me: I’m a Solutions Architect, working for my own company, DeusDat Solutions. I’ve been working over 8 years as a software Bob Villa (This Old House, American Reference). My clients call me in to renovate code bases that are near collapse. I’ve improved multiple Fortune 500 company’s core business applications. Recently I designed half to the Medicare Fraud Detection System for the US Government. That was based on Hadoop.
ArangoDB 2.6 New Release: Enhanced Features & Performance
We are proud to announce the latest release of ArangoDB with lot’s of improvements and many new features. ArangoDB 2.6 is available for download for many different operating systems. In the new release the focus is on performance improvements. For instance sorting on a string attribute is up to 3 times faster. There are also improvements in the shortest-path implementation and other graph related AQL queries.
Look at some of our previous blogposts like: Reusable Foxx Apps with Configurations, Document your Foxx Apps with Swagger 2 or the Improved System User Authentication to learn more about ArangoDB 2.6 and check the manual for a deeper dive into specific features.
Claudius, CEO: “The performance improvements in every area of ArangoDB 2.6 make ArangoDB an effective alternative to other databases. I am very proud of the product and the team, and we can expect much more in the next few months.”
AQL Improvements for ArangoDB 2.7: Enhanced Query Capabilities
With ArangoDB 2.6 being in beta already, it’s time to look at some features scheduled for 2.7. Today I’ll showcase a few AQL parser improvements that are present in the devel branch already, which will be the foundation for the 2.7 release.
Star operator
The already existing star operator ([*]) is much more flexible in 2.7 than in previous ArangoDB versions. It now allows filtering the values it iterates over, and optional projections.
These features will be demonstrated using the following example member data:
[
{ "name" : "sir alfred", "age" : 60, "likes" : [ "lettuce", "tortoises" ] },
{ "name" : "mozquito", "age" : 15, "likes" : [ "skateboards", "music" ] },
{ "name" : "murphy", "age" : 28, "likes" : [ "juice", "tarts", "cakes" ] },
{ "name" : "helga", "age" : 52, "likes" : [ "home", "garden", "tortoises", "cakes" ] }
]
Speeding Up Array Operations: ArangoDB Performance Tips
Last week some further optimization slipped into 2.6. The optimization can provide significant speedups in AQL queries using huge array/object bind parameters and passing them into V8-based functions.
It started with an ArangoDB user reporting a specific query to run unexpectedly slow. The part of the query that caused the problem was simple and looked like this:
FOR doc IN collection
FILTER doc.attribute == @value
RETURN TRANSLATE(doc.from, translations, 0)
In the original query, translations was a big, constant object literal. Think of something like the following, but with a lot more values:
{
"p1" : 1,
"p2" : 2,
"p3" : 40,
"p4" : 9,
"p5" : 12
}
The translations were used for replacing an attribute value in existing documents with a lookup table computed outside the AQL query.
The number of values in the translations object was varying from query to query, with no upper bound on the number of values. It was possible that the query was running with 50,000 lookup values in the translations object.
Get the latest tutorials, blog posts and news:
Thanks for subscribing! Please check your email for further instructions.