Relations that route — joins, FK placement, salting

Relations that route — joins, FK placement, salting #

A fact collection can now behave like one. Declare the relationship in the schema and the engine takes over:

"org_id": {
  "type": "keyword",
  "immutable": true,
  "references": {"collection": "orgs"},
  "routing": true,
  "ref": true
}

• Join queries are live — a semi-join over the wire: the inner query runs on the referenced collection, its matching keys become a membership filter on the outer side, and joins through a declared references field resolve without a second fan-out.
• Writes place by the foreign key’s value — hash(org_id) picks the home partition, not the document key, so an org’s facts colocate. Key-addressed operations take ?routing=<value> ( fetch, update, delete).
• Salting splits the hot org — when one routing value dominates, the _salting API spreads its writes across a partition SET (deterministic per key, round-robin for auto-IDs), with a terms feed that flags candidates against your threshold. Assignments are never auto-applied and searches stay oblivious — salting changes placement, never visibility.

One declaration, three consequences:

Salting (salt-split routing)

Salting (salt-split routing) #

Manage salt-split assignments for a collection whose schema declares a routing field ("routing": true). One hot routing value — the mega tenant, the biggest org — funnels every write into a single partition; salting splits that value across a SET of partitions so the hot key stops being a placement bottleneck.

The API never moves data by itself: assignments state intent, the write path consumes them live (the very next write of an assigned value lands inside its partition set), and migrating documents that are already placed is a separate rehash operation. The joins tutorial walks the complete sequence against a live node.