I’m happy to announce a new release of RediSearch.
Ref: https://github.com/RedisLabsModules/RediSearch/releases/tag/v1.4.0, release notes following immediately below.
P.S. some of the links to the documentation will become available over next 24 hours due to what may be an overzealous CDN.
Update urgency: Medium - mainly due to numerous fixes
This version improves overall stability and performance of RediSearch. It also delivers better support for use cases in which documents are continuously updated. New features:
Query spelling correction
Enhancement: More fuzziness in search
Like most search engines, RediSearch was designed for maintaining append-mostly indices. To update an existing document, the document is actually replaced - that is deleted and added to the index.
Because RediSearch provides realtime indexing and searching it is very tempting to use for searching near-realtime data (or the products of its processing). In such cases, the number of indexed documents stays mostly static, but their contents are continuously updated.
To support this use case, RediSearch has been reworked internally to use 64-bit internal document IDs so that an index can sustain high update throughputs without overflowing. Furthermore and as a result, significant effort has been put into improving memory management and garbage collection.
IF subcommand has been add to
FT.ADD. When used with the existing
REPLACE [PARTIAL] subcommand, the document will be updated only if the condition provided evaluates to a truth value, otherwise a special
NOADD reply is returned.
FT.ALTER command has been introduced, and provides the ability to add new fields to the definition of an existing index. The contents of such newly-added fields are indexed only for new or updated documents.
Query spelling correction
Query spelling correction, a.k.a “did you mean”, is now provided via the
FT.SPELLCHECK command. It enables generating suggestions for search terms that could be misspelled. For more details see Query Spelling Correction.
Phonetic matching, a.k.a “Jon or John?”, is now supported via the
PHONETIC text field attribute. The terms in such fields are also indexed by their phonetic equivalents, and search results include these by default. For more details see Phonetic Matching.
More fuzziness in search
The fuzzy match operator, ‘%’, can now be repeated up to three times to specify the Levenshtein distance. That means that the queries
%%%hello%%% will perform fuzzy matching on ‘hello’ for all terms with LD of 1, 2 and 3, respectively.