content/operate/oss_and_stack/stack-with-enterprise/release-notes/redisearch/redisearch-2.4-release-notes.md
RediSearch v2.4.16 requires:
This is a maintenance release for RediSearch 2.4
Update urgency: HIGH: There is a critical bug that may affect a subset of users. Upgrade!
Details:
Bug fixes:
This is a maintenance release for RediSearch 2.4.
Update urgency: MODERATE: Program an upgrade of the server, but it's not urgent.
Details:
Bug fixes:
findInfo, which could reduce stability during upgrade in Redis Enterprise (MOD-4197, MOD-4052)SORTBY numeric field for non-SORTABLE fields on the coordinator (MOD-4115)SORTBY (MOD-4120)Improvements:
This is a maintenance release for RediSearch 2.4.
Update urgency: MODERATE: Program an upgrade of the server, but it's not urgent.
Details:
Improvements:
Bug fixes:
This is a maintenance release for RediSearch 2.4.
Update urgency: MODERATE: Program an upgrade of the server, but it's not urgent.
Details:
Bug fixes:
SORTBY with MAX on FT.SEARCH (which is not supported) caused an inconsistent response and out-of-memory error (MOD-3540, MOD-3644)Improvements:
This is a maintenance release for RediSearch 2.4.
Update urgency: MODERATE: Program an upgrade of the server, but it's not urgent.
Details:
Bug fixes:
This is a maintenance release for RediSearch 2.4.
Update urgency: MODERATE: Program an upgrade of the server, but it's not urgent.
Details:
Bug fixes:
FT.AGGREGATE "... APPLY '-INF % -1'..."FT.EXPLAIN without parameters causes a crashnum_terms value in FT.INFO after a term is deleted from all the docs (garbage collection)OFFSET+LIMIT was greater than maxSearchResults (config)BlockedClientMeasureTime to coordinator for more accurate performance stats{}) are now returned by FT.SEARCHImprovements:
Minor breaking change:
{}), this could break your application. This only applies to users who are using RediSearch in clustered databases.This is a maintenance release for RediSearch 2.4.
Update urgency: MODERATE: Program an upgrade of the server, but it's not urgent.
However, if you're using Vector Similarity (introduced in RediSearch 2.4), there are some critical bugs that may affect a subset of users. In this case, you should upgrade.
Details:
Bug fixes:
EvalContext (which might have led to crashes in clustered databases)Improvements:
This is a maintenance release for RediSearch 2.4.
Update urgency: MODERATE: Program an upgrade of the server, but it's not urgent.
Details:
Bug fixes:
This is a maintenance release for RediSearch 2.4.
Update urgency: MODERATE: Program an upgrade of the server, but it's not urgent.
Details:
Bug fixes:
Improvements:
TEXT field, skip term iterator if term does not appear in requested fieldThis is the General Availability release of RediSearch 2.4.
RediSearch 2.4 introduces a new capability, Vector Similarity Search (VSS), which allows indexing and querying vector data stored (as BLOBs) in Redis hashes.
It also introduces a new query syntax to address query parser inconsistencies found in previous versions of RediSearch. Users can now choose between Dialect version 1 (to keep existing query parser behavior) or Dialect version 2 (to switch to the updated behavior).
All VSS queries or any query using the PARAMS option must use Dialect version 2.
FT.CREATE is extended to support the creation of 2 popular types of vector indexes:
FLAT Index
This type of index is used when the recall is more important than the speed of query execution. A query vector will be compared to all vectors in a flat index. The search results will return the exact top k nearest neighbors to the query vector.
Hierarchical Navigable Small World (HNSW) Index
This index is a modified implementation of the library written by the author of this influential academic paper. An HNSW vector index is used when the speed of query execution is preferred over recall. The results returned are approximate nearest neighbors (ANNs).
You can try out different HNSW index parameters (M, EFCONSTRUCTION, EFRUNTIME) to improve the "recall versus speed" balance.
Use FT.SEARCH to retrieve the top K hashes with the most similar vectors to a given query vector.
Hybrid queries in FT.SEARCH:
Use hybrid queries to retrieve Redis hashes that match a combination of vector and non-vector search criteria. Non-vector search criteria can include expressions combining NUMERIC, TEXT, TAG, and GEO fields.
Hybrid queries are often used in modern ecommerce search applications featuring "visual" similarity plus metadata similarity. For example, you can use a single hybrid query to find products that are visually similar to a given image within a price range and/or geo-location.
Use [FT.CONFIG SET]({{< relref "commands/ft.config-set" >}}) to set DEFAULT_DIALECT at the module level. By default, DEFAULT_DIALECT is set to 1.
Override DIALECT:
It is possible to override the module-level dialect for a specific command at runtime. You can specify the dialect when executing any of the following commands:
[FT.SEARCH]({{< relref "commands/ft.search" >}})
[FT.AGGREGATE]({{< relref "commands/ft.aggregate" >}})
[FT.EXPLAIN]({{< relref "commands/ft.explain" >}})
[FT.EXPLAINCLI]({{< relref "commands/ft.explaincli" >}})
[FT.SPELLCHECK]({{< relref "commands/ft.spellcheck" >}})
If you do not specify dialect when running any of these commands, they will use the default module-level dialect value.
Features:
Performance enhancements (since 2.4-RC1):
Security and privacy (since 2.4-RC1):
Bug fixes (since 2.4-RC1):
RediSearch 2.4.3 introduces a new query syntax to address query parser inconsistencies found in previous versions of RediSearch. Users can now choose between:
Dialect version 1 (to keep the query dialect as in RediSearch 2.2)
Dialect version 2 (to use the updated dialect)
Existing RediSearch 2.2 users will not have to modify their queries since the default dialect is 1. However, all RediSearch users should gradually update their queries to use dialect version 2.
Under certain conditions, some query parsing rules did not behave as originally intended. Queries containing the following operators could return unexpected results:
ANDORTo minimize the impact on existing, unaffected RediSearch users, a DIALECT setting was introduced to allow:
Existing queries to run without any modification (DIALECT 1)
New queries to benefit from the updated query-parsing behavior (DIALECT 2)
Your existing queries may behave differently under different DIALECT versions, if they fall into any of the following categories:
Your query has a field modifier followed by multiple words.
Consider this simple query <nobr>@name:James Brown</nobr>.
The field modifier @name is followed by 2 words: James and Brown.
With DIALECT 1, the parser interprets this query as "find James Brown in the @name field."
With DIALECT 2, the parser interprets it as "find James in the @name field AND Brown in ANY text field." In other words, the query parser interprets it as <nobr>(@name:James) Brown</nobr>.
With DIALECT 2, you could achieve the default behavior from DIALECT 1 by updating your query to <nobr>@name:(James Brown)</nobr>.
Your query uses quotes, ~, -, % (exact, optional, negation, fuzzy).
Consider a simple query with negation <nobr>-hello world</nobr>.
With DIALECT 1, the parser interprets this query as "find values in any field that does not contain hello AND does not contain world." This is the equivalent of <nobr>-(hello world)</nobr> or <nobr>-hello -world</nobr>.
With DIALECT 2, the parser interprets it as -hello AND world, so only hello is negated.
With DIALECT 2, you could achieve the default behavior from dialect 1 by updating your query to <nobr>-(hello world)</nobr>.
Another example that illustrates the differences in parser behavior is
hello world | "goodbye" moon:
With DIALECT 1, the parser interprets this query as searching for (hello world | "goodbye") moon
With DIALECT 2, the parser interprets it as searching for either hello world OR "goodbye" moon.
{{<note>}} This is the first GA version of 2.4. The version inside Redis will be 2.4.3 in semantic versioning. Since the version of a module in Redis is numeric, we could not add a GA flag. {{</note>}}