Hawkin
/
arangodb
mirror of https://gitee.com/bigwinds/arangodb
1
0
Fork 0
Code Issues Projects Releases Wiki Activity

Doc - Fix build (whitespaces, triple-backticks, comments) (#7857)

This commit is contained in:
Simran 2018-12-26 12:41:19 -08:00 committed by sleto-it
parent 3bf3818ba9
commit f7b9733a84
11 changed files with 253 additions and 247 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

1
Documentation/Books/Manual/Architecture/DeploymentModes/MasterSlave/Architecture.md
View File

@ -70,7 +70,6 @@ and maximum tick values per logfile:
require("@arangodb/replication").logger.tickRanges(); require("@arangodb/replication").logger.tickRanges();
### Replication Applier ### Replication Applier
**Purpose** **Purpose**

10
Documentation/Books/Manual/Indexing/Hash.md
View File

@ -118,7 +118,8 @@ details, including the index-identifier, is returned.
@endDocuBlock ensureHashIndexArray @endDocuBlock ensureHashIndexArray
<!-- Creating Hash Index in Background {###
Creating Hash Index in Background
--------------------------------- ---------------------------------
{% hint 'info' %} {% 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 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 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. on a live system without a dedicated maintenance window.
Indexes can also be created in "background", not using an exclusive lock during the creation. 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 ```js
db.collection.ensureIndex({ type: "hash", fields: [ "value" ], inBackground: true }); 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 Ensure uniqueness of relations in edge collections
-------------------------------------------------- --------------------------------------------------

27
Documentation/Books/Manual/Indexing/IndexBasics.md
View File

@ -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 Using the system attribute `_id` in user-defined indexes is not possible, but
indexing `_key`, `_rev`, `_from`, and `_to` is. 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. 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 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, creating indexes in "background". The collection remains available during the index creation,
see the section [Creating Indexes in Background](#creating-indexes-in-background) for more information. --> see the section "Creating Indexes in Background" for more information.
###}
ArangoDB provides the following index types: 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 in fact be faster. Vertex centric indexes are more likely to be chosen
for highly connected graphs and with RocksDB storage engine. for highly connected graphs and with RocksDB storage engine.
<!-- {###
Creating Indexes in Background 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 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 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. 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. 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. 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 }) 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 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 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 ### 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, 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. 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 Building an index is always a write heavy operation (internally), it is always a good idea to build indexes
during times with less load. --> during times with less load.
###}

10
Documentation/Books/Manual/Indexing/Skiplist.md
View File

@ -187,8 +187,9 @@ and
will match. will match.
<!-- Creating Skiplist Index in Background {###
--------------------------------- Creating Skiplist Index in Background
-------------------------------------
{% hint 'info' %} {% hint 'info' %}
This section only applies to the *rocksdb* storage engine 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 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 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. on a live system without a dedicated maintenance window.
Indexes can also be created in "background", not using an exclusive lock during the creation. 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 }); 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.
###}