Do query results impact elasticsearch phrase suggestions? - elasticsearch

I'd like to know whether Elasticsearch users query results to populate phrase suggestions for direct generator or not?
Or it simply picks tokens from given index?
My queries are based on some permission sets.
So for instance, that'd be my query:
{
"size" : 0,
"query" : {
"filtered" : {
"query" : {
"match_all" : {}
},
"filter" : {
"bool" : {
"must" : [{
"terms" : {
"Permissions" : ["permission1", "permission2", "permission3"
]
}
}
]
}
}
}
},
"suggest" : {
"DidYouMean" : {
"text" : "{{SearchPhrase}}",
"phrase" : {
"field" : "_all",
"analyzer" : "simple",
"size" : 1,
"real_word_error_likelihood" : 0.96,
"max_errors" : 5,
"gram_size" : 3,
"direct_generator" : [{
"field" : "_all",
"suggest_mode" : "popular",
"min_word_length" : 3
}
]
}
}
}
}
How would I ensure that direct generator creates suggestions and doesn't violate my permissions clause?
Is this even possible?

The term suggester and phrase suggester feeds on the tokens for generating suggest results. The query does not affect the suggest results. The suggester directly works on the reverse index and get the tokens from them. So its scope is global and never the query

Related

Different results with the same keywords in elasticsearch query

I have a question to understand the search logic. I have an Elasticsearch 5.4 instance and make a query_string query. The default operator is OR. Other settings are not defined.
Now I search for
dog house
and get 10,500 results. Then I search for
house dog
and get only 6,200 results. That's a bit curious for me.
That's my query:
{
"query" : {
"bool" : {
"must" : [
{
"query_string" : {
"query" : "dog house~",
"default_operator" : "OR",
"fuzziness" : "AUTO"
}
},
{
"term" : {
"client" : {
"value" : "MyClient",
"boost" : 1
}
}
},
{
"range" : {
"dateCreate" : {
"gte" : "2000-01-01T00:00:00+0200",
"lte" : "2000-12-31T23:59:59+0200"
}
}
}
]
}
},
"size" : 2,
"from" : 0,
"sort" : [
{
"_score" : {
"order" : "desc"
}
}
],
"collapse" : {
"field" : "title.keyword"
}
}
It is because of the ~ operator. If you try removing it and running the query again the number should be the same if the query is dog house or house dog.
Even the number of results should be the same if you run dog house~ or house~ dog, but the number will change if you change the ~ from house to dog.
If you want both words to specify the transpositions distance of 1 that the fuzzy search can match you can try with house~ dog~ and then the results will be the same if you change the order.

Elasticsearch slow results with IN query and Scoring

I have text document data (500k approximately) saved in elasticsearch where the document text is mapped with it's corresponding document number.
I am trying to fetch results in batches for "Sample Text" in particular set of document numbers (300k appoximately) with scoring and i am facing extreme slowness in the result.
Here is the the Mapping
PUT my_index
{
"mappings" : {
"doc_repo" : {
"properties" : {
"doc_number" : {
"type" : "integer"
},
"document" : {
"type" : "string",
"term_vector" : "with_positions_offsets_payloads"
}
}
}
}
}
Here is the request query
{
"query" : {
"bool" : {
"must" : [
{
"terms" : {
"document" : [
"sample text"
]
}
},
{
"terms" : {
"doc_number" : [1,2,3....,300K] //ArrayOf_300K_DocNumbers
}
}
]
}
},
"fields" : [
"doc_number"
],
"size" : 500,
"from" : 0
}
I Tried fetching result in two other ways
Result without scoring in particular set of document numbers(i used filtering for this)
Result with scoring but without any particular set of document numbers (in batches)
Both of these were pretty quick, but problem comes when i am trying achieve both.
Do i need to change mapping or search query or any other ways to achieve this.
Thanks in advance.
Issue was specifically with elasticsearch 2.X, Upgrading elasticsearch solves the issue.

elasticsearch percolator filter fails

