-
Notifications
You must be signed in to change notification settings - Fork 1.1k
Milestone
Description
Problem
Search commands in Cluster tend to stick to a single primary and cursor pagination can be misrouted when follow‑ups hit a different node than the one that created the cursor. We want behavior that matches RediSearch policies without client scatter/gather or client‑side result merging.
Goal
- Sticky cursors:
FT.CURSOR READ/DEL
go to the node that created the cursor by propagating Cursor object. - Balanced routing: “Keyless” RediSearch commands spread across all nodes for fairness and throughput.
- *Keep SUG key‑based:** Suggestion commands stay hash‑slot routed to the owning primary.
Commands covered (v1)
Balanced across all nodes (keyless policy):
FT.SEARCH
,FT.AGGREGATE
,FT.EXPLAIN
,FT.LIST
,FT.SPELLCHECK
,FT.TAGVALS
,FT.SYNDUMP
,FT.DICTDUMP
Sticky cursor:
FT.CURSOR READ
(route back to creator node)FT.CURSOR DEL
(route back to creator node)
Hash‑slot (unchanged, dictionary key):
FT.SUGGET
,FT.SUGLEN
,FT.SUGADD
,FT.SUGDEL
Admin (primaries only):
FT.CREATE
,FT.ALTER
,FT.DROP*
,FT.ALIAS*
,FT.SYNUPDATE
,FT.DICTADD
,FT.DICTDEL
Policies (what & why)
-
Request policy
- Keyless: May run on any primary → we balance calls for better throughput and fairness.
- Hash‑slot: Must run on the slot owner primary (suggestion dictionary is a real key).
- Sticky: Cursor follow‑ups must return to the same primary that created the cursor.
-
Response policy
- Single‑node response. Any internal scatter/gather is handled by RediSearch; the client does not broadcast or merge results.
Why now: Improves reliability (cursors), spreads load, and aligns with RediSearch behavior—without risking correctness by doing client‑side fan‑out or reductions.
Metadata
Metadata
Assignees
Labels
No labels