Query Language Archives - Page 3 of 3 - ArangoDB

AQL Improvements for 2.4

02Query LanguageTags:

While on a retreat in Belgium, we found some spare time to work on improvements for AQL. These will be shipped with ArangoDB version 2.4, and are already available in the devel version for testing from now on.

Here’s a short overview of the improvements:

Collect with count

A common use case in query languages is to count the number of documents returned by a query. The AQL solution for this has been to use the LENGTH function and a subquery:

This is quite long and probably unintuitive for people which have used SQL for years.

We therefore now allow using the following alternative version:

Read more on Jan’s Blog

Arangodb Java Driver and Graphs – Part 2

03Graphs, Java, Query LanguageTags: , , ,

After defining a graph and filling it with some vertices and edges (see part 1), the time has come to retrieve information out of the graph.

Please take a look at the defined graph operations of ArangoDB. These will be the base for our next examples. (Yes, there may be other ways to get the results, this post does not claim completeness!)

We will start with some easy stuff and then smoothly advance in complexity.

Question: “How many edges are defined within the graph?”

More info

A Tour Around the New AQL Query Optimizer

00Query LanguageTags:

The major new feature in ArangoDB 2.3 is the shiny new AQL query optimizer and executor. These parts of ArangoDB have been rewritten in 2.3 to make AQL much better for our end users.

Since one of the initial releases, ArangoDB has been shipped with AQL, the ArangoDB Query Language. AQL has since then been ArangoDB’s most versatile way of executing simple and also the not-so-simple queries.

I’ll start with an overview of query execution in previous versions of ArangoDB, and then explain the new engine and explain the differences.

Read more on Jan’s Blog

Modeling Data in MongoDB vs ArangoDB

05Architecture, Documentation, Graphs, Query LanguageTags: ,

MongoDB is a document DB whereas ArangoDB is a multi-model DB supporting documents, graphs and key/values within a single database. When it comes to data modeling and data querying, they pursue somewhat different approaches.


In a Nutshell: In MongoDB, data modeling is “aggregate-oriented”, avoiding relations and joins. On the other side, everybody has probably used relational databases which organize the data in tables with relations and try to avoid as much redundancy as possible. Both approaches have their pros and cons. ArangoDB is somewhat in-between: You can both model and query your data in a “relational way” but also in an “aggregate-oriented way”, depending on your use case. ArangoDB offers joins, nesting of sub-documents and multi-collection graphs. More info

First Beta of ArangoDB 2.3 is out

05General, Query Language, ReleasesTags:

This version is deprecated. Download the new version of ArangoDB

We are proud to present ArangoDB 2.3. The first beta version is now available for download from our web-site or you can use “brew install –unstable arangodb” under Mac OS X. You can also look into the nightly documentation for more information.

Please note that the main feature of this release contains a complete rewrite of the query engine, allowing much more optimizations than before – especially in the cluster case. It would be very helpful for us, if you could test this query engine as much as possible. If you find any unexpected behavior, please let us know.

The data-files can be upgraded from 2.x to 2.3. You should, however, backup the database directory beforehand, as this is a beta-release.

Features and improvements

The following list shows in detail which features have been added or improved in ArangoDB 2.3. ArangoDB 2.3 also contains several bug-fixes that are not listed here.

More info

AQL: Querying a nosql database the elegant & comfortable way

07Query LanguageTags:

Having a long history with relational databases and having worked for a lot of years with SQL some people find it a bit inconvenient querying nosql databases e.g. via REST. Others have rather complex data models and need nevertheless an elegant and convenient way for querying. And we all love clean and simple interfaces.

ArangoDB comes with a couple of options for querying the data, among offer it implements the “ArangoDB Query Language” (AQL).

AQL is a declarative query language for simple and also very complex queries. Unless like in other nosql databases you can also query across collections, aggregate results, do some geo location stuff and even iterate over graphs.

So if you like the comfort of SQL but also the freedom of a schema free database, AQL is for you.

If you are interested in learning more about the concepts of ArangoDB checkout Jan’s talk and slides.

But let’s stop beating around the bush and rather have a look at specific examples.

More info

RFC – The ArangoDB/AvocadoDB query language

02Query LanguageTags: ,
Note: We changed the name of the database in May 2012. AvocadoDB is now called ArangoDB.

The REST API for AvocadoDB is already available and stable and people are writing APIs using it. Awesome. As AvocacoDB offers more complex data structures like graphs and lists REST is not enough. We implemented a first version of a query language some time ago which is very similar to SQL and UNQL.
More info

Is UNQL Dead?

04Architecture, Query LanguageTags: ,
Note: We changed the name of the database in May 2012. AvocadoDB is now called ArangoDB.

UNQL started with quite some hype last year. However, after some burst of activity the project came to a hold. So it seems, that – at least as a project – UNQL has been a failure. IMHO one of the major issues with the current UNQL is, that it tries to cover everything in NoSQL, from key-value stores to document-stores to graph-database. Basically you end up with greatest common divisor – namely key-value access. But with graph structures and also document-structures you really want to supports joins, paths or some sort of sub-structures.

Apart from all the technical and theoretical benefits of SQL and what advantages the underlying theory has to offer, the major plus from an users point of view is that it is readable. You simple can see an SQL statement – be it in C, Java, Ruby – and understand what is going on. It is declarative, not imperative. With other imperative solution, like a fluent interface or a map-reduce, you need to understand the underlying syntax or language. With SQL you only need to understand English – at least most of the time.

And here I think is where UNQL is totally right. We need something similar for the NoSQL world. But it should not try to be a “fits all situation”. It should be a fit for 80% of the problems. For simple key-values stores a fluent-interface is indeed enough. For very complex graph traversals a traversal program must be written. For very complex map-reduces you might need to write a program – but check out Google’s talk (www.nosql-matters.org/program) about NoNoSQL. There they describe why they are developing a SQL-like interface for Map/Reduce.

In my experience most of the time you have a set of collections holding different “types” of documents with some relations between them. One of the biggest advantages of document stores or graph databases is that you can have lists and sub-objects. The problem with SQL is, that it has no good way to deal with these structures. So I believe UNQL would be quite successful if it would concentrate on these strong advantages of NoSQL, instead of trying to unify everything – especially after hear Jan’s talk about a document query language at the NoSQL Cologne UG (an English version is also available).

Do you like ArangoDB?
icon-githubStar this project on GitHub.
close-link