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.

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.

I just came across a question about how to create highscore lists or leaderboards in ArangoDB, and how they would work when compared to Redis sorted sets.

This blog post tries to give an answer on the topic and also detailed instructions and queries for setting up highscore lists with ArangoDB.

Inspired by the feature request in Github issue #1298, we added update and replace support for ArangoDB’s import facilities.

This extends ArangoDB’s HTTP REST API for importing documents plus the arangoimp binary so they can not only insert new documents but also update existing ones.

Inserts and updates can also be mixed in a single import run. This blog post provides a few usage examples.

I recently wrote about the performance improvements for the cursor API made in ArangoDB 2.6. The performance improvements are due to a rewrite of the cursor API’s internals.

As a byproduct of this rewrite, an extra API was created for exporting all documents from a collection to a client application. With this being its only use case, it is clear that the new API will not solve every data export problem. However, the API’s limitedness facilitated a very efficient implementation, resulting in nice speedups and lower memory usage when compared to the alternative way of exporting all documents into a client application.

This week we pushed some modifications for ArangoDB’s cursor API into the devel branch. The change will result in less copying of AQL query results between the AQL and the HTTP layers. As a positive side effect, this will reduce the amount of garbage collection the built-in V8 has to do.

These modifications should improve the cursor API performance significantly for many cases, while at the same time keeping its REST API stable.

This blog post shows some first unscientific performance tests comparing the old cursor API with its new, improved implementation.

Data-modification queries were enhanced in ArangoDB 2.4 to be able to also return the inserted, update or removed documents.

For example, the following statement inserted a few documents and also returned them with all their attributes:

1
2
3
4

FOR i IN 1..10
  INSERT { value: i } IN test
  LET inserted = NEW
  RETURN inserted

The syntax for returning documents from data-modification queries only supported the exact above format. Using a LET clause was required, and the RETURN clause was limited to returning the variable introduced by the LET.

These syntax restrictions have been lifted in the devel branch, which will become release 2.6 eventually. The changes make returning values from data-modification statements easier and also more flexible.

This week saw the completion of the AQL UPSERT command.

This command will be very helpful in a lot of use cases, including the following:

• ensure that a document exists
• update a document if it exists, otherwise create it
• replace a document if it exists, otherwise create it

The UPSERT command is executed on the server side and so delivers client applications from issuing a fetch command followed by a separate, conditional UPDATE or INSERT command.

I often find myself searching for certain commits using git log and friends. While I really love the power and flexibility that come with the git and other Unix command-line tools, sometimes it can be more convenient to use a database to filter and aggregate commit data.

I gave it a quick try yesterday and imported the commit history of ArangoDB’s Git repository into ArangoDB and ran some queries on the data. While the query results for our repository may not be interesting for everyone, I think it is still worth sharing what I did. Even though I didn’t try it, I think the overall procedure is applicable with any other Git repository.

ArangoDB 2.5 comes with an upgraded version of V8, Google’s open source JavaScript engine.

The built-in version of V8 has been upgraded from 3.29.54 to 3.31.74.1.

In addition to several already usable ES6 features (detailed in this blog, the following ES6 features are activated in ArangoDB 2.5 by default:

• iterators and generators
• template strings
• enhanced object literals
• enhanced numeric literals
• block scoping with let and constant variables using const
• additional String methods (such as startsWith, repeat etc.)

The above features are available in ArangoDB 2.5, and can now be used for scripting purposes in the ArangoShell and in server-side Foxx actions inside the database.

This blog post briefly explains the features provides some quick examples for using them.