- Elasticsearch Guide: other versions:
- Getting Started
- Setup Elasticsearch
- Breaking changes
- Breaking changes in 5.4
- Breaking changes in 5.3
- Breaking changes in 5.2
- Breaking changes in 5.1
- Breaking changes in 5.0
- Search and Query DSL changes
- Mapping changes
- Percolator changes
- Suggester changes
- Index APIs changes
- Document API changes
- Settings changes
- Allocation changes
- HTTP changes
- REST API changes
- CAT API changes
- Java API changes
- Packaging
- Plugin changes
- Filesystem related changes
- Path to data on disk
- Aggregation changes
- Script related changes
- API Conventions
- Document APIs
- Search APIs
- Aggregations
- Metrics Aggregations
- Avg Aggregation
- Cardinality Aggregation
- Extended Stats Aggregation
- Geo Bounds Aggregation
- Geo Centroid Aggregation
- Max Aggregation
- Min Aggregation
- Percentiles Aggregation
- Percentile Ranks Aggregation
- Scripted Metric Aggregation
- Stats Aggregation
- Sum Aggregation
- Top hits Aggregation
- Value Count Aggregation
- Bucket Aggregations
- Adjacency Matrix Aggregation
- Children Aggregation
- Date Histogram Aggregation
- Date Range Aggregation
- Diversified Sampler Aggregation
- Filter Aggregation
- Filters Aggregation
- Geo Distance Aggregation
- GeoHash grid Aggregation
- Global Aggregation
- Histogram Aggregation
- IP Range Aggregation
- Missing Aggregation
- Nested Aggregation
- Range Aggregation
- Reverse nested Aggregation
- Sampler Aggregation
- Significant Terms Aggregation
- Terms Aggregation
- Pipeline Aggregations
- Avg Bucket Aggregation
- Derivative Aggregation
- Max Bucket Aggregation
- Min Bucket Aggregation
- Sum Bucket Aggregation
- Stats Bucket Aggregation
- Extended Stats Bucket Aggregation
- Percentiles Bucket Aggregation
- Moving Average Aggregation
- Cumulative Sum Aggregation
- Bucket Script Aggregation
- Bucket Selector Aggregation
- Serial Differencing Aggregation
- Matrix Aggregations
- Caching heavy aggregations
- Returning only aggregation results
- Aggregation Metadata
- Returning the type of the aggregation
- Metrics Aggregations
- Indices APIs
- Create Index
- Delete Index
- Get Index
- Indices Exists
- Open / Close Index API
- Shrink Index
- Rollover Index
- Put Mapping
- Get Mapping
- Get Field Mapping
- Types Exists
- Index Aliases
- Update Indices Settings
- Get Settings
- Analyze
- Index Templates
- Shadow replica indices
- Indices Stats
- Indices Segments
- Indices Recovery
- Indices Shard Stores
- Clear Cache
- Flush
- Refresh
- Force Merge
- cat APIs
- Cluster APIs
- Query DSL
- Mapping
- Analysis
- Anatomy of an analyzer
- Testing analyzers
- Analyzers
- Normalizers
- Tokenizers
- Token Filters
- Standard Token Filter
- ASCII Folding Token Filter
- Flatten Graph Token Filter
- Length Token Filter
- Lowercase Token Filter
- Uppercase Token Filter
- NGram Token Filter
- Edge NGram Token Filter
- Porter Stem Token Filter
- Shingle Token Filter
- Stop Token Filter
- Word Delimiter Token Filter
- Word Delimiter Graph Token Filter
- Stemmer Token Filter
- Stemmer Override Token Filter
- Keyword Marker Token Filter
- Keyword Repeat Token Filter
- KStem Token Filter
- Snowball Token Filter
- Phonetic Token Filter
- Synonym Token Filter
- Synonym Graph Token Filter
- Compound Word Token Filters
- Reverse Token Filter
- Elision Token Filter
- Truncate Token Filter
- Unique Token Filter
- Pattern Capture Token Filter
- Pattern Replace Token Filter
- Trim Token Filter
- Limit Token Count Token Filter
- Hunspell Token Filter
- Common Grams Token Filter
- Normalization Token Filter
- CJK Width Token Filter
- CJK Bigram Token Filter
- Delimited Payload Token Filter
- Keep Words Token Filter
- Keep Types Token Filter
- Classic Token Filter
- Apostrophe Token Filter
- Decimal Digit Token Filter
- Fingerprint Token Filter
- Minhash Token Filter
- Character Filters
- Modules
- Index Modules
- Ingest Node
- Pipeline Definition
- Ingest APIs
- Accessing Data in Pipelines
- Handling Failures in Pipelines
- Processors
- Append Processor
- Convert Processor
- Date Processor
- Date Index Name Processor
- Fail Processor
- Foreach Processor
- Grok Processor
- Gsub Processor
- Join Processor
- JSON Processor
- KV Processor
- Lowercase Processor
- Remove Processor
- Rename Processor
- Script Processor
- Set Processor
- Split Processor
- Sort Processor
- Trim Processor
- Uppercase Processor
- Dot Expander Processor
- How To
- Testing
- Glossary of terms
- Release Notes
- 5.4.3 Release Notes
- 5.4.2 Release Notes
- 5.4.1 Release Notes
- 5.4.0 Release Notes
- 5.3.3 Release Notes
- 5.3.2 Release Notes
- 5.3.1 Release Notes
- 5.3.0 Release Notes
- 5.2.2 Release Notes
- 5.2.1 Release Notes
- 5.2.0 Release Notes
- 5.1.2 Release Notes
- 5.1.1 Release Notes
- 5.1.0 Release Notes
- 5.0.2 Release Notes
- 5.0.1 Release Notes
- 5.0.0 Combined Release Notes
- 5.0.0 GA Release Notes
- 5.0.0-rc1 Release Notes
- 5.0.0-beta1 Release Notes
- 5.0.0-alpha5 Release Notes
- 5.0.0-alpha4 Release Notes
- 5.0.0-alpha3 Release Notes
- 5.0.0-alpha2 Release Notes
- 5.0.0-alpha1 Release Notes
- 5.0.0-alpha1 Release Notes (Changes previously released in 2.x)
- Painless API Reference
WARNING: Version 5.4 of Elasticsearch has passed its EOL date.
This documentation is no longer being maintained and may be removed. If you are running this version, we strongly advise you to upgrade. For the latest information, see the current release documentation.
How to use scripts
editHow to use scripts
editWherever scripting is supported in the Elasticsearch API, the syntax follows the same pattern:
The language the script is written in, which defaults to |
|
The script itself which may be specified as |
|
Any named parameters that should be passed into the script. |
For example, the following script is used in a search request to return a scripted field:
PUT my_index/my_type/1 { "my_field": 5 } GET my_index/_search { "script_fields": { "my_doubled_field": { "script": { "lang": "expression", "inline": "doc['my_field'] * multiplier", "params": { "multiplier": 2 } } } } }
Script Parameters
edit-
lang
-
Specifies the language the script is written in. Defaults to
painless
but may be set to any of languages listed in Scripting. The default language may be changed in theelasticsearch.yml
config file by settingscript.default_lang
to the appropriate language. -
inline
,stored
,file
-
Specifies the source of the script. An
inline
script is specifiedinline
as in the example above, astored
script is specifiedstored
and is retrieved from the cluster state (see Stored Scripts), and afile
script is retrieved from a file in theconfig/scripts
directory (see File Scripts).While languages like
expression
andpainless
can be used out of the box as inline or stored scripts, other languages likegroovy
can only be specified asfile
unless you first adjust the default scripting security settings. -
params
- Specifies any named parameters that are passed into the script as variables.
The first time Elasticsearch sees a new script, it compiles it and stores the compiled version in a cache. Compilation can be a heavy process.
If you need to pass variables into the script, you should pass them in as
named params
instead of hard-coding values into the script itself. For
example, if you want to be able to multiply a field value by different
multipliers, don’t hard-code the multiplier into the script:
"inline": "doc['my_field'] * 2"
Instead, pass it in as a named parameter:
"inline": "doc['my_field'] * multiplier", "params": { "multiplier": 2 }
The first version has to be recompiled every time the multiplier changes. The second version is only compiled once.
If you compile too many unique scripts within a small amount of time,
Elasticsearch will reject the new dynamic scripts with a
circuit_breaking_exception
error. By default, up to 15 inline scripts per
minute will be compiled. You can change this setting dynamically by setting
script.max_compilations_per_minute
.
File-based Scripts
editTo increase security, non-sandboxed languages can only be specified in script
files stored on every node in the cluster. File scripts must be saved in the
scripts
directory whose default location depends on whether you use the
zip
/tar.gz
($ES_HOME/config/scripts/
),
RPM, or Debian package. The default may be
changed with the path.scripts
setting.
The languages which are assumed to be safe by default are: painless
,
expression
, and mustache
(used for search and query templates).
Any files placed in the scripts
directory will be compiled automatically
when the node starts up and then every 60 seconds thereafter.
The file should be named as follows: {script-name}.{lang}
. For instance,
the following example creates a Groovy script called calculate-score
:
echo "Math.log(_score * 2) + params.my_modifier" > config/scripts/calculate_score.painless
This script can be used as follows:
GET my_index/_search { "query": { "script": { "script": { "lang": "painless", "file": "calculate_score", "params": { "my_modifier": 2 } } } } }
The language of the script, which should correspond with the script file suffix. |
|
The name of the script, which should be the name of the file. |
The script
directory may contain sub-directories, in which case the
hierarchy of directories is flattened and concatenated with underscores. A
script in group1/group2/my_script.groovy
should use group1_group2_myscript
as the file
name.
Automatic script reloading
editThe scripts
directory will be rescanned every 60s
(configurable with the
resource.reload.interval
setting) and new, changed, or removed scripts will
be compiled, updated, or deleted from the script cache.
Script reloading can be completely disabled by setting
script.auto_reload_enabled
to false
.
Stored Scripts
editScripts may be stored in and retrieved from the cluster state using the
_scripts
end-point.
Deprecated Namespace
editThe namespace for stored scripts using both lang
and id
as a unique
identifier has been deprecated. The new namespace for stored scripts will
only use id
. Stored scripts with the same id
, but different lang
's
will no longer be allowed in 6.0. To comply with the new namespace for
stored scripts, existing stored scripts should be deleted and put again.
Any scripts that share an id
but have different `lang`s will need to
be re-named. For example, take the following:
"id": "example", "lang": "painless" "id": "example", "lang": "expressions"
The above scripts will conflict under the new namespace since the id’s are
the same. At least one will have to be re-named to comply with the new
namespace of only id
.
As a final caveat, stored search templates and stored scripts share
the same namespace, so if a search template has the same id
as a
stored script, one of the two will have to be re-named as well using
delete and put requests.
Request Examples
editThe following are examples of using a stored script that lives at
/_scripts/{id}
.
First, create the script called calculate-score
in the cluster state:
POST _scripts/calculate-score { "script": { "lang": "painless", "code": "Math.log(_score * 2) + params.my_modifier" } }
This same script can be retrieved with:
GET _scripts/calculate-score
Stored scripts can be used by specifying the stored
parameters as follows:
GET _search { "query": { "script": { "script": { "stored": "calculate-score", "params": { "my_modifier": 2 } } } } }
And deleted with:
DELETE _scripts/calculate-score
Script Caching
editAll scripts are cached by default so that they only need to be recompiled
when updates occur. File scripts keep a static cache and will always reside
in memory. Both inline and stored scripts are stored in a cache that can evict
residing scripts. By default, scripts do not have a time-based expiration, but
you can change this behavior by using the script.cache.expire
setting.
You can configure the size of this cache by using the script.cache.max_size
setting.
By default, the cache size is 100
.
The size of stored scripts is limited to 65,535 bytes. This can be
changed by setting script.max_size_in_bytes
setting to increase that soft
limit, but if scripts are really large then alternatives like
native scripts should be considered instead.
On this page