Signed-off-by: Andriy Redko andriy.redko@aiven.io

Description

Allows to use experimental Apache Lucene low-level API which allows to parallelize execution of the search across segment.

• Implement multi-collectors query context (possibly, needs API change to use CollectorManagers instead)

• Implement profilers support

  The query profiling is supported but it has some limitations and differences with respect to naming. The profilers capture the time each collection type has taken and return it as the cumulative summary. The fact that segments may have been searched concurrently is not reflected (it requires significant overhauling of the profiling implementation), so the "real" perceived time may be smaller then profilers will report. The collector names are replaced with collector manager names (fe MinimumScoreCollector vs MinimumCollectorManager).

  To compare, here is the usual search profile

  "collector" : [
     {
       "name" : "MinimumScoreCollector",
       "reason" : "search_min_score",
       "time_in_nanos" : 4702942,
       "children" : [
         {
           "name" : "SimpleTopScoreDocCollector",
           "reason" : "search_top_hits",
           "time_in_nanos" : 3450252
         }
       ]
     }
   ]
  

  vs the one where concurrent segment search is enabled

  "collector" : [
    {
      "name" : "MinimumCollectorManager",
      "reason" : "search_min_score",
      "time_in_nanos" : 74827,
      "children" : [
        {
          "name" : "SimpleTopDocsCollectorManager",
          "reason" : "search_top_hits",
          "time_in_nanos" : 98044
        }
      ]
    }
  ]
  

  Additionally, since TopDocs are merged, the query's shardIndex field is also populated, usual search profile has it set to -1, for example:

  "query" : [
    {
      "type" : "ConstantScoreQuery",
      "description" : "ConstantScore(SearchAfterSortedDocQuery(sort=<int: \"rank\">, afterDoc=doc=287 score=NaN shardIndex=-1 fields=[-2062713761]))",
      "time_in_nanos" : 1009712,
      ...
    }
  ]
  

  vs the one where concurrent segment search is enabled

  "query" : [
    {
      "type" : "ConstantScoreQuery",
      "description" : "ConstantScore(SearchAfterSortedDocQuery(sort=<int: \"rank\">, afterDoc=doc=287 score=NaN shardIndex=1 fields=[-2062713761]))",
      "time_in_nanos" : 35667,
        ....
    }
  ]
  

• Implement early termination and timeout support

  The forced early termination is simulated (without abrupt search termination) using Apache Lucene normal collection termination mechanism. The number of results is reduced to the desired one (if necessary) at the post search step. Essentially, to summarize, when early termination is requested and concurrent segment search is enabled, be the engine is going to do more work and (very likely) come up with more search hits than have been asked.

  If query finished by timeout, no results are being returned, even if returning partial results is acceptable. The reason for that exception propagation mechanism does not leave a chance for reducers to execute.

• Add benchmarks suite

Splitting into subtasks:

• Extract changes related to profiler support (Concurrent Searching (Experimental): modify profiling implementation to support concurrent data collection #1673)
• Extract changes related to query context support
• Move the concurrent search implementation to sandbox

Future Enhancements:

• Concurrent Searching: Support Aggregations #2585
• Concurrent Searching: Support Early Termination #2586

Issues Resolved

Fixes #1286

Check List

• New functionality includes testing.
  • All tests pass
• New functionality has been documented.
  • New functionality has javadoc added
• Commits are signed per the DCO using --signoff

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.
For more information on following Developer Certificate of Origin and signing off your commits, please check here.