Hash Indexes

The hash index type is deprecated for the RocksDB storage engine.
It is the same as the persistent type when using RocksDB. The type hash
is still allowed for backward compatibility in the APIs, but the web interface
does not offer this type anymore.

Introduction to Hash Indexes

It is possible to define a hash index on one or more attributes (or paths) of a
document. This hash index is then used in queries to locate documents in O(1)
operations. If the hash index is unique, then no two documents are allowed to have the
same set of attribute values.

Creating a new document or updating a document will fail if the uniqueness is violated.
If the index is declared sparse, a document will be excluded from the index and no
uniqueness checks will be performed if any index attribute value is not set or has a value
of null.

In case that the index was successfully created, the index identifier is returned.

Non-existing attributes will default to null.
In a sparse index all documents will be excluded from the index for which all
specified index attributes are null. Such documents will not be taken into account
for uniqueness checks.

In a non-sparse index, all documents regardless of null - attributes will be
indexed and will be taken into account for uniqueness checks.

In case that the index was successfully created, an object with the index
details, including the index-identifier, is returned.

Hash Array Indexes

Creates a non-unique hash array index for the individual elements of the array
attributes field1[*], … fieldn[*] found in the documents. At least
one attribute path has to be given. The index always treats the indexed arrays as
sparse.

Creating Hash Index in Background

This section only applies to the rocksdb storage engine

Creating new indexes is by default done under an exclusive collection lock. This means
that the collection (or the respective shards) are not available as long as the index
is created. This “foreground” index creation can be undesirable, if you have to perform it
on a live system without a dedicated maintenance window.

Indexes can also be created in “background”, not using an exclusive lock during the creation.
The collection remains available, other CRUD operations can run on the collection while the index is created.
This can be achieved by using the inBackground option.

To create an hash index in the background in arangosh just specify inBackground: true:

For more information see “Creating Indexes in Background” in the Index basics page.

Ensure uniqueness of relations in edge collections

It is possible to create secondary indexes using the edge attributes _from
and _to, starting with ArangoDB 3.0. A combined index over both fields together
with the unique option enabled can be used to prevent duplicate relations from
being created.

For example, a document collection verts might contain vertices with the document
handles verts/A, verts/B and verts/C. Relations between these documents can
be stored in an edge collection edges for instance. Now, you may want to make sure
that the vertex verts/A is never linked to verts/B by an edge more than once.
This can be achieved by adding a unique, non-sparse hash index for the fields _from
and _to:

Creating an edge { _from: "verts/A", _to: "verts/B" } in edges will be accepted,
but only once. Another attempt to store an edge with the relation A → B will
be rejected by the server with a unique constraint violated error. This includes
updates to the _from and _to fields.

Note that adding a relation B → A is still possible, so is A → A
and B → B, because they are all different relations in a directed graph.
Each one can only occur once however.