AQL Archives - Page 2 of 5

Index Speedups in 2.8

November 27, 201501PerformanceTags: AQL, Performance, Release

The upcoming 2.8 version of ArangoDB will provide several improvements in the area of index usage and query optimization.

First of all, hash and skiplist indexes can now index individual array values. A dedicated post on this will follow shortly. Second, the query optimizer can make use multiple indexes per collection for queries with OR-combined filter conditions. This again is a subject for another post. Third, there have been some speed improvements due to changes in the general index handling code. This is what this post is about. Read more

Using Bind Parameters in the AQL Editor

November 20, 201500API, GeneralTags: AQL

The AQL editor in the web interface is useful for running ad hoc AQL queries and trying things out. It provides a feature to explain the query and inspect its execution plan. This can be used to check if the query uses indexes, and which.

So far the AQL editor only supported using query string literals, but it lacked support for bind parameters. Queries issued by application code however often will use bind parameters for security reasons. Often enough this prevented copying & pasting queries from the application code into the AQL editor and vice versa without making manual adjustments. Read more

GA of ArangoDB 2.7 – Big + for Indexes, Throughput, AQL and Foxx

October 12, 201500GeneralTags: AQL, Foxx

Long awaited and now we´ve finished it! New major release of ArangoDB 2.7 is ready for download. First of all a big thanks to our community for your great support! We´ve implemented a lot of your ideas! After your feedback to RC1 and RC2 we are happy to bring a new major release to the world. With ArangoDB 2.7 we increased our performance even further and improved query handling a lot. Read more

On building AQL Query Strings

August 31, 201500Query Language, SecurityTags: AQL

I recently wrote two recipes about generating AQL query strings. They are contained in the ArangoDB cookbook by now:

After that, Github user tracker1 suggested in Github issue 1457 to take the ES6 template string variant even further, using a generator function for string building, and also using promises and ES7 async/await.

We can’t use ES7 async/await in ArangoDB at the moment due to lacking support in V8, but the suggested template string generator function seemed to be an obvious improvement that deserved inclusion in ArangoDB.

Basically, the suggestion is to use regular JavaScript variables/expressions in the template string and have them substituted safely.

With regular AQL bind parameters, a query looks like this:

1

2

3

4

5

6

var bindVars = { name: "test" };

var query = `FOR doc IN collection

FILTER doc.name == @name

RETURN doc._key`;

db._query(query, bindVars);

This is immune to parameter injection, because the query string and the bind parameter value are passed in separately. But it’s not very ES6-y.

More info

AQL object literal simplification

July 28, 201500Query LanguageTags: AQL

ArangoDB’s devel branch recently saw a change that makes writing some AQL queries a bit simpler.

The change introduces an optional shorthand notation for object attributes in the style of ES6’s enhanced object literal notation.

For example, consider the following query that groups values by age attribute and counts the number of documents per distinct age value:

1

2

3

4

FOR doc IN collection

COLLECT age = doc.age WITH COUNT INTO length

RETURN { age: age, length: length }

The object declaration in the last line of the query is somewhat redundant because one has to type identical attribute names and values:

1 2	RETURN { age: age, length: length }

In this case, the new shorthand notation simplifies the RETURN to:

1 2	RETURN { age, length }

In general, the shorthand notation can be used for all object literals when there is an attribute name that refers to a query variable of the same name.

It can also be mixed with the longer notation, e.g.:

1 2	RETURN { age, length, dateCreated: DATE_NOW() }

Introducing RETURN DISTINCT for AQL queries

July 27, 201500Query LanguageTags: AQL

Last week saw the addition of the RETURN DISTINCT for AQL queries. This is a new shortcut syntax for making result sets unique.

For this purpose it can be used as an easier-to-memorize alternative for the already existing COLLECT statement. COLLECT is very flexible and can be used for multiple purposes, but it is syntactic overkill for making a result-set unique.

New to multi-model and graphs? Check out our free ArangoDB Graph Course.

The new RETURN DISTINCT syntax makes queries easier to write and understand.

Here’s a non-scientific proof for this claim:

Compare the following queries, which both return each distinct age attribute value from the collection:

1

2

3

4

FOR doc IN collection

COLLECT age = doc.age

RETURN age

With RETURN DISTINCT:

1

2

3

FOR doc IN collection

RETURN DISTINCT doc.age

Clearly, the query using RETURN DISTINCT is more intuitive, especially for AQL beginners. Apart from that, using RETURN DISTINCT will save a bit of typing compared to the longer COLLECT-based query.

Internally both COLLECT and RETURN DISTINCT will work by creating an AggregateNode. The optimizer will try the sorted and the hashed variants for both, so they should perform about the same.

However, the result of a RETURN DISTINCT does not have any guaranteed order, so the optimizer will not insert a post-SORT for it. It may do so for a regular COLLECT.

As mentioned before, COLLECT is more flexible than RETURN DISTINCT. Notably, COLLECT is superior to RETURN DISTINCT when the result set should be made unique using more than one criterion, e.g.

1

2

3

4

FOR doc IN collection

COLLECT status = doc.status, age = doc.age,

RETURN { status, age }

This is currently not achievable via RETURN DISTINCT, as it only works with a single criterion.

The great AQL shootout: ArangoDB 2.5 vs 2.6

June 30, 201500PerformanceTags: AQL, Performance, testing

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.

More info

AQL Improvements for 2.7

June 18, 201502GeneralTags: AQL

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:

1

2

3

4

5

6

7

[

{ "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" ] }

]

More info