TessariDBDocs
  • 0.34.2-betalatest
  • 0.34.1-beta
  • 0.34.0-beta
  • 0.33.4-beta
  • 0.33.3-beta
  • 0.33.2-beta
  • 0.33.1-beta
  • 0.33.0-beta
  • 0.32.0-beta

A space with a limit

MAX n keeps the newest keys and removes the least recently written; EVICT NONE refuses the key past the limit instead.

A cache is a space that holds at most so many keys and makes room by forgetting the oldest. Declare the limit and the space keeps it:

DEFINE NAMESPACE app;
USE NAMESPACE app;
DEFINE DATABASE web;
USE DATABASE web;
DEFINE SPACE recent MAX 3;
SET recent:'a' = 1;
SET recent:'b' = 2;
SET recent:'c' = 3;
SET recent:'d' = 4;
KEYS FROM recent;

'b', 'c', 'd'. The commit that would have taken the space to four keys removed the least recently written one — the key whose newest version is oldest — and kept the key it was writing.

What counts, and what makes a key recent

The limit is a count of keys, not a size in bytes. A count is exact and the same on every node; the bytes a key occupies in a log-structured store depend on versions and compaction nobody asked about, and a limit expressed in them would move under you.

Writing a key makes it recent. Reading it does not:

GET recent:'b';
SET recent:'e' = 5;
KEYS FROM recent;

'c', 'd', 'e' — 'b' was read a moment ago and went anyway. A read changes nothing in this store, so it cannot keep a key alive; write it again if it should stay.

Refusing instead of forgetting

Some spaces must never lose a key silently — a set of issued tickets, a list of seats. EVICT NONE refuses the key past the limit instead:

DEFINE SPACE tickets MAX 2 EVICT NONE;
SET tickets:'t1' = 'ada';
SET tickets:'t2' = 'grace';
SET tickets:'t3' = 'hopper';

SpaceFull. Overwriting a key the space already holds is accepted, and so is removing one first:

SET tickets:'t2' = 'grace, row 4';
DEL tickets:'t1';
SET tickets:'t3' = 'hopper';
KEYS FROM tickets;

What holds under concurrency

The limit is checked in the commit, against the committed state. Two writers adding different keys at the same moment cannot both pass it: one of them sees the other's key when it commits. The keys the committing transaction writes are never the ones evicted, and a commit that alone adds more keys than the limit is refused with SpaceFull rather than trimmed — a cache that silently kept half of one write would be worse than one that said no.

Evictions are ordinary deletes carried in that commit's log record. A follower applies them and never evicts on its own, so every copy holds the same keys, and the change feed shows each eviction as a removal.

What the space says about itself

INFO FOR TABLE recent;

The definition comes back as DEFINE SPACE recent MAX 3, so a space re-created from it keeps its limit. MAX 0 is refused: a space that can hold nothing is a mistake rather than a configuration.

A space with a limit — TessariDB