AQL Archives - Page 3 of 5 - ArangoDB

Sign up for ArangoDB Cloud

Before signing up, please accept our terms & conditions and privacy policy.

What to expect after you signup
You can try out ArangoDB Cloud FREE for 14 days. No credit card required and you are not obligated to keep using ArangoDB Cloud.

At the end of your free trial, enter your credit card details to continue using ArangoDB Cloud.

If you decide that ArangoDB Cloud is not (yet) for you, you can simply leave and come back later.

Introducing RETURN DISTINCT for AQL queries

00Query LanguageTags:

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:

With RETURN DISTINCT:

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.

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

00PerformanceTags: , ,

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

02GeneralTags:

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:

More info

Return Value Optimization for AQL

00PerformanceTags:

While in search for further AQL query optimizations last week, we found that intermediate AQL query results were copied one time too often in some cases.

Precisely, the data that a query’s ReturnNode will return to the caller was copied into the ReturnNode’s own register. With ReturnNode’s never modifying their input data, this demanded for something that is called return-value optimization in compilers.

2.6 will now optimize away these copies in many cases, and my blog post Return Value Optimization for AQL shows performance benefits of 10-25% that can be expected due to the optimization.

AQL Functions Improvements

07GeneralTags:

Waiting for a git pull to complete over an 8 KiB/s internet connection is boring. So I thought I’d rather use the idle time and quickly write about some performance improvements for certain AQL functions that were recently completed and that will become available with ArangoDB 2.6.

The improvements affect the following AQL functions:

  • UNSET(): remove specified attributes from an object/document
  • KEEP(): keep only specified attributes of an object/document
  • MERGE(): merge the attributes of multiple objects/documents

This blog post shows a few example queries that will benefit from 50 to more than 60 % reductions in query execution times due to the changes done to these functions.

More info

COLLECTing With a Hash Table

07Performance, Query LanguageTags:

ArangoDB 2.6 will feature an alternative hash implementation of the AQL COLLECT operation. The new implementation can speed up some AQL queries that can not exploit indexes on the COLLECT group criteria.

This blog post provides a preview of the feature and shows some nice performance improvements. It also explains the COLLECT-related optimizer parts and how the optimizer will decide whether to use the new or the traditional implementation.

More info

AQB Updated: Write More Readable Queries

00JavascriptTags:

The latest update to the AQL Query Builder for JavaScript addresses a major pain point: the “prefix notation” or LISP style syntax of AQL operator methods. Instead of calling the operator methods on the query builder object itself, you can now directly call them as methods on value objects.

Let’s say you want to write a query that takes all non-admin users with a power level over 9000 and returns their score rounded to the closest 100. In plain AQL this could be written like this:

More info

Learn More About Graph Databases

Read our latest Graph and Beyond  white paper to gain insights into how ArangoDB graph databases can support many use cases.
DOWNLOAD NOW!
close-link
Click Me