consolidationIntervalMsec - Wait at least this many milliseconds between committing index data changes and
making them visible to queries (default: 60000, 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.
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 data directory
(default: 10, 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.
primarySortCache - If you enable this option, then the primary sort columns are always cached in memory.
This can improve the performance of queries that utilize the primary sort order.
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.
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.