Back to Redis

Scalable Query Best Practices

content/operate/oss_and_stack/stack-with-enterprise/search/scalable-query-best-practices.md

latest7.1 KB
Original Source

[Vertical scaling of Redis Search]({{<relref "/operate/oss_and_stack/stack-with-enterprise/search/query-performance-factor">}}) requires configuring query performance factors. With careful crafting of search indexes and queries, query performance factors allow throughput scaling up to 16X. The following recommendations can help optimize your indexes and queries to maximize the performance benefits from additional CPUs allocated by query performance factors.

Best candidates for query performance factor improvements

  • Query types:

    • [Full-text]({{<relref "/develop/ai/search-and-query/query/full-text">}})

    • [Tag]({{<relref "/develop/ai/search-and-query/advanced-concepts/tags">}})

    • [Vector]({{<relref "/develop/ai/search-and-query/query/vector-search">}})

    • [Numeric]({{<relref "/develop/ai/search-and-query/query/range">}})

    • [Geo]({{<relref "/develop/ai/search-and-query/query/geo-spatial">}})

  • Result set types:

    • Small result sets

    • Document subsets that are indexed in their [non-normalized]({{<relref "/develop/ai/search-and-query/advanced-concepts/sorting#normalization-unf-option">}}) form

Best practices

If query performance factors have not boosted the performance of your queries as much as expected:

  1. Verify your index includes all queried and returned fields.

  2. Identify and avoid query [anti-patterns]({{<relref "/develop/ai/search-and-query/best-practices/scalable-query-best-practices#anti-patterns">}}) that limit scalability.

  3. Follow best practices to improve indexing.

  4. Follow best practices to improve queries.

Improve indexing

Follow these best practices for [indexing]({{<relref "/develop/ai/search-and-query/indexing">}}):

  • Include fields in the index definition that are used in the query or the required result sets (projections).

  • Use SORTABLE for all fields returned in result sets.

  • Use the UNF option for TAG and GEO fields.

  • Use the NOSTEM option for TEXT fields.

Improve queries

Follow these best practices to optimize [queries]({{<relref "/develop/ai/search-and-query/query">}}):

  • Specify the result set fields in the RETURN or LOAD clauses and include them in the index definition. Don’t just return the default result set from [FT.SEARCH]({{< relref "commands/ft.search/" >}}) or LOAD * from [FT.AGGREGATE]({{< relref "commands/ft.aggregate/" >}}).

  • Use LIMIT to reduce the result set size.

  • Use [DIALECT 3]({{<relref "/develop/ai/search-and-query/advanced-concepts/dialects#dialect-3">}}) or higher for any queries against JSON.

Index and query examples

The following examples depict an anti-pattern index schema and query, followed by a corrected schema and query, which allows for scalability with Redis Search.

Anti-pattern index schema

The following index schema is not optimized for vertical scaling:

sh
FT.CREATE jsonidx:profiles ON JSON PREFIX 1 profiles: 
          SCHEMA $.tags.* as t NUMERIC SORTABLE 
                 $.firstName as name TEXT 
                 $.location as loc GEO

Anti-pattern query

The following query is not optimized for vertical scaling:

sh
FT.AGGREGATE jsonidx:profiles '@t:[1299 1299]' LOAD * LIMIT 0 10

Improved index schema

Here's an improved index schema that follows best practices for vertical scaling:

sh
FT.CREATE jsonidx:profiles ON JSON PREFIX 1 profiles: 
          SCHEMA $.tags.* as t NUMERIC SORTABLE 
                 $.firstName as name TEXT NOSTEM SORTABLE 
                 $.lastName as lastname TEXT NOSTEM SORTABLE 
                 $.location as loc GEO SORTABLE 
                 $.id as id TAG SORTABLE UNF 
                 $.ver as ver TAG SORTABLE UNF

Improved query

Here's an improved query that follows best practices for vertical scaling:

sh
FT.AGGREGATE jsonidx:profiles '@t:[1299 1299]' 
                LOAD 6 id t name lastname loc ver
                LIMIT 0 10
                DIALECT 3

Performance results

The following benchmarks show the performance improvements for different query types achieved with query performance factors. Vector, tag, and text queries strongly benefit, while numeric and geographic queries show more limited improvements.

Vector schema type

Vector ingest

ShardsThreads per shardCPUsSpeedup factor
1010
6066.6
1662.5
26126.1
462424.3

Vector query

ShardsThreads per shardCPUsSpeedup factor
1010
6060.8
1664.7
26125.1
46245.6

Tag schema type

Worker threads% change
00
6135.88

Text schema type

Two-word union queries

Worker threadsQueries per second% change
01880
61,072470
121,995961
182,8341,407

Two-word intersection queries

Worker threadsQueries per second% change
02,3730
612,396422
1217,506638
1819,764733

Simple one-word match

Worker threadsQueries per second% change
04760
62,837496
125,2921,012
187,5121,478

Numeric schema type

Worker threadsQueries per second% change
033,5840
136,99310.15
336,5048.69
636,8979.86

Geo schema type

Geo queries without UNF

Worker threadsQueries per second% change
0480
696100
1296100
1898104

Geo queries with UNF

Worker threadsQueries per second% change
0610
6227272
12217256
18217256