Context

With regards to the issue  MSEARCH-492 - Getting issue details... STATUS prototype workarounds have been accomplished, hence two mods researched:

1) nested mappings variations on random data sets

2) nested mapping on actual production like data with corresponding scale (5M records) 

Results and conclusions are outlined correspondingly.

Preliminary decision is to proceed with alter indexing to incorporate nested object mapping for items and ones call number entries.

Also, needs to adopt same solution for similar bunch of problems (e.g.: filtering by status of items).

Environment and precondition

Tested on:

1) local machine, ES v8+

2) Rancher cluster with OpenSearch 2+ (production like environment with 5M data set, modules specified, mod-search separate branch for prototyping)

Results

For nested object mappings tested on random data set 

For 5 million of instance records nested queries and nested aggregation queries are performed within a reasonable time (nested queries: not more than 1.5 seconds, nested aggregation queries - not more than 2 seconds)

With introduction of nested objects size of index of instances increased less than 15% for one level of nested objects.

Conclusions

According to prototype results it is considered as a reasonable option to proceed with introduction of nested object mappings within instance index to cover scope of similar issues of searching by multiple fields of inner objects within indexed documents.