The recent work to benchmark ES|QL has benefitted greatly from the addition of the esql operator in https://github.com/elastic/rally/pull/1791. However, the benchmarks that make use of the enrich command need enrich indices set up, and this is currently achieved using a complex set of multiple raw operations:
Create enrich source index and ingest data
Delete previous enrich policy
Create new enrich policy
Execute the enrich policy
Use the enrich policy within an ingestion pipeline
The three steps for delete/create/execute of the enrich policy can be combined into a single enrich policy operation. This operation should combine the following raw steps:
{
"name": "setup-enrich-nyc_vendors",
"operation-type": "enrich_policy",
"policy_name": "nyc_vendors",
"delete": true, // default to true
"enrich_type": "match", // could be default to 'match'
"indices": "nyc_vendors", // could be default to value of 'policy_name'
"match_field": "id",
"enrich_fields": [ "name" ]
}
Multiple policies
An interesting alternative might be to allow the definition of multiple policies with a more flexible syntax:
One advantage of this syntax is the body of the enrich policy matches exactly the body of the create part of the enrich policy REST request, so we could just pass through that part of the json object.
The recent work to benchmark
ES|QL
has benefitted greatly from the addition of theesql
operator in https://github.com/elastic/rally/pull/1791. However, the benchmarks that make use of theenrich
command need enrich indices set up, and this is currently achieved using a complex set of multipleraw
operations:The three steps for delete/create/execute of the enrich policy can be combined into a single
enrich
policy operation. This operation should combine the following raw steps:Delete
Create
Execute
Combined
The above operations could be combined into one:
Multiple policies
An interesting alternative might be to allow the definition of multiple policies with a more flexible syntax:
One advantage of this syntax is the body of the enrich policy matches exactly the body of the
create
part of the enrich policy REST request, so we could just pass through that part of the json object.