Stored Procedures

Supported

ArangoDB allows users to define their own User Defined Functions (UDFs). Users can also use the Foxx microservice framework to build their own logic into a microservice inside the database and able to access data it needs. This can achieve the same functionalities of stored procedures.

Logging

Shadow Paging

ArangoDB does not overwrite existing documents. Instead, it create a new version of modified documents for all the write operations (including delete operation). ArangoDB's Write-Ahead-Logging records all these write operations that were executed on the server.

Indexes

Hash Table

By default, the index of a document is a hash index on its _key attribute. At the same time, user can specify other indexes including skip list, fulltext index, persistent index, geo-spatial Index etc.

Data Model

Key/Value Document / XML Graph

In ArangoDB, a document collection always has a primary key _key. Therefore, without specifying any secondary index, it is just like a key-value store. Generally, there can be multiple attributes and multiple secondary indexes, then it is like a common document store. By default, the sharding key is the same as the primary key _key. Therefore it can achieve good linear scalability. Besides key-value store and document store, ArangoDB can also support graph store with comprehensive functionalities.

Query Interface

Custom API

ArangoDB has its own query language ArangoDB query language (AQL). AQL queries can be invoked using Arangosh (ArangoDB Shell), web interface, or HTTP REST API.

Storage Architecture

In-Memory

ArangoDB is a mostly-memory database. There are two storage engines available. The default one is called MMFiles which is based on memory-mapped files. The other available option is RocksDB.

Storage Organization

Copy-on-Write / Shadow Paging

Concurrency Control

Two-Phase Locking (Deadlock Detection)

The user need to specify which collections a transaction needs to read/write. ArangoDB will first collect all the locks in alphabetical order of the collection names at the beginning of each transaction, and release the locks in reverse order after the transaction finishes. In case there is a deadlock, ArangoDB will automatically abort one of the transactions, roll back the changes, and throw error 29 (deadlock detected) to the client.