Thanks for the replies/feedback, appreciated!
Someone on Stackoverflow also answered:
KeyDB, in fact, only runs the IO operations and Redis protocol parsing operations in parallel. It processes the commands in serial, i.e. process commands one-by-one, and working threads are synced with a spin lock.
This seems to be in line with what you say Bob. I have not myself tested doing a long query on one key (“key1”) and then doing many operations on another key (“key2”); does KeyDB block then? This is actually what @jgaskins is asking also, “how granular is that lock”, that question is very relevant.
To answer your question:
In my world, without getting into how it would be implemented, I could and would accept that whoever asked first gets the result as the state was when it was asked. So, if I do a “get all” on a large hash, and then during that fetch, someone edits the same hash, I get the results as they are when I fetch them.
If a hash has 1M entries, and my query is building the result-set, and I get to 500k, and then someone edits the 499k-entry then I have the previous version in my result-set since I fetched it before the edit. If someone edits the 501k, then I will probably get that when my query gets that far. If someone deletes the key altogether, I would be fine with getting the hash as it was if they didnt delete it (read into a separate store or whatever).
This is the same as with any SQL db:
If I start doing a large SELECT query, and someone starts deleting rows from the same table, then I normally dont have to wait for the large SELECT query to finish, the DELETEs can go on. InnoDb has as far as I know row-locking, not table-lock