{"id":1727,"date":"2020-10-02T07:18:17","date_gmt":"2020-10-02T14:18:17","guid":{"rendered":"https:\/\/www.couchbase.com\/blog\/full-text-search-tips-for-query-performance\/"},"modified":"2020-10-02T07:18:17","modified_gmt":"2020-10-02T14:18:17","slug":"full-text-search-tips-for-query-performance","status":"publish","type":"post","link":"https:\/\/www.couchbase.com\/blog\/full-text-search-tips-for-query-performance\/","title":{"rendered":"Full-Text Search – 5 Tips To Improve Your Query Performance"},"content":{"rendered":"\n

Tuning the search query performance is a very important aspect of Full-Text Search<\/a> as it helps business-critical applications in meeting the SLA requirements of latency and throughput. Without much preamble, let me share a few useful recommendations for troubleshooting your search performance. All of these suggestions are agnostic of any hardware configurations, cluster topologies, and are applicable to most generic search use cases.<\/span><\/p>\n\n\n\n

\u00a0<\/p>\n\n\n\n

Search As Few Fields As Possible<\/b><\/h3>\n\n\n\n

\u00a0<\/p>\n\n\n\n

This is particularly applicable to certain types of composite queries<\/a> where the user tries to search a common search query text across multiple indexed fields.<\/span><\/p>\n\n\n\n

Let us delve into a sample query.<\/span><\/p>\n\n\n

[crayon lang=”default” decode=”true”]”query”: {
\n “conjuncts”: [
\n {
\n “field”: “UserName”,
\n “match”: “searchText”,
\n “fuzziness”: 1<\/p>\n

},
\n {
\n “field”: “Department.Name”,
\n “match”: “searchText”,
\n “fuzziness”: 1
\n },
\n {
\n “field”: “SecondName”,
\n “match”: “searchText”,
\n “fuzziness”: 1
\n },
\n {
\n “field”: “ConsumerName”,
\n “match”: “searchText”
\n “fuzziness”: 1
\n }
\n]}
\n[\/crayon]<\/p>\n\n\n\n

\u00a0<\/p>\n\n\n\n

If we notice – there are 4 match query clauses in the conjunct composite query all of which have the same search text. This is highly inefficient, as in the background the search system has to graze a lot of data indexed across different fields for the same search text. This overhead is worsened by the multitude of runtime query structures created and garbage collected across fields.<\/span><\/p>\n\n\n\n

FTS has a feature to support this in a very efficient way. It lets the users index multiple source document fields against a generic configurable field. Once the user does this during the index definition time, then they could execute searches against that single common field.<\/span><\/p>\n\n\n\n

To avail of this feature, the user needs to enable the <\/a><\/span>`_all`<\/i><\/b> option against all those multiple fields in the field mapping during the indexing.<\/span><\/p>\n\n\n\n

\"Diagram<\/p>\n\n\n\n

With this, all these field contents will also get indexed against the default _all<\/strong><\/em> field in the index. This has an additional storage aspect for the index size.<\/span><\/p>\n\n\n\n

Now the user should be able to issue queries without explicitly specifying the target field.\u00a0 And whenever target fields are not specified in the query, Full-Text Search will search it against the default common field <\/span>`_all`.\u00a0<\/i><\/b><\/p>\n\n\n\n

So with the above optimization, the earlier query would become a simpler one like below,<\/span><\/p>\n\n\n

[crayon lang=”default” decode=”true”]”query”: {
\n\u00a0\u00a0“conjuncts”: [
\n\u00a0\u00a0\u00a0\u00a0{
\n\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0“match”: “searchText”
\n\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u201cfuzziness\u201d : 1,
\n\u00a0\u00a0\u00a0\u00a0}
\n]
\n}[\/crayon]<\/p>\n\n\n\n

This search query performance ought to be much lighter and faster compared to the original query.<\/span><\/p>\n\n\n\n

Note: This is applicable if there is no score boosting<\/a> used in the original query for the child clauses.<\/p>\n\n\n\n

\u00a0<\/p>\n\n\n\n

<\/h3>\n\n\n\n

<\/h3>\n\n\n\n

Specify <\/b>prefix_length<\/i><\/b> For Fuzzy Match Queries\u00a0<\/b><\/h3>\n\n\n\n

\u00a0<\/p>\n\n\n\n

Users choose fuzzy match queries<\/a> for helping against any potential spelling mistakes within the search texts. With the fuzziness factor, they would still get the intended document hits from the search system. But fuzzy users need to keep in mind that fuzzy queries are extremely resource-consuming queries. <\/span><\/p>\n\n\n\n

How<\/b> – In a sufficiently large FTS index, there will be many candidate tokens that are at a given fuzziness\/edit distance from the query text. So essentially a single fuzzy query will become a disjunct\/OR query for all the candidate tokens present in the index. This results in a high internal fan out of the rudimentary search operations which is resource cumbersome.<\/span><\/p>\n\n\n\n

Let’s check out a simpler example for the query fan-out here.<\/p>\n\n\n\n

\"word-tree<\/p>\n\n\n\n

A match fuzzy query with a fuzziness of 1 for the query text “plan” would result in total 6 terms getting searched underneath as in this example. (given that only those 5 terms are present in the indexed content which are at the asked edit distance or fuzziness of 1)<\/p>\n\n\n\n

One important optimization idea while guarding against any potential misspellings is that – most spelling mistakes happen towards the end, not towards the beginning of the text. Users can leverage this fact and utilize the <\/span>prefix_length<\/span><\/i> option in fuzzy queries. Once the <\/span>prefix_length<\/span><\/i> is given, then the fuzziness will only be considered for the text after the given <\/span>prefix_length<\/span><\/i>.<\/span><\/p>\n\n\n\n

Usually, a <\/span>prefix_length<\/span><\/i> of 2 or 3 ought to be good. But certainly, this is an application or use case-specific one.<\/span><\/p>\n\n\n\n

Example:<\/span><\/em><\/p>\n\n\n

[crayon font-size=”16″ lang=”default” decode=”true”]{
\n\u00a0“match”: “beautiful”,\u00a0 => “autiful” is only considered for fuzziness
\n\u00a0“field”: “reviews.content”,
\n\u00a0“analyzer”: “standard”,
\n\u00a0“fuzziness”: 1,
\n\u00a0“prefix_length”: 2
\n}[\/crayon]<\/p>\n\n\n\n

\u00a0<\/p>\n\n\n\n

This drastically reduces the scope\/number of the tokens searched in the index for a given fuzzy query.\u00a0 And the search query performance can be significantly improved by specifying a `prefix_length<\/i>` for the fuzziness.\u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 <\/span><\/p>\n\n\n\n

\u00a0<\/p>\n\n\n\n

Skip Scoring When Text Relevancy Doesn\u2019t Matter<\/b><\/h3>\n\n\n\n

\u00a0<\/p>\n\n\n\n

Many times it is observed that users are using Full-Text Search for the exact match queries with a bit of fuzziness or other search specific capabilities like geo<\/a>. Text relevancy score doesn\u2019t matter when the user is looking for exact or more targeted searches with many predicates.\u00a0<\/span><\/p>\n\n\n\n

In similar situations where the user isn\u2019t interested in the default tf-idf<\/a> scoring, then they could optimize the query performance by skipping the scoring altogether. Users may skip the scoring by passing a “score”: “none” option in the search request.\u00a0<\/span><\/p>\n\n\n\n

Example:\u00a0<\/span><\/i><\/p>\n\n\n

[crayon lang=”default” decode=”true”]{
\n “query”: {},
\n “score”: “none”,
\n “size”: 10,
\n “from”: 0
\n}[\/crayon]<\/p>\n\n\n\n

This improves the search query performance significantly in many cases, especially for composite queries with many child search clauses.<\/span><\/p>\n\n\n\n

This feature is available since the Couchbase server release – 6.6.1<\/span><\/p>\n\n\n\n

\u00a0<\/p>\n\n\n\n

Keyset Pagination For Deeper Page Searches<\/b><\/h3>\n\n\n\n

\u00a0<\/p>\n\n\n\n

As you might know, the pagination of search results can be done using the `from` and `size` parameters in the search request. But as the search gets into deeper pages it becomes highly resource taxing.\u00a0 The primary reason being the search results are by default sorted by their tf-idf<\/a> scores, and Full-Text Search has heap memory requirements proportional to the requested page\u2019s offset and size. ie `from+size` for maintaining this ranking.\u00a0<\/span><\/p>\n\n\n\n

To safeguard against any arbitrary higher memory requirements, we have a configurable limit <\/span>bleveMaxResultWindow<\/b> (10000 default) on the maximum allowable page offsets. But bumping this limit to higher levels isn\u2019t a scalable solution.<\/span><\/p>\n\n\n\n

To circumvent this problem, we have introduced the concept of key set pagination in FTS.\u00a0<\/span><\/p>\n\n\n\n

Instead of providing `<\/span>from`<\/span><\/i> as a number of search results to skip, the user will provide the sort value of a previously seen search result (usually, the last result shown on the current page).\u00a0 The idea is that to show the next page of the results, we just want the top N results of that sort after the last result from the previous page.<\/span><\/p>\n\n\n\n

This solution requires a few preconditions be met:<\/span><\/p>\n\n\n\n