Query Language Archives - ArangoDB

Sign up for ArangoGraph Insights Platform

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.

detecting complex fraud patterns with ArangoDB

Detecting Complex Fraud Patterns with ArangoDB

00General, Graphs, how to, Query LanguageTags: , ,

Introduction

This article presents a case study of using AQL queries for detecting complex money laundering and financial crime patterns. While there have been multiple publications about the advantages of graph databases for fraud detection use cases, few of them provide concrete examples of implementing detection of complex fraud patterns that would work in real-world scenarios. 

This case study is based on a third-party transaction data generator, which is designed to simulate realistic transaction graphs of any size. The generator disguises complex financial fraud patterns of two kinds: 

  • Circular money flows: a big amount of money is going through different nodes and comes back to the source node.
  • Indirect money transfers: a big amount of money is sent from source node to a target node over a multi-layered network of intermediate accounts.
More info

Best Practices for AQL Graph Queries

10General, Graphs, how to, Query Language

Estimated reading time: 8 minutes

The ArangoDB Query Language(AQL) was designed to accomplish a few important goals, including:

  • Be a human-readable query language
  • Client independency 
  • Support complex query patterns
  • Support all ArangoDB data models with one language

The goal of this guide is to ensure Read more

From Zero to Advanced Graph Query Knowledge with ArangoDB

10General, Graphs, Query LanguageTags: , ,

Thinking about your data as a highly connected set of information is a powerful way to gain insights, solve problems and bring products faster into the hands of your users.

Unlike other databases, relationships take the first priority in graph databases and with ArangoDBs multi-model approach for graphs, documents and key/value pairs you can even switch between models or combine them in a single query.

The graph concept is booming but still new to many. So we invested a few bazillion coffees and some night shifts to come up with a good plan for a Graph Course:

Read more

Killing a long-running query

01General, Query LanguageTags: ,

Suppose there is an AQL query that’s executing in the server for a long time already and you want to get rid of it. What can be done to abort that query?

If a connection to the server can still be established, the easiest is to use the ArangoShell to fetch the list of currently executing AQL queries and send a kill command to the server for the correct query. Read more

On building AQL Query Strings

00Query Language, SecurityTags:

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:

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

00Query LanguageTags:

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:

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

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

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.: