A COUNT that will stall the server
Each call is one operation on the single thread, so a huge COUNT is a pause
keyspace-size: 10000000 count: 50000
Plan a SCAN loop. Two things about it are routinely assumed and wrong: COUNT is a hint rather than a page size, and the same key can be returned more than once in a single iteration.
Or drop a file anywhere on this panel. Nothing is uploaded: the analysis runs in this tab.
The answer appears here
Paste on the left and press Plan. Nothing leaves this tab.
Nothing else to flag.
No formatting problems, and nothing the rules object to. Worth remembering what that covers: this reads the file you pasted, not the account or cluster it will be applied to.
No finding matches that filter.
Real input you can load into the tool above. Each one shows a different thing going wrong, because that is what the tool is for.
Each call is one operation on the single thread, so a huge COUNT is a pause
keyspace-size: 10000000 count: 50000
SCAN answers for one node, not for the cluster
keyspace-size: 5000000 count: 500 cluster: yes
These are the ones that fail silently. The config is accepted, nothing raises an error, and the consequence arrives later.
SCAN can return the same key more than once, so the total overcounts.
Instead:Deduplicate on the client, or use DBSIZE.
An empty batch with a non-zero cursor is normal, especially with MATCH.
Instead:Stop only when the returned cursor is 0.
It does make each call more productive, but it also makes each call longer, and MATCH never reduces the work done.
Instead:Balance it; a few hundred is usually right.
You see only the slots that node owns.
Instead:Iterate every primary and combine.
SCAN is the safe way to walk a keyspace, and its contract is weaker than most code assumes.
The guarantee is that a key present for the whole iteration is returned at least once, and that a key absent throughout is never returned. Keys added or removed during the scan may or may not appear, and any key may appear repeatedly. Code that counts by summing batch sizes overcounts, and code that acts on each key must be safe to run twice.
The server uses it to decide how much to do per call and may return more keys, fewer, or none at all while still returning a non-zero cursor. An empty batch does not mean the end. The iteration is finished when the RETURNED cursor is 0, and nothing else.
The pattern does not make the scan cheaper. The server still walks COUNT keys and then discards those that do not match, so a selective pattern over a large keyspace produces many empty batches while paying full cost for each. Raise COUNT when the pattern is selective.
Each call is a single operation on the one thread. A large COUNT trades round trips for a longer pause per call, and past a few thousand that pause is measurable by every other client. A few hundred is the usual working range.
Each node has its own cursor space and its own slots. Scanning one node and treating the result as the keyspace silently sees a fraction of it. Every primary has to be iterated separately.