A collection identifier identifies a collection in a database. It is a string value and is unique within the database. Up to including ArangoDB 1.1, the collection identifier has been a client’s primary means to access collections. Starting with ArangoDB 1.2, clients should instead use a collection’s unique name to access a collection instead of its identifier.
ArangoDB currently uses 64bit unsigned integer values to maintain collection ids internally. When returning collection ids to clients, ArangoDB will put them into a string to ensure the collection id is not clipped by clients that do not support big integers. Clients should treat the collection ids returned by ArangoDB asopaque strings when they store or use it locally.
A collection name identifies a collection in a database. It is a string and is unique within the database. Unlike the collection identifier it is supplied by the creator of the collection. The collection name must consist of letters, digits, and the _ (underscore) and - (dash) characters only. Please refer to for more information on valid collection names.
ArangoDB can handle multiple databases in the same server instance. Databases can be used to logically group and separate data. An ArangoDB database consists of collections and dedicated database-specific worker processes.
A database contains its own collections (which cannot be accessed from other databases), Foxx applications, and replication loggers and appliers. Each ArangoDB database contains its own system collections (e.g. _users, _replication, …).
There will always be at least one database in ArangoDB. This is the default database, named _system. This database cannot be dropped, and provides special operations for creating, dropping, and enumerating databases. Users can create additional databases and give them unique names to access them later. Database management operations cannot be initiated from out of user-defined databases.
When ArangoDB is accessed via its HTTP REST API, the database name is read from the first part of the request URI path (e.g. /_db/_system/…). If the request URI does not contain a database name, the database name is automatically derived from the endpoint. Please refer to DatabaseEndpoint for more information.
A single ArangoDB instance can handle multiple databases in parallel. When multiple databases are used, each database must be given a unique name. This name is used to uniquely identify a database. The default database in ArangoDB is named _system.
The database name is a string consisting of only letters, digits and the _ (underscore) and - (dash) characters. User-defined database names must always start with a letter. Database names is case-sensitive.
A single ArangoDB instance can handle multiple databases in parallel. By default, there will be at least one database, which is named _system.
Databases are physically stored in separate sub-directories underneath the database directory, which itself resides in the instance’s data directory.
Each database has its own sub-directory, named database-. The database directory contains sub-directories for the collections of the database, and a file named parameter.json. This file contains the database id and name.
In an example ArangoDB instance which has two databases, the filesystem layout could look like this:
Foxx applications are also organized in database-specific directories inside the application path. The filesystem layout could look like this:
Documents in ArangoDB are JSON objects. These objects can be nested (to any depth) and may contain arrays. Each document is uniquely identified by its document handle.
The document revision ( value) enclosed in double quotes. The revision is returned by several HTTP API methods in the Etag HTTP header.
A document handle uniquely identifies a document in the database. It is a string and consists of the collection’s name and the document key (
_key attribute) separated by /. The document handle is stored in a document’s
By default, ArangoDB will auto-generate a document key if no
_keyattribute is specified, and use the user-specified
This behavior can be changed on a per-collection level by creatingcollections with the
keyOptions it is possible to disallow user-specified keys completely, or to force a specific regime for auto-generating the
There are some restrictions for user-definedkeys (see ).
Every document in ArangoDB has a revision, stored in the system attribute. It is fully managed by the server and read-only for the user.
Its value should be treated as opaque, no guarantees regarding its formatand properties are given except that it will be different after adocument update. More specifically,
_rev values are unique across alldocuments and all collections in a single server setup. In a cluster setup,within one shard it is guaranteed that two different document revisionshave a different
_rev string, even if they are written in the samemillisecond.
rev attribute can be used as a pre-condition for queries, to avoid_lost update situations. That is, if a client fetches a document from the server,modifies it locally (but with the
_rev attribute untouched) and sends it backto the server to update the document, but meanwhile the document was changed byanother operation, then the revisions do not match anymore and the operationis cancelled by the server. Without this mechanism, the client wouldaccidentally overwrite changes made to the document without knowing about it.
When an existing document is updated or replaced, ArangoDB will write a newversion of this document to the write-ahead logfile (regardless of thestorage engine). When the new version of the document has been written, theold version(s) will still be present, at least on disk. The same is true whenan existing document (version) gets removed: the old version of the documentplus the removal operation will be on disk for some time.
On disk it is therefore possible that multiple revisions of the same document(as identified by the same
_key value) exist at the same time. However,stale revisions are not accessible. Once a document was updated or removedsuccessfully, no query or other data retrieval operation done by the userwill be able to see it any more. Furthermore, after some time, old revisionswill be removed internally. This is to avoid ever-growing disk usage.
From a user perspective, there is just one single document revisionpresent per different
_key at every point in time. There is no built-insystem to automatically keep a history of all changes done to a documentand old versions of a document can not be restored via the
Edges are special documents used for connecting other documents into a graph. An edge describes the connection between two documents using the internal attributes:
_to. These contain document handles, namely the start-point and the end-point of the edge.
Edge collections are collections that store edges.
Edge definitions are parts of the definition of . They describe which edge collections connect which vertex collections.
Module maintaining graph setup in the
_graphs collection - aka
named graphs. Configures which edge collections relate to which vertex collections. Ensures graph consistency in modification queries.
Named graphs enforce consistency between edge collections and vertex collections, so if you remove a vertex, edges pointing to it will be removed too.
Indexes are used to allow fast access to documents in a collection. All collections have a primary index, which is the document’s _key attribute. This index cannot be dropped or changed.
Edge collections will also have an automatically created edges index, which cannot be modified. This index provides quick access to documents via the
Indexing the system attribute
_id in user-defined indexes is not supported by any index type.
An edges index is automatically created for edge collections. It contains connections between vertex documents and is invoked when the connecting edges of a vertex are queried. There is no way to explicitly create or delete edges indexes.
A fulltext index can be used to find words, or prefixes of words inside documents. A fulltext index can be defined on one attribute only, and will include all words contained in documents that have a textual value in the index attribute. Since ArangoDB 2.6 the index will also include words from the index attribute if the index attribute is an array of strings, or an object with string value members.
For example, given a fulltext index on the
translations attribute and the following documents, then searching for
лиса using the fulltext index would return only the first document. Searching for the index for the exact string
Fox would return the first two documents, and searching for
prefix:Fox would return all three documents:
If the index attribute is neither a string, an object or an array, its contents will not be indexed. When indexing the contents of an array attribute, an array member will only be included in the index if it is a string. When indexing the contents of an object attribute, an object member value will only be included in the index if it is a string. Other data types are ignored and not indexed.
Only words with a (specifiable) minimum length are indexed. Word tokenization is done using the word boundary analysis provided by libicu, which is taking into account the selected language provided at server start. Words are indexed in their lower-cased form. The index supports complete match queries (full words) and prefix queries.
A geo index is used to find places on the surface of the earth fast.
An index handle uniquely identifies an index in the database. It is a string and consists of a collection name and an index identifier separated by /.
A hash index is used to find documents based on examples. A hash index can be created for one or multiple document attributes.
A hash index will only be used by queries if all indexed attributes are present in the example or search query, and if all attributes are compared using the equality (== operator). That means the hash index does not support range queries.
A unique hash index has an amortized complexity of O(1) for lookup, insert, update, and remove operations.The non-unique hash index is similar, but amortized lookup performance is O(n), with n being the number ofindex entries with the same lookup value.
A skiplist is a sorted index type that can be used to find ranges of documents.
You may use edge collections with vertex collections without the graph management facilities. However, graph consistency is not enforced by these. If you remove vertices, you have to ensure by yourselves edges pointing to this vertex are removed. Anonymous graphs may not be browsed using graph viewer in the webinterface. This may be faster in some scenarios.
A view is conceptually a transformation function over documents from zero ormore collections. It is uniquely identified by its view identifier. It also hasa unique name that clients should use to identify and access it. Views can berenamed. Renaming a view will change the view name, but not the view identifier.The conceptual transformation function employed by a view type is implementationspecific. The type is specified by the user when the view is created, and cannotbe changed later. The following view types are currently supported:
A view identifier identifies a view in a database. It is a string value and isunique within the database. Clients should use a view’s unique name to access aview instead of its identifier.
ArangoDB currently uses 64bit unsigned integer values to maintain view idsinternally. When returning view ids to clients, ArangoDB will put them into astring to ensure the view id is not clipped by clients that do not support bigintegers. Clients should treat the view ids returned by ArangoDB as opaquestrings when they store or use them locally.
A view name identifies a view in a database. It is a string and is unique withinthe database. Unlike the view identifier it is supplied by the creator of theview. The view name must consist of letters, digits, and the _ (underscore)and - (dash) characters only. Please refer to formore information on valid view names, which follow the same guidelines ascollection names.