mirror of https://gitee.com/bigwinds/arangodb
Doc - Fix build (whitespaces, triple-backticks, comments) (#7857)
This commit is contained in:
parent
3bf3818ba9
commit
f7b9733a84
|
@ -70,7 +70,6 @@ and maximum tick values per logfile:
|
|||
|
||||
require("@arangodb/replication").logger.tickRanges();
|
||||
|
||||
|
||||
### Replication Applier
|
||||
|
||||
**Purpose**
|
||||
|
|
|
@ -118,7 +118,8 @@ details, including the index-identifier, is returned.
|
|||
@endDocuBlock ensureHashIndexArray
|
||||
|
||||
|
||||
<!-- Creating Hash Index in Background
|
||||
{###
|
||||
Creating Hash Index in Background
|
||||
---------------------------------
|
||||
|
||||
{% hint 'info' %}
|
||||
|
@ -127,7 +128,7 @@ 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 undesireable, if you have to perform it
|
||||
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.
|
||||
|
@ -138,9 +139,10 @@ To create an hash index in the background in *arangosh* just specify `inBackgrou
|
|||
|
||||
```js
|
||||
db.collection.ensureIndex({ type: "hash", fields: [ "value" ], inBackground: true });
|
||||
``` -->
|
||||
```
|
||||
|
||||
For more information see [Creating Indexes in Background](IndexBasics.md#creating-indexes-in-background)
|
||||
For more information see "Creating Indexes in Background" in the [Index basics](IndexBasics.md) page.
|
||||
###}
|
||||
|
||||
Ensure uniqueness of relations in edge collections
|
||||
--------------------------------------------------
|
||||
|
|
|
@ -22,13 +22,15 @@ are covered by an edge collection's edge index automatically.
|
|||
Using the system attribute `_id` in user-defined indexes is not possible, but
|
||||
indexing `_key`, `_rev`, `_from`, and `_to` is.
|
||||
|
||||
<!-- Creating new indexes is usually done under an exclusive collection lock. The collection is not
|
||||
available as long as the index is created. This "foreground" index creation can be undesireable,
|
||||
{###
|
||||
Creating new indexes is usually done under an exclusive collection lock. The collection is 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.
|
||||
|
||||
For potentially long running index creation operations the _rocksdb_ storage-engine also supports
|
||||
creating indexes in "background". The colletion remains available durint the index creation,
|
||||
see the section [Creating Indexes in Background](#creating-indexes-in-background) for more information. -->
|
||||
creating indexes in "background". The collection remains available during the index creation,
|
||||
see the section "Creating Indexes in Background" for more information.
|
||||
###}
|
||||
|
||||
ArangoDB provides the following index types:
|
||||
|
||||
|
@ -549,7 +551,7 @@ based on the costs it estimates, even if a vertex centric index might
|
|||
in fact be faster. Vertex centric indexes are more likely to be chosen
|
||||
for highly connected graphs and with RocksDB storage engine.
|
||||
|
||||
<!--
|
||||
{###
|
||||
Creating Indexes in Background
|
||||
------------------------------
|
||||
|
||||
|
@ -559,10 +561,10 @@ 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 undesireable, if you have to perform it
|
||||
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.
|
||||
**STARTING FROM VERSION vX.Y.Z**, 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.
|
||||
|
||||
|
@ -584,7 +586,7 @@ db.collection.ensureIndex({ type: "geo", fields: [ "latitude", "longitude"], inB
|
|||
db.collection.ensureIndex({ type: "fulltext", fields: [ "text" ], minLength: 4, inBackground: true })
|
||||
```
|
||||
|
||||
### Behaviour
|
||||
### Behavior
|
||||
|
||||
Indexes that are still in the build process will not be visible via the ArangoDB API. Nevertheless it is not
|
||||
possible to create the same index twice via the *ensureIndex* API. AQL Queries will not use these indexes either
|
||||
|
@ -601,10 +603,11 @@ In the ArangoDB cluster the index might then be automatically recreated on affec
|
|||
|
||||
### Performance
|
||||
|
||||
The backround index creation might be slower than the "foreground" index creation and require more RAM.
|
||||
The background index creation might be slower than the "foreground" index creation and require more RAM.
|
||||
Under a write heavy load (specifically many remove, update or replace) operations,
|
||||
the background index creation needs to keep a list of removed documents in RAM. This might become unsuistainable
|
||||
the background index creation needs to keep a list of removed documents in RAM. This might become unsustainable
|
||||
if this list grows to tens of millions of entries.
|
||||
|
||||
Building an index is always a write heavy operation (internally), it is alsways a good idea to build indexes
|
||||
during times with less load. -->
|
||||
Building an index is always a write heavy operation (internally), it is always a good idea to build indexes
|
||||
during times with less load.
|
||||
###}
|
||||
|
|
|
@ -187,8 +187,9 @@ and
|
|||
will match.
|
||||
|
||||
|
||||
<!-- Creating Skiplist Index in Background
|
||||
---------------------------------
|
||||
{###
|
||||
Creating Skiplist Index in Background
|
||||
-------------------------------------
|
||||
|
||||
{% hint 'info' %}
|
||||
This section only applies to the *rocksdb* storage engine
|
||||
|
@ -196,7 +197,7 @@ 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 undesireable, if you have to perform it
|
||||
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.
|
||||
|
@ -209,4 +210,5 @@ To create a Skiplist index in the background in *arangosh* just specify `inBackg
|
|||
db.collection.ensureIndex({ type: "skiplist", fields: [ "value" ], inBackground: true });
|
||||
```
|
||||
|
||||
For more information see [Creating Indexes in Background](IndexBasics.md#creating-indexes-in-background) -->
|
||||
For more information see "Creating Indexes in Background" in the [Index basics](IndexBasics.md#) page.
|
||||
###}
|
||||
|
|
Loading…
Reference in New Issue