I'm using a document query against a percolator that works ok. When I try to filter the percolator queries against which document percolate using queries ids, it doesn't return any result. For example:
{
"doc" : {
"text" : "This is the text within my document"
},
"highlight" : {
"order" : "score",
"pre_tags" : ["<example>"],
"post_tags" : ["</example>"],
"fields" : {
"text" : { "number_of_fragments" : 0 }
}
},
"filter":{"ids":{"values":[11,15]}}
,
"size" : 100
}
I know for sure that those ids are correct, but allways obtain "matches" : [ ]. When I don't use filter, ES retrieves correct matches.
Thanks for your help.
I think I've solved it. It seems that the filter only works on the "metadata" fields, meaning that you have to add customized fields to the queries indexed in the percolator in order to use them to filter when you need.
Using my previous example, I would have to index in percolator queries like:
{
"query" : {
"match_phrase" : {
"text" : "document"
}
},
"id" : 11
}
Adding "manually" a redundant id field in order to use it later as filter reference.
At percolation time, you have to use something like:
{
"doc" : {
"text" : "This is the text within my document"
},
"filter":{"match":{"id":11}},
"highlight" : {
"order" : "score",
"pre_tags" : ["<example>"],
"post_tags" : ["</example>"],
"fields" : {
"text" : { "number_of_fragments" : 0 }
}
},
"size" : 100
}
In order to use only that percolator query. Complementary information can be found here.

Elasticsearch, get average document length

Is there any better way in elasticsearch (other than issuing a match all query and manually averaging over the length of all returned documents) to get the average document length for a specific index?
The _size mapping field, if enabled, should give you the size of each document for free. Combining this with the avg aggregation should get you what you want. Something like:
{
"query" : {"match_all" : {}},
"aggs" : {"avg_size" : {"avg" : {"terms" : {"field" : "_size"}}}}
}
I have used this code (I have the _source enabled)
{
"query" : {"match_all" : {}},
"aggs":{
"avg_length" : { "avg" : { "script" : "_source.toString().length()"}}
}
}
Well, the chars .. .if the string are UTF-8 to get the bytes:
{
"query" : {"match_all" : {}},
"aggs":{
"avg_length" : { "avg" : { "script" : "_source.toString().getBytes(\"UTF-8\").length"}}
}
}
Shot in the dark, but facets or aggregations combined with a script might do it.
{
...,
"aggs" : {
"avg_length" : { "avg" : { "script" : "doc['_all'].length" } }
}
}
In ElasticSearch 6.2 you should just use the following line (no need to add 'terms'):
"aggs" :
{"avg_size" :
{"avg" :
{"field" : "_size"}}}
See details here: https://www.elastic.co/guide/en/elasticsearch/reference/current/search-aggregations-metrics-avg-aggregation.html

ElasticSearch using wildcard and term queries

I'm new using Elastic Search, and i never used Lucene too.
I build this query:
{
"query" : {
"wildcard" : { "referer" : "*.domain.com*" }
},
"filter" : {
"query" : {
"term" : { "first" : "1" }
}
},
"facets" : {
"site_id" : {
"terms" : {
"field" : "site",
"size" : "70"
}
}
}
}
The wildcard is working great, but the term filter was ignored, what i did wrong?
I need to filter the results with both wildcard and term
Thanks!
Assuming what you are trying to do is applying the filter on the wildcard query results,
you can use a FilteredQuery. However, your case might fit better for a filter.
You use a query filter. Instead of that you may directly use a TermFilter in a FilteredQuery rather than making a filter out of a TermQuery. TermFilter should be faster as it directly uses the TermsEnum.
Note that results of Filters are cached in a FilterCache and Filters are faster because they do not do any scoring of documents. In your case, even though the filter part of the FilteredQuery will work fast, but the wildcard query will be unnecessarily do scoring. You may try to use an AND Filter to club both queryfilter(wildcard query) and term filter instead of a FilteredQuery.
To make just the filter work as required by you, try something like below. (Not tried myself)
{
"filtered" : {
"query" : {
"wildcard" : { "referer" : "*.domain.com*" }
},
"filter" : {
"term" : { "first" : "1" }
}
},
"facets" : {
"site_id" : {
"terms" : {
"field" : "site",
"size" : "70"
}
}
}
}

Resources