0.8

This version is a complete rewrite of the index internal structure, doing away with the use of Redis strings under the hood, and using an internal data structure instead. We also added an internal garbage collection mechanism for cleaning garbage from the index after deletes/updates.

Notes:

1. This version requires a complete rebuild of the data and is not backwards compatible with older versions.
2. As of this version, RediSearch cannot be used with AOF persistence, and should only be used with RDB persistence.

0.7.1

Fixes a few bugs that may cause redis to crash.

0.7

Main additions in this version:

Support for updating documents

If the REPLACE argument is present in FT.ADD, we re-index the document and update the index accordingly. Notice that this is done by deleting the document and then inserting it again with a new internal id. So lots of replaces will cause the index to leak. We also do not compare the documents, so replacing the document when nothing has changed will still cause the index to grow.

Support for multiple numeric filters

You can now specify multiple FILTER predicates in a query, referring to different numeric properties. As the different filters are intersected, specifying multiple filters for the same property is meaningless.

Document payloads

You can now save payloads inside the index per document with the PAYLOAD specifier in FT.ADD. These are not indexed, and are meant for custom scoring functions (coming in a later release) to be able to evaluate them with near-zero latency, without loading the actual document. However, you can retrieve them along with the documents with the WITHPAYLOADS argument when searching.

0.6

This version brings two important additions:

1. Geo-search is now supported. The implementation leverages Redis' own GEOADD/GEORADIUS commands, and uses geo sets as geograhical indexes. Upon querying, an additional GEOFILTER argument has been added, with the same semantics as the Redis GEORADIUS command.

Note that currently, we simply perform a GEORADIUS command, load the entire result of it, and intersect that with the text query, inside redis. This might cause geo searches to be slow if the radius is large and/or returns a huge number of results. This will be optimized in the future, but it gives good performance already.

1. A complete rewrite of Numeric Indexes. A new data structure has been added to support optimized numerical ranges and intersections of them with the result. I'll document the data structure, which is based on a Range Tree, in the design document.

The rewrite makes numeric indexes able to speed up queries considerably if applied correctly. If the range is small but the query is slow, you can expect up to an order of magnitude speedup in results. Large ranges, that span over 50% of the results or so, will however slow query times. The actual effects depend on the distribution of the numeric values in the data set and on the cardinality of the results in the query range.

0.5.4

• Unicode aware case-folding in auto-complete searches.
• Several bug fixes.

0.5.3 Crash Fix

This version fixes a critical bug - crash during RDB load.

0.5.2

Since 0.5.0 FT.DROP was not functioning correctly. 0.5.2 makes it work again, and adds proper testing for it.

0.5.1

This version adds document deletion, and uses an optimized trie map to store docKey to docId, thus preventing document duplication.

Note: Document updating in this version is not supported directly, but can be achieved by running FT.DEL and then FT.ADD on the same document.

0.5

Notice: This version contains breaking API changes, and changes to internal encoding

Any index created with previous RediSearch versions needs to be rebuilt.

Main Changes:

• Significant optimizations to memory consumption of up to 50%. The main improvement comes from optimizing the data structures mapping between internal, incremental numeric ids the index uses, and the original document ids inserted into the index.
• Changes in the index record structure to allow flexible encoding, as described in the next section:
• New options introduced to index creation to facilitate even further memory reduction at the expense of less features:
  • NOOFFSETS - Causes the index not to save term offset vectors, which can reduce memory consumption considerably, but remove the ability to query for exact phrases, and reduce relevance in phrase searches.
  • NOSCOREIDX - By default, RediSearch saves a small skip-index for the top entries of each term, used to speed up single-term searches. For most terms however, this is not needed. While FT.OPTIMIZE can remove tons of memory by deleting these keys for less popular terms, the above option eliminates this throughout the index.
  • NOFIELDS - By default, per each record, RediSearch saves 8 bits of "field flags" - signifying which fields in the document the term appeared in, and allowing for INFIELDS search filtering. This is not a huge memory waster, but if you don't need this feature, you can disable it in your index.

0.4

Notice: This version contains breaking API changes, and changes to internal encoding

You will need to reindex your data if it has been created on older versions.

Main changes:

• Change to index creation API. The format now is FT.CREATE {index} SCHEMA {field} [TEXT [WEIGHT {weight}] [NUMERIC]
• Added the FT.INFO command, which reports statistics on index memory consumption.
• Optimizations of the inverted index format. The inverted index takes up 30-40% less space than in previous version. This change requires a full reindexing. The engine will crash or behave unexpectedly if used on older data.
• Many bug-fixes in the internal intersection and union logic.
• Index spec is now a custom data type, allowing faster loading times and storing stats internally.