primarySort - You can define a primary sort order to enable an AQL optimization. If a query iterates over
all documents of a collection, wants to sort them by attribute values, and the (left-most)
fields to sort by, as well as their sorting direction, match with the primarySort definition,
then the SORT operation is optimized away.
storedValues - The optional storedValues attribute can contain an array of paths to additional attributes to
store in the index. These additional attributes cannot be used for index lookups or for
sorting, but they can be used for projections. This allows an index to fully cover more
queries and avoid extra document lookups.
analyzer - The name of an Analyzer to use by default. This Analyzer is applied to the values of the indexed
fields for which you don’t define Analyzers explicitly.
includeAllFields - This option only applies if you use the inverted index in a search-alias Views. If set to
true, then all sub-attributes of this field are indexed, excluding any sub-attributes
that are configured separately by other elements in the fields array (and their
sub-attributes). The analyzer and features properties apply to the sub-attributes. If set
to false, then sub-attributes are ignored. The default value is defined by the top-level
includeAllFields option, or false if not set.
trackListPositions - This option only applies if you use the inverted index in a search-alias Views. If set
to true, then track the value position in arrays for array values. For example, when
querying a document like { attr: [ "valueX", "valueY", "valueZ" ] }, you need to
specify the array element, e.g. doc.attr[1] == "valueY". If set to false, all values in
an array are treated as equal alternatives. You don’t specify an array element in
queries, e.g. doc.attr == "valueY", and all elements are searched for a match. Default:
the value defined by the top-level trackListPositions option, or false if not set.
searchField - This option only applies if you use the inverted index in a search-alias Views. You can set
the option to true to get the same behavior as with arangosearch Views regarding the indexing
of array values as the default. If enabled, both, array and primitive values (strings,
numbers, etc.) are accepted. Every element of an array is indexed according to the
trackListPositions option. If set to false, it depends on the attribute path. If it explicitly
expand an array ([*]), then the elements are indexed separately. Otherwise, the array is
indexed as a whole, but only geopoint and aql Analyzers accept array inputs. You cannot use an
array expansion if searchField is enabled.
consolidationIntervalMsec - Wait at least this many milliseconds between applying ‘consolidationPolicy’ to
consolidate View data store and possibly release space on the filesystem
(default: 1000, to disable use: 0). For the case where there are a lot of data
modification operations, a higher value could potentially have the data store
consume more space and file handles. For the case where there are a few data
modification operations, a lower value will impact performance due to no segment
candidates available for consolidation. Background: For data modification
ArangoSearch Views follow the concept of a “versioned data store”. Thus old
versions of data may be removed once there are no longer any users of the old
data. The frequency of the cleanup and compaction operations are governed by
‘consolidationIntervalMsec’ and the candidates for compaction are selected via
‘consolidationPolicy’.
commitIntervalMsec - Wait at least this many milliseconds between committing View data store changes and
making documents visible to queries (default: 1000, to disable use: 0). For the case
where there are a lot of inserts/updates, a lower value, until commit, will cause the
index not to account for them and memory usage would continue to grow. For the case
where there are a few inserts/updates, a higher value will impact performance and waste
disk space for each commit call without any added benefits. Background: For data
retrieval ArangoSearch Views follow the concept of “eventually-consistent”, i.e.
eventually all the data in ArangoDB will be matched by corresponding query expressions.
The concept of ArangoSearch View “commit” operation is introduced to control the
upper-bound on the time until document addition/removals are actually reflected by
corresponding query expressions. Once a “commit” operation is complete all documents
added/removed prior to the start of the “commit” operation will be reflected by queries
invoked in subsequent ArangoDB transactions, in-progress ArangoDB transactions will
still continue to return a repeatable-read state.
cleanupIntervalStep - Wait at least this many commits between removing unused files in the ArangoSearch data
directory (default: 2, to disable use: 0). For the case where the consolidation
policies merge segments often (i.e. a lot of commit+consolidate), a lower value will
cause a lot of disk space to be wasted. For the case where the consolidation policies
rarely merge segments (i.e. few inserts/deletes), a higher value will impact
performance without any added benefits. Background: With every “commit” or
“consolidate” operation a new state of the View internal data-structures is created on
disk. Old states/snapshots are released once there are no longer any users remaining.
However, the files for the released states/snapshots are left on disk, and only
removed by “cleanup” operation.
consolidationPolicy - The consolidation policy to apply for selecting which segments should be merged
(default: {}). Background: With each ArangoDB transaction that inserts documents one
or more ArangoSearch internal segments gets created. Similarly for removed documents
the segments that contain such documents will have these documents marked as
‘deleted’. Over time this approach causes a lot of small and sparse segments to be
created. A “consolidation” operation selects one or more segments and copies all of
their valid documents into a single new segment, thereby allowing the search algorithm
to perform more optimally and for extra file handles to be released once old segments
are no longer used.
writebufferActive - Maximum number of concurrent active writers (segments) that perform a transaction. Other
writers (segments) wait till current active writers (segments) finish (default: 0, use 0
to disable)
writebufferSizeMax - Maximum memory byte size per writer (segment) before a writer (segment) flush is
triggered. 0 value turns off this limit for any writer (buffer) and data will be
flushed periodically based on the value defined for the flush thread (ArangoDB server
startup option). 0 value should be used carefully due to high potential memory
consumption (default: 33554432, use 0 to disable)
cache - Enable this option to always cache the field normalization values in memory for all fields by
default. This can improve the performance of scoring and ranking queries. Otherwise, these values
are memory-mapped and it is up to the operating system to load them from disk into memory and to
evict them from memory.
Default: `false`. (Enterprise Edition only)
primaryKeyCache - If you enable this option, then the primary key columns are always cached in memory. This
can improve the performance of queries that return many documents. Otherwise, these values
are memory-mapped and it is up to the operating system to load them from disk into memory
and to evict them from memory (Enterprise Edition only). (default: false)