3 ms·
This seems to keep the important bit about Redis single threading, that is that you have exclusive access to the db in a script or `multi`. That property allows
by nicpottier 8y ago
This seems to keep the important bit about Redis single threading, that is that you have exclusive access to the db in a script or `multi`. That property allows for a lot of things that wouldn't be possible otherwise. Also leads to very predictable performance characteristics.
That said, Redis has always been faster than I've needed, and that's leaning on it pretty heavily, so I kind of agree with antirez that adding this complexity may not come with much benefit. Will be interesting to see where this goes.
- rbranson 8y agoAccording to the README all access to the data is effectively single threaded. Only the network work is actually multi-threaded. > Access to the core hash table is guarded by spinlock. Because the hashtable access is extremely fast this lock has low contention. Transactions hold the lock for the duration of the EXEC command.
- jdsully 8y agoThis will be improved in future versions. One of my major goals is to make KeyDB work well for large value sizes, >1MB. There’s no reason you shouldn’t be able to cache images as well as text. FLASH support was the first step, and we’ve removed a bunch of unnecessary copies along the way but there is still more work to do.
- gtrubetskoy 8y agoFWIW - my notes on how locking was done in Thredis: https://github.com/grisha/thredis/blob/master/README-THREDIS https://github.com/grisha/thredis/blob/master/README-THREDIS
- jdsully 8y agoThanks! I did look at thredis originally, but the github seemed to not have been maintained at the time.