A search query returns dimension values that match the search specification.

There are several main parts to a search query:

The format of the result is:

  1. [
  2.   {
  3.     "timestamp": "2013-01-01T00:00:00.000Z",
  4.     "result": [
  5.       {
  6.         "dimension": "dim1",
  7.         "value": "Ke$ha",
  8.         "count": 3
  9.       {
  10.         "dimension": "dim2",
  11.         "value": "Ke$haForPresident",
  13.       }
  14.     ]
  15.   },
  16.   {
  17.     "timestamp": "2013-01-02T00:00:00.000Z",
  18.     "result": [
  19.       {
  20.         "dimension": "dim1",
  21.         "value": "SomethingThatContainsKe",
  22.         "count": 1
  23.       },
  24.       {
  25.         "value": "SomethingElseThatContainsKe",
  26.         "count": 2
  27.       }
  29.   }
  30. ]

Strategies

  • “useIndexes” strategy, the default, first categorizes search dimensions into two groups according to their support for bitmap indexes. And then, it applies index-only and cursor-based execution plans to the group of dimensions supporting bitmaps and others, respectively. The index-only plan uses only indexes for search query processing. For each dimension, it reads the bitmap index for each dimension value, evaluates the search predicate, and finally checks the time interval and filter predicates. For the cursor-based execution plan, please refer to the “cursorOnly” strategy. The index-only plan shows low performance for the search dimensions of large cardinality which means most values of search dimensions are unique.

  • “cursorOnly” strategy generates a cursor-based execution plan. This plan creates a cursor which reads a row from a queryableIndexSegment, and then evaluates search predicates. If some filters support bitmap indexes, the cursor can read only the rows which satisfy those filters, thereby saving I/O cost. However, it might be slow with filters of low selectivity.

  • “auto” strategy uses a cost-based planner for choosing an optimal search strategy. It estimates the cost of index-only and cursor-based execution plans, and chooses the optimal one. Currently, it is not enabled by default due to the overhead of cost estimation.

The following query context parameters apply:

If any part of a dimension value contains the value specified in this search query spec, regardless of case, a “match” occurs. The grammar is:

If any part of a dimension value contains all of the values specified in this search query spec, regardless of case by default, a “match” occurs. The grammar is:

  1. {
  2.   "type" : "fragment",
  3.   "case_sensitive" : false,
  4.   "values" : ["fragment1", "fragment2"]
  5. }

If any part of a dimension value contains the pattern specified in this search query spec, a “match” occurs. The grammar is:

  1. {
  2.   "type"  : "regex",
  3. }