Skip to content 
The world is a graph: How Fix reimagines cloud security using a graph in ArangoDB
Three Ways to Scale your Graph
Estimated reading time: 10 minutes
As businesses grow and their data needs increase, they often face the challenge of scaling their database systems to keep up with the increasing demand.
What happens when your single server machine is no longer sufficient to store your graph that has grown too large? Or when your instance can no longer cope with the increasing amount of user requests coming in?
Read moreGraph and Entity Resolution Against Cyber Fraud
Estimated reading time: 4 minutes
With the growing prevalence of the internet in our daily lives, the risks of malware, ransomware, and other cyber fraud are rising. The digital nature of these attacks makes it very easy for fraudsters to scale by creating thousands of accounts, so even if one is identified, they can continue their attacks.
In this blog post, we will discuss how graph and entity resolution (ER) can help us battle these risks across different industries such as healthcare, finance, and e-commerce (for example, the US healthcare system alone can save $300 billion a year with entity resolution). You will also receive hands-on experience with entity resolution on ArangoDB.
Combat Fraud with Graph
Estimated reading time: 5 minutes
Fraud is one of the most significant issues facing businesses today. While companies have always faced fraud, detecting fraudulent activity has become even more challenging due to increased online transactions. Globally, fraud results in more than $3.7 trillion in annual losses (Murphy, 2022). Fraud comes in numerous forms, including but not limited to money laundering, identity theft, account takeover, and payment fraud. Due to the variety of ways companies can face fraud, they must have a system to protect themselves and their customers.
Read moreWhy Should You Care About SOC 2?
And by the way, ArangoDB is SOC 2 compliant!
Estimated reading time: 3 minutes
While driving along California’s Highway 101 and its billboards, compliance and SOC 2 seem to be an omnipresent – yet challenging – topic. But is it really? And if so, why? In this blog post, we want to share why and how ArangoDB has become SOC 2 compliant.
Read moreArangoDB 3.7 – A Big Step Forward for Multi-Model
Estimated reading time: 7 minutes
When our founders realized that data models can be features, we at ArangoDB set ourselves the big goal of developing the most flexible database. With today’s GA release of ArangoDB 3.7, the project reached an important milestone on this journey.
(more…)Building AQL Query Strings: Tips and Best Practices | ArangoDB Blog
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:
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.
Efficient Lock-Free Data Structure Protection | ArangoDB Blog
Motivation
In multi-threaded applications running on multi-core systems, it occurs often that there are certain data structures, which are frequently read but relatively seldom changed. An example of this would be a database server that has a list of databases that changes rarely, but needs to be consulted for every single query hitting the database. In such situations one needs to guarantee fast read access as well as protection against inconsistencies, use after free and memory leaks.
Therefore we seek a lock-free protection mechanism that scales to lots of threads on modern machines and uses only C++11 standard library methods. The mechanism should be easy to use and easy to understand and prove correct. This article presents a solution to this, which is probably not new, but which we still did not find anywhere else.
The concrete challenge at hand
Assume a global data structure on the heap and a single atomic pointer P to it. If (fast) readers access this completely unprotected, then a (slow) writer can create a completely new data structure and then change the pointer to the new structure with an atomic operation. Since writing is not time critical, one can easily use a mutex to ensure that there is only a single writer at any given time. The only problem is to decide, when it is safe to destruct the old value, because the writer cannot easily know that no reader is still accessing the old values. The challenge is aggravated by the fact that without thread synchronization it is unclear, when a reader actually sees the new pointer value, in particular on a multi-core machine with a complex system of caches.
If you want to see our solution directly, scroll down to “Source code links“. We first present a classical good approach and then try to improve on it. (more…)
Securing your Foxx with API Keys
ArangoDB’s Foxx allows you to easily build an API to access your data sources. But now this API is either public or restricted to users having an account, but those still get unlimited access.
In many use cases you do not want to expose your data in this fashion, but you want to expose it with a more controllable access pattern and want to restrict the requests one user could issue in a certain time period. Popular examples for these API restrictions are Twitter or Facebook. This allows you to offer all of your data but only in limited chunks, and then possibly charge your customers to increase the chunk limit they can request.
All this is done via API keys, which are bound to a user and has become a common pattern to monetize the data you have collected. (more…)