Skip to main content
Loading

AVS system diagram

This page describes three distinct layers of a fully functional Aerospike Vector Search (AVS) platform, and the components within each layer. It is important to understand these components if you plan to operate AVS yourself. The layers are:

  • Storage layer - the Aerospike Database (ASDB) cluster
  • Search layer - the AVS cluster
  • Application layer - load balancer

image

Storage layer (ASDB cluster)​

ASDB is built on a horizontally scalable storage system and delivers high performance, low latency, and reliability. ASDB's data partitioning and hybrid memory architecture make it especially well-suited for AVS.

The storage system provides the following core pieces of functionality related to AVS:

  • Storing state for the AVS system. This is referred to as index metadata and requires a specific namespace configuration in ASDB to start the search layer.
  • Stores the the vector data and associated metadata for your search application.
  • Stores the index data for your Hierarchical Navigable Small World (HNSW) index.

image

AVS can use several core storage layer features, the relevant specifics of which are highlighted here.

Data partitioning​

ASDB uses a partitioning system to manage data across nodes. When using AVS, that data includes your HNSW index. Partitioning allows you to dynamically scale your storage based on your index needs without the risk of your indexes growing too large.

Additionally, you can configure how you store data across your index and your record data. This flexibility lets you use the specific storage features that are most advantageous to your use case.

Hybrid memory architecture (HMA)​

ASDB's hybrid memory architecture takes advantage of in-memory storage and fast drive types. You can use either or both, depending on the cost and performance trade-offs that best suit your needs. These features require specification at the namespace level for your index or data when used with AVS.

Native data replication and XDR​

ASDB has multiple options for data replication that are relevant to how you store your core AVS search application. These replication features are:

These features require specification at the namespace level for your index or data when used with AVS.

Backup and restore capabilities​

ASDB's core backup and restore tools work with vector and index data. These features require specification at the namespace level for your index or data when used with AVS.

Encryption and compression features​

AVS operators can configure TLS for the AVS service and ASDB to encrypt data at rest and encrypt data in motion. Additionally, operators can configure compression to optimize storage. These features require specification at the namespace level for your index or data when used with AVS.

Search layer (AVS cluster)​

The search layer is a collection of clustered AVS nodes that can scale according to your operational needs for query and ingest throughput. These nodes perform caching, ingestion, and indexing.

image

Clustering​

AVS uses the same clustering algorithm as ASDB to add nodes to the pool and utilize the resources of those nodes. Clustering happens by default, but you can use several configuration options for heartbeat and interconnect to configure details like encryption and intervals used by the system.

Caching​

To ensure optimal performance, AVS caches the index in memory on the AVS nodes. This ensures scaling can meet specific performance requirements for throughput and latency. You can configure caching on the node or override it at the index level. Only index records are saved in the cache — vector records require a round-trip to the storage layer.

For details, visit our caching guide.

Ingestion and indexing​

Each AVS node ingests and indexes new vector records as they come in. The ingestion and indexing process comprises the following:

  1. Updating vector records in the storage layer
  2. Asynchronous index construction
  3. Retroactive index healing

For details, see ingestion and indexing.

Application load balancer (optional)​

If you want to provide AVS as a service from a host URL, you need to configure an application load balancer.

Using without a load balancer (default behavior)​

If you are not exposing AVS to the internet, you can allow clients to connect directly to an AVS node and use that connection to discover other nodes in the cluster. You must specify at least one valid node as a seed when creating your cluster and set is_loadbalancer to false.

Using with a load balancer​

A layer-7 load-balancer is required to load-balance gRPC connections properly. Layer-7 load balancers can route gRPC calls based on the specific method being invoked, enabling more intelligent traffic management. Additionally, this layer provides TLS termination and retry logic. If you are using a load balancer, ensure that the is_loadbalancer configuration is set to true when creating your client.

tip

A layer-4 load balancer from a cloud provider is not sufficient for AVS because it does not properly load balance the gRPC connection. See the Kubernetes installation guide for details about installing Istio.