Namespaces and tiering layout

For the complete documentation index see: llms.txt

All documentation pages available in markdown.

This page explains how namespace_overrides routes feature views to different Aerospike namespaces, what that saves, and what it adds to the read path.

On the overview page, you saw how hot and cold feature views route to different Aerospike namespaces. Before you configure the tiered repository, this page explains who owns each part of that setup and how Feast routing choices affect read latency.

Responsibility split

Tiering spans Aerospike cluster operations and Feast project configuration. The table identifies the owner and mechanism for each concern.

Concern	Owner	Mechanism
Memory and flash namespace policies	Aerospike operations	`aerospike.conf`, `storage-engine` per namespace
Which feature view uses which namespace	Feast	`online_store.namespace` + `namespace_overrides`
Which features a model requests together	Feast	`FeatureService` definitions

Feast keys namespace_overrides by feature view name. Spelling must match the name= argument on each FeatureView exactly.

Default namespace and overrides

online_store:
  type: aerospike
  namespace: feast_ssd
  namespace_overrides:
    scoring_velocity: feast_ram

Feature views without an override land on feast_ssd (cold / wide).
scoring_velocity lands on feast_ram (hot).

Benefits and boundaries

Routing cold views to flash reduces the memory capacity needed for online features. It does not reduce read calls. Feast issues one online_read per requested feature view.

A hot-only FeatureService controls the tradeoff by requesting fewer views. A full service requests the hot and cold views, adding a read call for each added view. When those views resolve to separate namespaces, the calls also use different storage tiers.

In this tutorial’s local demo, both logical tiers use the Docker test namespace so you can run without custom aerospike.conf. The YAML structure matches production. Only the namespace names change. The demo verifies that configuration loads and each FeatureService returns its expected feature fields. It does not verify namespace override routing, memory or flash placement, or latency differences between tiers.

Read behavior across tiers

For requests containing at most batch_max_records entities (1,000 by default), each online_read issues one batch_operate. Larger requests issue one batch_operate per entity chunk. A service that adds cold feature views adds read calls regardless of whether those views share a namespace. When views are in separate namespaces, those calls target separate records and storage tiers.

Namespace placement controls which storage tier backs each call. A hot-only FeatureService that reads only from a memory namespace has lower per-call latency than one reading from a flash namespace. A full service spanning both tiers takes on both the added call count from the extra views and the slower flash reads for the cold views.

Use a hot-only FeatureService when the ranking path does not need cold views. Use a full service when the model needs both groups and its latency budget accommodates the additional calls and flash reads.

TTL across tiers

ttl_seconds is an online-store setting that applies the same record-level time to live (TTL) to every Aerospike write, across both tiers. FeatureView.ttl controls batch materialization lookback and historical point-in-time retrieval. It does not give the standard Aerospike online read path a separate storage TTL for each view.

This tutorial sets ttl_seconds to 30 days so the cold view can remain in Aerospike for its full intended retention period. The hot record has the same storage TTL. Keep hot values fresh through regular writes and monitor their event timestamps.

On the next page, you configure the tiered feature repository.