Redis online store

Description

The Redis online store provides support for materializing feature values into Redis.

• Both Redis and Redis Cluster are supported.
• The data model used to store feature values in Redis is described in more detail here.

Data model: All feature views that share the same entity key are stored in a single Redis hash. The hash key is derived from the serialized entity key and the project name. Each feature's value is a hash field keyed by a murmur3 hash of "feature_view_name:feature_name", and a separate _ts:<feature_view_name> field stores the event timestamp per feature view.

This collocated-by-entity design enables an important performance optimization: get_online_features() requests that span multiple feature views for the same entity can issue all HMGET commands in a single Redis pipeline execution, regardless of how many feature views are requested. See Performance characteristics below.

Getting started

In order to use this online store, you'll need to install the redis extra (along with the dependency needed for the offline store of choice). E.g.

• pip install 'feast[gcp, redis]'
• pip install 'feast[snowflake, redis]'
• pip install 'feast[aws, redis]'
• pip install 'feast[azure, redis]'

You can get started by using any of the other templates (e.g. feast init -t gcp or feast init -t snowflake or feast init -t aws), and then swapping in Redis as the online store as seen below in the examples.

Examples

Connecting to a single Redis instance:

{% code title="feature_store.yaml" %}

project: my_feature_repo
registry: data/registry.db
provider: local
online_store:
  type: redis
  connection_string: "localhost:6379"

{% endcode %}

Connecting to a Redis Cluster with SSL enabled and password authentication:

{% code title="feature_store.yaml" %}

project: my_feature_repo
registry: data/registry.db
provider: local
online_store:
  type: redis
  redis_type: redis_cluster
  connection_string: "redis1:6379,redis2:6379,ssl=true,password=my_password"

{% endcode %}

Connecting to a Redis Sentinel with SSL enabled and password authentication:

{% code title="feature_store.yaml" %}

project: my_feature_repo
registry: data/registry.db
provider: local
online_store:
  type: redis
  redis_type: redis_sentinel
  sentinel_master: mymaster
  connection_string: "redis1:26379,ssl=true,password=my_password"

{% endcode %}

TTL configuration

The Redis online store supports two complementary TTL mechanisms:

Key-level TTL (key_ttl_seconds)

Sets a Redis EXPIRE on the entire entity hash key. When the TTL elapses, Redis automatically deletes all feature values for that entity across all feature views that share the same key. Use this to bound memory usage and automatically evict stale entity data.

online_store:
  type: redis
  key_ttl_seconds: 604800   # 7 days
  connection_string: "localhost:6379"

{% hint style="warning" %} Because all feature views for the same entity share one Redis hash key, key_ttl_seconds uses the entity as the expiry unit, not the feature view. Writing any feature view for an entity resets the TTL for the whole hash. This means a frequently written feature view can keep a stale, infrequently written feature view alive beyond its intended TTL. {% endhint %}

{% hint style="info" %} FeatureView.ttl defines the offline retrieval window (how far back in time point-in-time joins look in the offline store). It does not filter online store reads. To control online data expiry, use key_ttl_seconds. {% endhint %}

Performance characteristics

Batched multi-feature-view reads

Unlike most online stores, the Redis implementation overrides get_online_features() to issue a single pipeline execution for all feature views in the request. Because all feature views for the same entity live in the same Redis hash, all HMGET commands across every feature view are batched into one pipeline.execute() call.

Benchmark results against Redis 8.6.2 (localhost, 50 entities, 3 features/FV, 300 rounds):

The speedup grows with the number of feature views and is most pronounced in production environments with non-trivial network RTT to Redis.

Write path: skip_dedup for bulk loads

By default, online_write_batch() checks existing timestamps before writing (to avoid overwriting newer data with older data). This requires two pipeline round trips per batch: one to read existing timestamps, one to write new values.

For initial bulk loads or append-only pipelines where out-of-order writes are not a concern, set skip_dedup: true to write in a single pipeline round trip:

online_store:
  type: redis
  connection_string: "localhost:6379"
  skip_dedup: true

{% hint style="warning" %} With skip_dedup: true, writes always overwrite existing data regardless of timestamp order. Under concurrent writers, an older record can overwrite a newer one. Use only for controlled bulk loads or pipelines that guarantee ordered delivery. {% endhint %}

Async write support

The Redis online store implements online_write_batch_async() using the async Redis client. This enables non-blocking batch writes in async serving frameworks. skip_dedup is also respected in the async path.

Configuration reference

The full set of configuration options is available in RedisOnlineStoreConfig.

Functionality Matrix

The set of functionality supported by online stores is described in detail here. Below is a matrix indicating which functionality is supported by the Redis online store.

To compare this set of functionality against other online stores, please see the full functionality matrix.