Fix typos in docs.
This commit is contained in:
parent
77a1649905
commit
21ea552070
|
@ -10,7 +10,7 @@ The queries in this group are:
|
||||||
<<java-query-dsl-geo-shape-query,`geo_shape`>> query::
|
<<java-query-dsl-geo-shape-query,`geo_shape`>> query::
|
||||||
|
|
||||||
Find document with geo-shapes which either intersect, are contained by, or
|
Find document with geo-shapes which either intersect, are contained by, or
|
||||||
do not interesect with the specified geo-shape.
|
do not intersect with the specified geo-shape.
|
||||||
|
|
||||||
<<java-query-dsl-geo-bounding-box-query,`geo_bounding_box`>> query::
|
<<java-query-dsl-geo-bounding-box-query,`geo_bounding_box`>> query::
|
||||||
|
|
||||||
|
|
|
@ -32,7 +32,7 @@ to your classpath in order to use this type:
|
||||||
|
|
||||||
[source,java]
|
[source,java]
|
||||||
--------------------------------------------------
|
--------------------------------------------------
|
||||||
// Import ShapeRelationn and ShapeBuilder
|
// Import ShapeRelation and ShapeBuilder
|
||||||
import org.elasticsearch.common.geo.ShapeRelation;
|
import org.elasticsearch.common.geo.ShapeRelation;
|
||||||
import org.elasticsearch.common.geo.builders.ShapeBuilder;
|
import org.elasticsearch.common.geo.builders.ShapeBuilder;
|
||||||
--------------------------------------------------
|
--------------------------------------------------
|
||||||
|
|
|
@ -43,7 +43,7 @@ releases 2.0 and later do not support rivers.
|
||||||
* https://www.elastic.co/guide/en/logstash/current/plugins-inputs-elasticsearch.html[Elasticsearch input to Logstash]
|
* https://www.elastic.co/guide/en/logstash/current/plugins-inputs-elasticsearch.html[Elasticsearch input to Logstash]
|
||||||
The Logstash `elasticsearch` input plugin.
|
The Logstash `elasticsearch` input plugin.
|
||||||
* https://www.elastic.co/guide/en/logstash/current/plugins-filters-elasticsearch.html[Elasticsearch event filtering in Logstash]
|
* https://www.elastic.co/guide/en/logstash/current/plugins-filters-elasticsearch.html[Elasticsearch event filtering in Logstash]
|
||||||
The Logstash `elasticearch` filter plugin.
|
The Logstash `elasticsearch` filter plugin.
|
||||||
* https://www.elastic.co/guide/en/logstash/current/plugins-codecs-es_bulk.html[Elasticsearch bulk codec]
|
* https://www.elastic.co/guide/en/logstash/current/plugins-codecs-es_bulk.html[Elasticsearch bulk codec]
|
||||||
The Logstash `es_bulk` plugin decodes the Elasticsearch bulk format into individual events.
|
The Logstash `es_bulk` plugin decodes the Elasticsearch bulk format into individual events.
|
||||||
|
|
||||||
|
|
|
@ -2,7 +2,7 @@
|
||||||
=== Range Aggregation
|
=== Range Aggregation
|
||||||
|
|
||||||
A multi-bucket value source based aggregation that enables the user to define a set of ranges - each representing a bucket. During the aggregation process, the values extracted from each document will be checked against each bucket range and "bucket" the relevant/matching document.
|
A multi-bucket value source based aggregation that enables the user to define a set of ranges - each representing a bucket. During the aggregation process, the values extracted from each document will be checked against each bucket range and "bucket" the relevant/matching document.
|
||||||
Note that this aggregration includes the `from` value and excludes the `to` value for each range.
|
Note that this aggregation includes the `from` value and excludes the `to` value for each range.
|
||||||
|
|
||||||
Example:
|
Example:
|
||||||
|
|
||||||
|
|
|
@ -77,7 +77,7 @@ tags of the issues the user has commented on:
|
||||||
}
|
}
|
||||||
--------------------------------------------------
|
--------------------------------------------------
|
||||||
|
|
||||||
As you can see above, the the `reverse_nested` aggregation is put in to a `nested` aggregation as this is the only place
|
As you can see above, the `reverse_nested` aggregation is put in to a `nested` aggregation as this is the only place
|
||||||
in the dsl where the `reversed_nested` aggregation can be used. Its sole purpose is to join back to a parent doc higher
|
in the dsl where the `reversed_nested` aggregation can be used. Its sole purpose is to join back to a parent doc higher
|
||||||
up in the nested structure.
|
up in the nested structure.
|
||||||
|
|
||||||
|
|
|
@ -34,7 +34,7 @@ Credits for the hyphenation code go to the Apache FOP project .
|
||||||
[float]
|
[float]
|
||||||
=== Dictionary decompounder
|
=== Dictionary decompounder
|
||||||
|
|
||||||
The `dictionary_decompounder` uses a brute force approach in conjuction with
|
The `dictionary_decompounder` uses a brute force approach in conjunction with
|
||||||
only the word dictionary to find subwords in a compound word. It is much
|
only the word dictionary to find subwords in a compound word. It is much
|
||||||
slower than the hyphenation decompounder but can be used as a first start to
|
slower than the hyphenation decompounder but can be used as a first start to
|
||||||
check the quality of your dictionary.
|
check the quality of your dictionary.
|
||||||
|
|
|
@ -16,7 +16,7 @@ attribute as follows:
|
||||||
------------------------
|
------------------------
|
||||||
bin/elasticsearch --node.rack rack1 --node.size big <1>
|
bin/elasticsearch --node.rack rack1 --node.size big <1>
|
||||||
------------------------
|
------------------------
|
||||||
<1> These attribute settings can also be specfied in the `elasticsearch.yml` config file.
|
<1> These attribute settings can also be specified in the `elasticsearch.yml` config file.
|
||||||
|
|
||||||
These metadata attributes can be used with the
|
These metadata attributes can be used with the
|
||||||
`index.routing.allocation.*` settings to allocate an index to a particular
|
`index.routing.allocation.*` settings to allocate an index to a particular
|
||||||
|
|
|
@ -186,7 +186,7 @@ Here is what it looks like when one shard group failed due to pending operations
|
||||||
}
|
}
|
||||||
--------------------------------------------------
|
--------------------------------------------------
|
||||||
|
|
||||||
NOTE: The above error is shown when the synced flush failes due to concurrent indexing operations. The HTTP
|
NOTE: The above error is shown when the synced flush fails due to concurrent indexing operations. The HTTP
|
||||||
status code in that case will be `409 CONFLICT`.
|
status code in that case will be `409 CONFLICT`.
|
||||||
|
|
||||||
Sometimes the failures are specific to a shard copy. The copies that failed will not be eligible for
|
Sometimes the failures are specific to a shard copy. The copies that failed will not be eligible for
|
||||||
|
|
|
@ -3,7 +3,7 @@
|
||||||
|
|
||||||
Provides store information for shard copies of indices.
|
Provides store information for shard copies of indices.
|
||||||
Store information reports on which nodes shard copies exist, the shard
|
Store information reports on which nodes shard copies exist, the shard
|
||||||
copy allocation ID, a unique identifer for each shard copy, and any exceptions
|
copy allocation ID, a unique identifier for each shard copy, and any exceptions
|
||||||
encountered while opening the shard index or from earlier engine failure.
|
encountered while opening the shard index or from earlier engine failure.
|
||||||
|
|
||||||
By default, only lists store information for shards that have at least one
|
By default, only lists store information for shards that have at least one
|
||||||
|
|
|
@ -61,7 +61,7 @@ All processors are defined in the following way within a pipeline definition:
|
||||||
Each processor defines its own configuration parameters, but all processors have
|
Each processor defines its own configuration parameters, but all processors have
|
||||||
the ability to declare `tag` and `on_failure` fields. These fields are optional.
|
the ability to declare `tag` and `on_failure` fields. These fields are optional.
|
||||||
|
|
||||||
A `tag` is simply a string identifier of the specific instatiation of a certain
|
A `tag` is simply a string identifier of the specific instantiation of a certain
|
||||||
processor in a pipeline. The `tag` field does not affect any processor's behavior,
|
processor in a pipeline. The `tag` field does not affect any processor's behavior,
|
||||||
but is very useful for bookkeeping and tracing errors to specific processors.
|
but is very useful for bookkeeping and tracing errors to specific processors.
|
||||||
|
|
||||||
|
@ -1079,7 +1079,7 @@ response:
|
||||||
|
|
||||||
It is often useful to see how each processor affects the ingest document
|
It is often useful to see how each processor affects the ingest document
|
||||||
as it is passed through the pipeline. To see the intermediate results of
|
as it is passed through the pipeline. To see the intermediate results of
|
||||||
each processor in the simulat request, a `verbose` parameter may be added
|
each processor in the simulate request, a `verbose` parameter may be added
|
||||||
to the request
|
to the request
|
||||||
|
|
||||||
Here is an example verbose request and its response:
|
Here is an example verbose request and its response:
|
||||||
|
|
|
@ -24,7 +24,7 @@ GET my_index/my_type/1?routing=user1 <2>
|
||||||
// AUTOSENSE
|
// AUTOSENSE
|
||||||
|
|
||||||
<1> This document uses `user1` as its routing value, instead of its ID.
|
<1> This document uses `user1` as its routing value, instead of its ID.
|
||||||
<2> The the same `routing` value needs to be provided when
|
<2> The same `routing` value needs to be provided when
|
||||||
<<docs-get,getting>>, <<docs-delete,deleting>>, or <<docs-update,updating>>
|
<<docs-get,getting>>, <<docs-delete,deleting>>, or <<docs-update,updating>>
|
||||||
the document.
|
the document.
|
||||||
|
|
||||||
|
|
|
@ -93,7 +93,7 @@ used for future documents.
|
||||||
|
|
||||||
==== Note on documents expiration
|
==== Note on documents expiration
|
||||||
|
|
||||||
Expired documents will be automatically deleted periodoically. The following
|
Expired documents will be automatically deleted periodically. The following
|
||||||
settings control the expiry process:
|
settings control the expiry process:
|
||||||
|
|
||||||
`indices.ttl.interval`::
|
`indices.ttl.interval`::
|
||||||
|
|
|
@ -22,7 +22,7 @@ are searchable. It accepts three values:
|
||||||
This option applies only to `string` fields, for which it is the default.
|
This option applies only to `string` fields, for which it is the default.
|
||||||
The string field value is first <<analysis,analyzed>> to convert the
|
The string field value is first <<analysis,analyzed>> to convert the
|
||||||
string into terms (e.g. a list of individual words), which are then
|
string into terms (e.g. a list of individual words), which are then
|
||||||
indexed. At search time, the the query string is passed through
|
indexed. At search time, the query string is passed through
|
||||||
(<<search-analyzer,usually>>) the same analyzer to generate terms
|
(<<search-analyzer,usually>>) the same analyzer to generate terms
|
||||||
in the same format as those in the index. It is this process that enables
|
in the same format as those in the index. It is this process that enables
|
||||||
<<full-text-queries,full text search>>.
|
<<full-text-queries,full text search>>.
|
||||||
|
|
|
@ -7,7 +7,7 @@ contain sub-fields, called `properties`. These properties may be of any
|
||||||
be added:
|
be added:
|
||||||
|
|
||||||
* explicitly by defining them when <<indices-create-index,creating an index>>.
|
* explicitly by defining them when <<indices-create-index,creating an index>>.
|
||||||
* explicitily by defining them when adding or updating a mapping type with the <<indices-put-mapping,PUT mapping>> API.
|
* explicitly by defining them when adding or updating a mapping type with the <<indices-put-mapping,PUT mapping>> API.
|
||||||
* <<dynamic-mapping,dynamically>> just by indexing documents containing new fields.
|
* <<dynamic-mapping,dynamically>> just by indexing documents containing new fields.
|
||||||
|
|
||||||
Below is an example of adding `properties` to a mapping type, an `object`
|
Below is an example of adding `properties` to a mapping type, an `object`
|
||||||
|
|
|
@ -22,7 +22,7 @@ configuration are:
|
||||||
|
|
||||||
`BM25`::
|
`BM25`::
|
||||||
The Okapi BM25 algorithm.
|
The Okapi BM25 algorithm.
|
||||||
See {defguide}/pluggable-similarites.html[Plugggable Similarity Algorithms]
|
See {defguide}/pluggable-similarites.html[Pluggable Similarity Algorithms]
|
||||||
for more information.
|
for more information.
|
||||||
|
|
||||||
|
|
||||||
|
|
|
@ -21,7 +21,7 @@ document:
|
||||||
<<nested>>:: `nested` for arrays of JSON objects
|
<<nested>>:: `nested` for arrays of JSON objects
|
||||||
|
|
||||||
[float]
|
[float]
|
||||||
=== Geo dataypes
|
=== Geo datatypes
|
||||||
|
|
||||||
<<geo-point>>:: `geo_point` for lat/lon points
|
<<geo-point>>:: `geo_point` for lat/lon points
|
||||||
<<geo-shape>>:: `geo_shape` for complex shapes like polygons
|
<<geo-shape>>:: `geo_shape` for complex shapes like polygons
|
||||||
|
|
|
@ -9,7 +9,7 @@ Fields of type `geo_point` accept latitude-longitude pairs, which can be used:
|
||||||
<<query-dsl-geohash-cell-query,geohash>> cell.
|
<<query-dsl-geohash-cell-query,geohash>> cell.
|
||||||
* to aggregate documents by <<search-aggregations-bucket-geohashgrid-aggregation,geographically>>
|
* to aggregate documents by <<search-aggregations-bucket-geohashgrid-aggregation,geographically>>
|
||||||
or by <<search-aggregations-bucket-geodistance-aggregation,distance>> from a central point.
|
or by <<search-aggregations-bucket-geodistance-aggregation,distance>> from a central point.
|
||||||
* to integerate distance into a document's <<query-dsl-function-score-query,relevance score>>.
|
* to integrate distance into a document's <<query-dsl-function-score-query,relevance score>>.
|
||||||
* to <<geo-sorting,sort>> documents by distance.
|
* to <<geo-sorting,sort>> documents by distance.
|
||||||
|
|
||||||
There are four ways that a geo-point may be specified, as demonstrated below:
|
There are four ways that a geo-point may be specified, as demonstrated below:
|
||||||
|
|
|
@ -44,7 +44,7 @@ The <<cluster-state,`cluster_state`>>, <<cluster-nodes-info,`nodes_info`>>,
|
||||||
<<cluster-nodes-stats,`nodes_stats`>> and <<indices-stats,`indices_stats`>>
|
<<cluster-nodes-stats,`nodes_stats`>> and <<indices-stats,`indices_stats`>>
|
||||||
APIs have all been changed to make their format more RESTful and less clumsy.
|
APIs have all been changed to make their format more RESTful and less clumsy.
|
||||||
|
|
||||||
For instance, if you just want the `nodes` section of the the `cluster_state`,
|
For instance, if you just want the `nodes` section of the `cluster_state`,
|
||||||
instead of:
|
instead of:
|
||||||
|
|
||||||
[source,sh]
|
[source,sh]
|
||||||
|
@ -320,7 +320,7 @@ longer be used to return whole objects and it no longer accepts the
|
||||||
parameters instead.
|
parameters instead.
|
||||||
|
|
||||||
* Settings, like `index.analysis.analyzer.default` are now returned as proper
|
* Settings, like `index.analysis.analyzer.default` are now returned as proper
|
||||||
nested JSON objects, which makes them easier to work with programatically:
|
nested JSON objects, which makes them easier to work with programmatically:
|
||||||
+
|
+
|
||||||
[source,js]
|
[source,js]
|
||||||
---------------
|
---------------
|
||||||
|
|
|
@ -25,7 +25,7 @@ Index templates can no longer be configured on disk. Use the
|
||||||
==== Analyze API changes
|
==== Analyze API changes
|
||||||
|
|
||||||
|
|
||||||
The Analyze API now returns the the `position` of the first token as `0`
|
The Analyze API now returns the `position` of the first token as `0`
|
||||||
instead of `1`.
|
instead of `1`.
|
||||||
|
|
||||||
The `prefer_local` parameter has been removed. The `_analyze` API is a light
|
The `prefer_local` parameter has been removed. The `_analyze` API is a light
|
||||||
|
|
|
@ -153,7 +153,7 @@ PUT my_index
|
||||||
}
|
}
|
||||||
}
|
}
|
||||||
----------------------------
|
----------------------------
|
||||||
<1> These two fields cannot be distinguised as both are referred to as `foo.bar`.
|
<1> These two fields cannot be distinguished as both are referred to as `foo.bar`.
|
||||||
|
|
||||||
You can no longer create fields with dots in the name.
|
You can no longer create fields with dots in the name.
|
||||||
|
|
||||||
|
|
|
@ -550,7 +550,7 @@ Removing individual setters for lon() and lat() values, both values should be se
|
||||||
Removing setters for to(Object ...) and from(Object ...) in favour of the only two allowed input
|
Removing setters for to(Object ...) and from(Object ...) in favour of the only two allowed input
|
||||||
arguments (String, Number). Removing setter for center point (point(), geohash()) because parameter
|
arguments (String, Number). Removing setter for center point (point(), geohash()) because parameter
|
||||||
is mandatory and should already be set in constructor.
|
is mandatory and should already be set in constructor.
|
||||||
Also removing setters for lt(), lte(), gt(), gte() since they can all be replaced by equivallent
|
Also removing setters for lt(), lte(), gt(), gte() since they can all be replaced by equivalent
|
||||||
calls to to/from() and inludeLower()/includeUpper().
|
calls to to/from() and inludeLower()/includeUpper().
|
||||||
|
|
||||||
==== GeoPolygonQueryBuilder
|
==== GeoPolygonQueryBuilder
|
||||||
|
|
|
@ -17,7 +17,7 @@ There are a number of settings available to control the shard allocation process
|
||||||
be distributed across different racks or availability zones.
|
be distributed across different racks or availability zones.
|
||||||
|
|
||||||
* <<allocation-filtering>> allows certain nodes or groups of nodes excluded
|
* <<allocation-filtering>> allows certain nodes or groups of nodes excluded
|
||||||
from allocation so that they can be decommisioned.
|
from allocation so that they can be decommissioned.
|
||||||
|
|
||||||
Besides these, there are a few other <<misc-cluster,miscellaneous cluster-level settings>>.
|
Besides these, there are a few other <<misc-cluster,miscellaneous cluster-level settings>>.
|
||||||
|
|
||||||
|
|
|
@ -7,10 +7,10 @@ you to allow or disallow the allocation of shards from *any* index to
|
||||||
particular nodes.
|
particular nodes.
|
||||||
|
|
||||||
The typical use case for cluster-wide shard allocation filtering is when you
|
The typical use case for cluster-wide shard allocation filtering is when you
|
||||||
want to decommision a node, and you would like to move the shards from that
|
want to decommission a node, and you would like to move the shards from that
|
||||||
node to other nodes in the cluster before shutting it down.
|
node to other nodes in the cluster before shutting it down.
|
||||||
|
|
||||||
For instance, we could decomission a node using its IP address as follows:
|
For instance, we could decommission a node using its IP address as follows:
|
||||||
|
|
||||||
[source,js]
|
[source,js]
|
||||||
--------------------------------------------------
|
--------------------------------------------------
|
||||||
|
|
|
@ -28,7 +28,7 @@ Defaults to `_local_`.
|
||||||
`discovery.zen.ping.unicast.hosts`::
|
`discovery.zen.ping.unicast.hosts`::
|
||||||
|
|
||||||
In order to join a cluster, a node needs to know the hostname or IP address of
|
In order to join a cluster, a node needs to know the hostname or IP address of
|
||||||
at least some of the other nodes in the cluster. This settting provides the
|
at least some of the other nodes in the cluster. This setting provides the
|
||||||
initial list of other nodes that this node will try to contact. Accepts IP
|
initial list of other nodes that this node will try to contact. Accepts IP
|
||||||
addresses or hostnames.
|
addresses or hostnames.
|
||||||
+
|
+
|
||||||
|
|
|
@ -11,7 +11,7 @@ The queries in this group are:
|
||||||
<<query-dsl-geo-shape-query,`geo_shape`>> query::
|
<<query-dsl-geo-shape-query,`geo_shape`>> query::
|
||||||
|
|
||||||
Find document with geo-shapes which either intersect, are contained by, or
|
Find document with geo-shapes which either intersect, are contained by, or
|
||||||
do not interesect with the specified geo-shape.
|
do not intersect with the specified geo-shape.
|
||||||
|
|
||||||
<<query-dsl-geo-bounding-box-query,`geo_bounding_box`>> query::
|
<<query-dsl-geo-bounding-box-query,`geo_bounding_box`>> query::
|
||||||
|
|
||||||
|
|
|
@ -77,7 +77,7 @@ GET /_search
|
||||||
}
|
}
|
||||||
}
|
}
|
||||||
------------------------------------------
|
------------------------------------------
|
||||||
<1> Name of the the query template in `config/scripts/`, i.e., `my_template.mustache`.
|
<1> Name of the query template in `config/scripts/`, i.e., `my_template.mustache`.
|
||||||
|
|
||||||
Alternatively, you can register a query template in the special `.scripts` index with:
|
Alternatively, you can register a query template in the special `.scripts` index with:
|
||||||
|
|
||||||
|
@ -106,7 +106,7 @@ GET /_search
|
||||||
}
|
}
|
||||||
}
|
}
|
||||||
------------------------------------------
|
------------------------------------------
|
||||||
<1> Name of the the query template in `config/scripts/`, i.e., `storedTemplate.mustache`.
|
<1> Name of the query template in `config/scripts/`, i.e., `storedTemplate.mustache`.
|
||||||
|
|
||||||
|
|
||||||
There is also a dedicated `template` endpoint, allows you to template an entire search request.
|
There is also a dedicated `template` endpoint, allows you to template an entire search request.
|
||||||
|
|
|
@ -261,7 +261,7 @@ The meaning of the stats are as follows:
|
||||||
|
|
||||||
This parameter shows how long it takes to build a Scorer for the query. A Scorer is the mechanism that
|
This parameter shows how long it takes to build a Scorer for the query. A Scorer is the mechanism that
|
||||||
iterates over matching documents generates a score per-document (e.g. how well does "foo" match the document?).
|
iterates over matching documents generates a score per-document (e.g. how well does "foo" match the document?).
|
||||||
Note, this records the time required to generate the Scorer object, not actuall score the documents. Some
|
Note, this records the time required to generate the Scorer object, not actual score the documents. Some
|
||||||
queries have faster or slower initialization of the Scorer, depending on optimizations, complexity, etc.
|
queries have faster or slower initialization of the Scorer, depending on optimizations, complexity, etc.
|
||||||
{empty} +
|
{empty} +
|
||||||
{empty} +
|
{empty} +
|
||||||
|
@ -353,7 +353,7 @@ For reference, the various collector reason's are:
|
||||||
`search_min_score`::
|
`search_min_score`::
|
||||||
|
|
||||||
A collector that only returns matching documents that have a score greater than `n`. This is seen when
|
A collector that only returns matching documents that have a score greater than `n`. This is seen when
|
||||||
the top-level paramenter `min_score` has been specified.
|
the top-level parameter `min_score` has been specified.
|
||||||
|
|
||||||
`search_multi`::
|
`search_multi`::
|
||||||
|
|
||||||
|
|
|
@ -148,14 +148,14 @@ nested level these can also be returned via the `fields` feature.
|
||||||
|
|
||||||
An important default is that the `_source` returned in hits inside `inner_hits` is relative to the `_nested` metadata.
|
An important default is that the `_source` returned in hits inside `inner_hits` is relative to the `_nested` metadata.
|
||||||
So in the above example only the comment part is returned per nested hit and not the entire source of the top level
|
So in the above example only the comment part is returned per nested hit and not the entire source of the top level
|
||||||
document that contained the the comment.
|
document that contained the comment.
|
||||||
|
|
||||||
[[hierarchical-nested-inner-hits]]
|
[[hierarchical-nested-inner-hits]]
|
||||||
==== Hierarchical levels of nested object fields and inner hits.
|
==== Hierarchical levels of nested object fields and inner hits.
|
||||||
|
|
||||||
If a mapping has multiple levels of hierarchical nested object fields each level can be accessed via dot notated path.
|
If a mapping has multiple levels of hierarchical nested object fields each level can be accessed via dot notated path.
|
||||||
For example if there is a `comments` nested field that contains a `votes` nested field and votes should directly be returned
|
For example if there is a `comments` nested field that contains a `votes` nested field and votes should directly be returned
|
||||||
with the the root hits then the following path can be defined:
|
with the root hits then the following path can be defined:
|
||||||
|
|
||||||
[source,js]
|
[source,js]
|
||||||
--------------------------------------------------
|
--------------------------------------------------
|
||||||
|
|
|
@ -236,7 +236,7 @@ GET /_search/template
|
||||||
}
|
}
|
||||||
------------------------------------------
|
------------------------------------------
|
||||||
|
|
||||||
<1> Name of the the query template in `config/scripts/`, i.e., `storedTemplate.mustache`.
|
<1> Name of the query template in `config/scripts/`, i.e., `storedTemplate.mustache`.
|
||||||
|
|
||||||
You can also register search templates by storing it in the elasticsearch cluster in a special index named `.scripts`.
|
You can also register search templates by storing it in the elasticsearch cluster in a special index named `.scripts`.
|
||||||
There are REST APIs to manage these indexed templates.
|
There are REST APIs to manage these indexed templates.
|
||||||
|
@ -297,7 +297,7 @@ GET /_search/template
|
||||||
}
|
}
|
||||||
}
|
}
|
||||||
------------------------------------------
|
------------------------------------------
|
||||||
<1> Name of the the query template stored in the `.scripts` index.
|
<1> Name of the query template stored in the `.scripts` index.
|
||||||
|
|
||||||
[float]
|
[float]
|
||||||
==== Validating templates
|
==== Validating templates
|
||||||
|
|
|
@ -111,9 +111,9 @@ doesn't take the query into account that is part of request.
|
||||||
|
|
||||||
`string_distance`::
|
`string_distance`::
|
||||||
Which string distance implementation to use for comparing how similar
|
Which string distance implementation to use for comparing how similar
|
||||||
suggested terms are. Five possible values can be specfied:
|
suggested terms are. Five possible values can be specified:
|
||||||
`internal` - The default based on damerau_levenshtein but highly optimized
|
`internal` - The default based on damerau_levenshtein but highly optimized
|
||||||
for comparing string distancee for terms inside the index.
|
for comparing string distance for terms inside the index.
|
||||||
`damerau_levenshtein` - String distance algorithm based on
|
`damerau_levenshtein` - String distance algorithm based on
|
||||||
Damerau-Levenshtein algorithm.
|
Damerau-Levenshtein algorithm.
|
||||||
`levenstein` - String distance algorithm based on Levenstein edit distance
|
`levenstein` - String distance algorithm based on Levenstein edit distance
|
||||||
|
|
|
@ -75,7 +75,7 @@ sudo service elasticsearch start
|
||||||
[float]
|
[float]
|
||||||
==== Using systemd
|
==== Using systemd
|
||||||
|
|
||||||
Distributions like Debian Jessie, Ubuntu 14, and many of the SUSE derivitives do not use the `chkconfig` tool to register services, but rather `systemd` and its command `/bin/systemctl` to start and stop services (at least in newer versions, otherwise use the `chkconfig` commands above). The configuration file is also placed at `/etc/sysconfig/elasticsearch` if the system is rpm based and `/etc/default/elasticsearch` if it is deb. After installing the RPM, you have to change the systemd configuration and then start up elasticsearch
|
Distributions like Debian Jessie, Ubuntu 14, and many of the SUSE derivatives do not use the `chkconfig` tool to register services, but rather `systemd` and its command `/bin/systemctl` to start and stop services (at least in newer versions, otherwise use the `chkconfig` commands above). The configuration file is also placed at `/etc/sysconfig/elasticsearch` if the system is rpm based and `/etc/default/elasticsearch` if it is deb. After installing the RPM, you have to change the systemd configuration and then start up elasticsearch
|
||||||
|
|
||||||
[source,sh]
|
[source,sh]
|
||||||
--------------------------------------------------
|
--------------------------------------------------
|
||||||
|
|
|
@ -133,7 +133,7 @@ request:
|
||||||
curl http://localhost:9200/_nodes/process?pretty
|
curl http://localhost:9200/_nodes/process?pretty
|
||||||
--------------
|
--------------
|
||||||
|
|
||||||
If you see that `mlockall` is `false`, then it means that the the `mlockall`
|
If you see that `mlockall` is `false`, then it means that the `mlockall`
|
||||||
request has failed. The most probable reason, on Linux/Unix systems, is that
|
request has failed. The most probable reason, on Linux/Unix systems, is that
|
||||||
the user running Elasticsearch doesn't have permission to lock memory. This can
|
the user running Elasticsearch doesn't have permission to lock memory. This can
|
||||||
be granted by running `ulimit -l unlimited` as `root` before starting Elasticsearch.
|
be granted by running `ulimit -l unlimited` as `root` before starting Elasticsearch.
|
||||||
|
|
Loading…
Reference in New Issue