TSDB index.routing_path setting improvement

[weizijun]

here are some improvement about TSDB index.routing_path settings:

1. support custom routing search:

• if user set only one field routing_path, it can search with: GET xxx/_search?routing=xx
• if user set multi fields in routing_path, it can search with: GET xxx/_search?routing=filed1:xxx|field2:xxx|field3:xxx
• if user set wildcard fields in routing_path, it can reject the routing parameter

2.ignore object type check:

• It will cause that some mistake. e.g: {"foo":{"bar":"xxx"}} , index.routing_path : "foo.*" is ok, but index.routing_path : "foo*" is not ok.
• I think we can ignore object type, because the routing_path will check the field if it has time_series_dimension parameter, as object can't set the parameter, it can ignore the object check.

3.how to deal with ''.":

• e.g index.routing_path : "foo.bar", the document is ok:

{
  "foo": {
    "bar": "xxx"
  }
}

but the document is failed:

{
  "foo.bar" : "xxx"
}

This can be confusing for the user, because the user configures index.routing_path : "foo.*", but the field foo.bar is failed, user must set index.routing_path : "foo\.*" to support field foo.bar.

The reason why foo.bar is failed, is because of the Xcontent filter rule. May be it can be improved.

[weizijun]

hi, @imotov , @nik9000 , can you take a look the improvement?

[elasticmachine]

Pinging @elastic/es-analytics-geo (Team:Analytics)

[nik9000]

hi, @imotov , @nik9000 , can you take a look the improvement?

Sorry for the delay getting back to you. I was pretty deeply in #82633. Which, ironically, reworks the handling routing generation.

I've thought a little about your first point. I was thinking that it should be possible to recognize sets of queries and use something like CoordinatorRewriteContext to lock to the correct shards. I'd sort of hoped users wouldn't need work without routing at all in tsdb. But I really haven't thought it all the way through.

For the second one - it sounds like the error message is just bad. I do like the paranoia of rejecting the matching object in the routing generation code. Maybe we can just improve the error message there?

About dots in names - yeah. I don't really want to change how x content filtering works. And I kind of want to be able to say that routing_path is just xcontent filtering that only accepts strings. I wonder if this is just something we can document?