diff --git a/Documentation/Books/Manual/Graphs/SmartGraphs/README.md b/Documentation/Books/Manual/Graphs/SmartGraphs/README.md
index a97ddb3d0d..1bfbaf53a5 100644
--- a/Documentation/Books/Manual/Graphs/SmartGraphs/README.md
+++ b/Documentation/Books/Manual/Graphs/SmartGraphs/README.md
@@ -6,17 +6,20 @@ This feature is only available in the
[**Enterprise Edition**](https://www.arangodb.com/why-arangodb/arangodb-enterprise/)
{% endhint %}
-This chapter describes the [smart-graph](../README.md) module.
-It enables you to manage graphs at scale, it will give a vast performance benefit for all graphs sharded in an ArangoDB Cluster.
-On a single server this feature is pointless, hence it is only available in a cluster mode.
-In terms of querying there is no difference between smart and General Graphs.
-The former are a transparent replacement for the latter.
-So for querying the graph please refer to [AQL Graph Operations](../../../AQL/Graphs/index.html)
-and [Graph Functions](../GeneralGraphs/Functions.md) sections.
-The optimizer is clever enough to identify if we are on a SmartGraph or not.
+This chapter describes the `smart-graph` module, which enables you to manage
+graphs at scale. It will give a vast performance benefit for all graphs sharded
+in an ArangoDB Cluster. On a single server this feature is pointless, hence it
+is only available in cluster mode.
-The difference is only in the management section: creating and modifying the underlying collections of the graph.
-For a detailed API reference please refer to [SmartGraph Management](../SmartGraphs/Management.md).
+In terms of querying there is no difference between SmartGraphs and
+General Graphs. The former is a transparent replacement for the latter.
+For graph querying please refer to [AQL Graph Operations](../../../AQL/Graphs/index.html)
+and [General Graph Functions](../GeneralGraphs/Functions.md) sections.
+The optimizer is clever enough to identify whether it is a SmartGraph or not.
+
+The difference is only in the management section: creating and modifying the
+underlying collections of the graph. For a detailed API reference please refer
+to [SmartGraph Management](Management.md).
Do the hands-on
[ArangoDB SmartGraphs Tutorial](https://www.arangodb.com/using-smartgraphs-arangodb/)
@@ -25,50 +28,63 @@ to learn more.
What makes a graph smart?
-------------------------
-Most graphs have one feature that divides the entire graph into several smaller subgraphs.
-These subgraphs have a large amount of edges that only connect vertices in the same subgraph
-and only have few edges connecting vertices from other subgraphs.
+Most graphs have one feature that divides the entire graph into several smaller
+subgraphs. These subgraphs have a large amount of edges that only connect
+vertices in the same subgraph and only have few edges connecting vertices from
+other subgraphs.
+
Examples for these graphs are:
-* Social Networks
-
+- **Social Networks**
Typically the feature here is the region/country users live in.
- Every user typically has more contacts in the same region/country then she has in other regions/countries
+ Every user typically has more contacts in the same region/country then she
+ has in other regions/countries
-* Transport Systems
+- **Transport Systems**
+ For those also the feature is the region/country. You have many local
+ transportation but only few across countries.
- For those also the feature is the region/country. You have many local transportation but only few across countries.
-
-* E-Commerce
-
- In this case probably the category of products is a good feature. Often products of the same category are bought together.
+- **E-Commerce**
+ In this case probably the category of products is a good feature.
+ Often products of the same category are bought together.
If this feature is known, SmartGraphs can make use if it.
-When creating a SmartGraph you have to define a smartAttribute, which is the name of an attribute stored in every vertex.
-The graph will than be automatically sharded in such a way that all vertices with the same value are stored on the same physical machine,
-all edges connecting vertices with identical smartAttribute values are stored on this machine as well.
-During query time the query optimizer and the query executor both know for every document exactly where it is stored and can thereby minimize network overhead.
-Everything that can be computed locally will be computed locally.
+
+When creating a SmartGraph you have to define a smartAttribute, which is the
+name of an attribute stored in every vertex. The graph will than be
+automatically sharded in such a way that all vertices with the same value are
+stored on the same physical machine, all edges connecting vertices with
+identical smartAttribute values are stored on this machine as well.
+During query time the query optimizer and the query executor both know for
+every document exactly where it is stored and can thereby minimize network
+overhead. Everything that can be computed locally will be computed locally.
Benefits of SmartGraphs
-----------------------
-Because of the above described guaranteed sharding, the performance of queries that only cover one subgraph have a performance almost equal to an only local computation.
-Queries that cover more than one subgraph require some network overhead. The more subgraphs are touched the more network cost will apply.
-However the overall performance is never worse than the same query on a General Graph.
+Because of the above described guaranteed sharding, the performance of queries
+that only cover one subgraph have a performance almost equal to an only local
+computation. Queries that cover more than one subgraph require some network
+overhead. The more subgraphs are touched the more network cost will apply.
+However the overall performance is never worse than the same query using a
+General Graph.
Getting started
---------------
-First of all SmartGraphs *cannot use existing collections*, when switching to SmartGraph from an existing data set you have to import the data into a fresh SmartGraph.
-This switch can be easily achieved with [arangodump](../../Programs/Arangodump/README.md)
-and [arangorestore](../../Programs/Arangorestore/README.md).
-The only thing you have to change in this pipeline is that you create the new collections with the SmartGraph before starting `arangorestore`.
+First of all SmartGraphs *cannot use existing collections*, when switching to
+SmartGraph from an existing data set you have to import the data into a fresh
+SmartGraph. This switch can be easily achieved with
+[arangodump](../../Programs/Arangodump/README.md) and
+[arangorestore](../../Programs/Arangorestore/README.md).
+The only thing you have to change in this pipeline is that you create the new
+collections with the SmartGraph before starting `arangorestore`.
-* Create a graph
-
- In comparison to General Graph we have to add more options when creating the graph. The two options `smartGraphAttribute` and `numberOfShards` are required and cannot be modified later.
+- Create a graph
+ In comparison to General Graph we have to add more options when creating the
+ graph. The two options `smartGraphAttribute` and `numberOfShards` are
+ required and cannot be modified later.
@startDocuBlockInline smartGraphCreateGraphHowTo1
arangosh> var graph_module = require("@arangodb/smart-graph");
@@ -77,11 +93,10 @@ The only thing you have to change in this pipeline is that you create the new co
[ SmartGraph myGraph EdgeDefinitions: [ ] VertexCollections: [ ] ]
@endDocuBlock smartGraphCreateGraphHowTo1
+- Add some vertex collections
-* Add some vertex collections
-
- This is again identical to General Graph. The module will setup correct sharding for all these collections. *Note*: The collections have to be new.
-
+ This is again identical to General Graph. The module will setup correct
+ sharding for all these collections. *Note*: The collections have to be new.
@startDocuBlockInline smartGraphCreateGraphHowTo2
arangosh> graph._addVertexCollection("shop");
@@ -91,13 +106,11 @@ The only thing you have to change in this pipeline is that you create the new co
[ SmartGraph myGraph EdgeDefinitions: [ ] VertexCollections: [ "shop", "customer", "pet" ] ]
@endDocuBlock smartGraphCreateGraphHowTo2
-
-* Define relations on the Graph
-
+- Define relations on the Graph
@startDocuBlockInline smartGraphCreateGraphHowTo3
arangosh> var rel = graph_module._relation("isCustomer", ["shop"], ["customer"]);
arangosh> graph._extendEdgeDefinitions(rel);
arangosh> graph;
- [ SmartGraph myGraph EdgeDefinitions: [ "isCustomer: [shop] -> [customer]" ] VertexCollections: [ "pet" ] ]
+ [ SmartGraph myGraph EdgeDefinitions: [ "isCustomer: [shop] -> [customer]" ] VertexCollections: [ "pet" ] ]
@endDocuBlock smartGraphCreateGraphHowTo3
diff --git a/Documentation/Books/Manual/Views/ArangoSearch/DetailedOverview.md b/Documentation/Books/Manual/Views/ArangoSearch/DetailedOverview.md
index 321d7ddb56..07d13cd0ea 100644
--- a/Documentation/Books/Manual/Views/ArangoSearch/DetailedOverview.md
+++ b/Documentation/Books/Manual/Views/ArangoSearch/DetailedOverview.md
@@ -165,7 +165,7 @@ is used by these writers (in terms of "writers pool") one can use
upon several possible configurable formulas as defined by their types.
The currently supported types are:
- - **bytes_accum**: Consolidation is performed based on current memory cunsumption
+ - **bytes_accum**: Consolidation is performed based on current memory consumption
of segments and `threshold` property value.
- **tier**: Consolidate based on segment byte size and live document count
as dictated by the customization attributes.
diff --git a/Documentation/DocuBlocks/Rest/Views/patch_api_view_properties_iresearch.md b/Documentation/DocuBlocks/Rest/Views/patch_api_view_properties_iresearch.md
index be31483d00..cb879fd1e2 100644
--- a/Documentation/DocuBlocks/Rest/Views/patch_api_view_properties_iresearch.md
+++ b/Documentation/DocuBlocks/Rest/Views/patch_api_view_properties_iresearch.md
@@ -20,8 +20,8 @@ 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:
+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
@@ -38,8 +38,8 @@ 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:
+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.
@@ -60,8 +60,8 @@ 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:
+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
@@ -71,8 +71,8 @@ Background:
@RESTSTRUCT{consolidationPolicy,post_api_view_props,object,optional,post_api_view_props_consolidation}
The consolidation policy to apply for selecting which segments should be merged
-(default: {})
-Background:
+(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
@@ -85,16 +85,16 @@ Background:
released once old segments are no longer used.
-@RESTSTRUCT{type,post_api_view_props_consolidations,string,optional,string}
+@RESTSTRUCT{type,post_api_view_props_consolidation,string,optional,string}
The segment candidates for the "consolidation" operation are selected based
upon several possible configurable formulas as defined by their types.
The currently supported types are (default: "bytes_accum"):
-- *bytes_accum*: consolidate if and only if ({threshold} range `[0.0, 1.0]`):
- {threshold} > (segment_bytes + sum_of_merge_candidate_segment_bytes) / all_segment_bytes
+- *bytes_accum*: consolidate if and only if (`{threshold}` range `[0.0, 1.0]`):
+ `{threshold} > (segment_bytes + sum_of_merge_candidate_segment_bytes) / all_segment_bytes`
i.e. the sum of all candidate segment byte size is less than the total
- segment byte size multiplied by the {threshold}
+ segment byte size multiplied by the `{threshold}`
- *tier*: consolidate based on segment byte size and live document count
- as dicated by the customization attributes.
+ as dictated by the customization attributes.
@RESTSTRUCT{links,post_api_view_props,object,optional,post_api_view_links}
diff --git a/Documentation/DocuBlocks/Rest/Views/post_api_view_iresearch.md b/Documentation/DocuBlocks/Rest/Views/post_api_view_iresearch.md
index c4ecaf2973..bf67c29b8a 100644
--- a/Documentation/DocuBlocks/Rest/Views/post_api_view_iresearch.md
+++ b/Documentation/DocuBlocks/Rest/Views/post_api_view_iresearch.md
@@ -21,8 +21,8 @@ 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:
+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
@@ -39,8 +39,8 @@ 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:
+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.
@@ -61,8 +61,8 @@ 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:
+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
@@ -72,8 +72,8 @@ Background:
@RESTSTRUCT{consolidationPolicy,post_api_view_props,object,optional,post_api_view_props_consolidation}
The consolidation policy to apply for selecting which segments should be merged
-(default: {})
-Background:
+(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
@@ -86,16 +86,16 @@ Background:
released once old segments are no longer used.
-@RESTSTRUCT{type,post_api_view_props_consolidations,string,optional,string}
+@RESTSTRUCT{type,post_api_view_props_consolidation,string,optional,string}
The segment candidates for the "consolidation" operation are selected based
upon several possible configurable formulas as defined by their types.
The currently supported types are (default: "bytes_accum"):
-- *bytes_accum*: consolidate if and only if ({threshold} range `[0.0, 1.0]`):
- {threshold} > (segment_bytes + sum_of_merge_candidate_segment_bytes) / all_segment_bytes
+- *bytes_accum*: consolidate if and only if (`{threshold}` range `[0.0, 1.0]`):
+ `{threshold} > (segment_bytes + sum_of_merge_candidate_segment_bytes) / all_segment_bytes`
i.e. the sum of all candidate segment byte size is less than the total
- segment byte size multiplied by the {threshold}
+ segment byte size multiplied by the `{threshold}`
- *tier*: consolidate based on segment byte size and live document count
- as dicated by the customization attributes.
+ as dictated by the customization attributes.
@RESTSTRUCT{links,post_api_view_props,object,optional,post_api_view_links}
diff --git a/Documentation/DocuBlocks/Rest/Views/put_api_view_properties_iresearch.md b/Documentation/DocuBlocks/Rest/Views/put_api_view_properties_iresearch.md
index 70c872db13..5a485104c1 100644
--- a/Documentation/DocuBlocks/Rest/Views/put_api_view_properties_iresearch.md
+++ b/Documentation/DocuBlocks/Rest/Views/put_api_view_properties_iresearch.md
@@ -20,8 +20,8 @@ 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:
+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
@@ -38,8 +38,8 @@ 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:
+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.
@@ -60,8 +60,8 @@ 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:
+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
@@ -71,8 +71,8 @@ Background:
@RESTSTRUCT{consolidationPolicy,post_api_view_props,object,optional,post_api_view_props_consolidation}
The consolidation policy to apply for selecting which segments should be merged
-(default: {})
-Background:
+(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
@@ -85,16 +85,16 @@ Background:
released once old segments are no longer used.
-@RESTSTRUCT{type,post_api_view_props_consolidations,string,optional,string}
+@RESTSTRUCT{type,post_api_view_props_consolidation,string,optional,string}
The segment candidates for the "consolidation" operation are selected based
upon several possible configurable formulas as defined by their types.
The currently supported types are (default: "bytes_accum"):
-- *bytes_accum*: consolidate if and only if ({threshold} range `[0.0, 1.0]`):
- {threshold} > (segment_bytes + sum_of_merge_candidate_segment_bytes) / all_segment_bytes
+- *bytes_accum*: consolidate if and only if (`{threshold}` range `[0.0, 1.0]`):
+ `{threshold} > (segment_bytes + sum_of_merge_candidate_segment_bytes) / all_segment_bytes`
i.e. the sum of all candidate segment byte size is less than the total
- segment byte size multiplied by the {threshold}
+ segment byte size multiplied by the `{threshold}`
- *tier*: consolidate based on segment byte size and live document count
- as dicated by the customization attributes.
+ as dictated by the customization attributes.
@RESTSTRUCT{links,post_api_view_props,object,optional,post_api_view_links}
diff --git a/js/apps/system/_admin/aardvark/APP/frontend/js/templates/navigationView.ejs b/js/apps/system/_admin/aardvark/APP/frontend/js/templates/navigationView.ejs
index c494d302be..b4c945b610 100644
--- a/js/apps/system/_admin/aardvark/APP/frontend/js/templates/navigationView.ejs
+++ b/js/apps/system/_admin/aardvark/APP/frontend/js/templates/navigationView.ejs
@@ -11,7 +11,7 @@
-
+