Using Aerospike Expressions to Cut Network Traffic in Read‑Heavy Workloads

Problem: Too much data moving for simple filters

In many read‑heavy services the client asks Aerospike for a set of records, then discards most of them locally because only a subset matches a business rule. This pattern wastes network bandwidth, increases latency, and adds unnecessary CPU work on the client.

Thesis: Aerospike Expressions evaluate predicates inside the server, so only matching records travel to the client.

Expressions are a lightweight, SQL‑like language that Aerospike can run on each record during a get, exists, or query operation. When the expression evaluates to true, the record is returned; otherwise it is skipped early in the pipeline.

How expressions work

An expression can contain:

• Bin references (age, score)
• Arithmetic operators (+, -, *, /)
• String functions (regex_match, strlen)
• Boolean logic (AND, OR, NOT)

The Aerospike server evaluates the expression per record, just like a WHERE clause, but without sending the full record back to the client first.

Worked example: filtering user profiles

Assume a namespace test and set demo with bins:

• age (integer)
• score (integer)

We want only users older than 30 whose doubled score exceeds 100.

1. Prepare the cluster (local dev)

Start a single‑node Aerospike instance with Docker:

docker run -d --name aerospike-demo \
  -p 3000:3000 -p 3003:3003 \
  aerospike/aerospike-server:latest

No special feature flag is required for basic expressions; they are enabled by default in recent server versions.

2. Insert test records

Using the Aerospike Query Language (aql) shell:

aql> INSERT INTO test.demo (PK, age, score) VALUES (1, 25, 40)
aql> INSERT INTO test.demo (PK, age, score) VALUES (2, 35, 60)
aql> INSERT INTO test.demo (PK, age, score) VALUES (3, 40, 55)
aql> INSERT INTO test.demo (PK, age, score) VALUES (4, 28, 90)

Only records 2 and 3 should satisfy age > 30 AND score * 2 > 100.

3. Run a query with an expression

The expression string is passed to the WHERE clause. In aql you can write it directly:

aql> SELECT * FROM test.demo WHERE age > 30 AND score * 2 > 100

The server evaluates age > 30 AND score * 2 > 100 for each record and returns only PK 2 and PK 3.

4. Verify reduced network traffic

You can observe the effect with the server’s statistics:

# Show proxy bytes out before the query
aql> show statistics like 'proxy'
# Run the query
# Show proxy bytes out after the query and compare the delta

The delta should be roughly the size of two records instead of four. For a more granular view, run tcpdump -i any port 3000 while executing the query from a client and compare packet lengths with and without the expression.

Trade‑offs and limitations

CPU cost on the server

Expression evaluation adds per‑record CPU work. Simple arithmetic and boolean checks are cheap, but complex string regexes or nested arithmetic can increase node load. Monitor the transaction and query CPU metrics (show statistics like 'transaction') before and after deploying heavy expressions.

Client library version

Expressions require a client library that supports the feature (generally version 4.0 or newer). Older clients will ignore the expression clause and fetch full records, negating the benefit. Check your client’s changelog or run client.info() to confirm support.

No expression indexes (yet)

As of the current server release, expressions cannot be indexed like regular bins. If you need both filtering and fast look‑ups on the same condition, consider creating a dedicated bin that stores the pre‑computed value and indexing that bin instead.

Actionable closing

If your read‑heavy workload suffers from unnecessary data transfer, start by identifying the most common filter predicates. Replace client‑side filtering with an Aerospike Expression wherever the predicate is simple enough to keep CPU impact low. Verify the improvement with the proxy statistics method above, watch node CPU for any regression, and ensure all services use a compatible client version. When the expression grows complex, evaluate whether a pre‑computed bin or a secondary index would be a better trade‑off.