4 ms·
In Redis performance is the same regardless of the number of keys, there is no such an issue. But of course in Redis is easy because everything is in memory, an
by antirez 16y ago
In Redis performance is the same regardless of the number of keys, there is no such an issue. But of course in Redis is easy because everything is in memory, and we use O(1) data structures for lookups.
If you use Virtual Memory things are different of course, unless you almost always hit the part of the dataset fitting in RAM. With diskstore there is also to flush things on disk from time to time, so if the site is write-heavy regardless of the amount of memory you'll see a significant slow down.
Basically we think that for write heavy apps the default (in memory) is the way to go. Actually it is a bit different than that: everybody should run Redis in memory, but some specific applications where disk-backed makes sense.
- otterley 16y ago> in Redis is easy because everything is in memory Only by recommendation. You merely advise users not to allocate a DB larger than available memory. There's no built-in protection against overcommit, at least last time I checked (the documentation has been reorganized recently and I can't find the page that has the command-line arguments anymore). One could create a capped collection in MongoDB that was smaller than memory to achieve the same effect.
- antirez 16y agoSure there is, check 'maxmemory' directive. Especially in 2.2 it was extended a lot. You can configure it to simply trow error on writes once the limit is reached.
- otterley 16y agoMy point is that Redis doesn't automatically size maxmemory itself. Novice users can trivially make Redis perform awfully if their working set exceeds available RAM. (I don't consider this a flaw in Redis, BTW - it's just that a lot of implementors really don't understand operating systems and VM overcommit.)