2 ms·
yep this is exactly the plan :) But actually it will be a good idea to use such a feature only if data access is not evenly distributed across the dataset, othe
by antirez 17y ago
yep this is exactly the plan :) But actually it will be a good idea to use such a feature only if data access is not evenly distributed across the dataset, otherwise it's simply better to buy more RAM or more servers IMHO.
- anApple 17y agoNot if you are buying SSD disks. SSD disks offer very good random read performance, so it does make sense to use them for non often accessed items.
- antirez 17y ago"Very good" compared to normal disks. RAM is still much faster. Btw a setup to try is to use Redis with an SSD disk as swap, and load it with more data than RAM can hold and let the OS swap to see how it performs.
- skorgu 17y agoThis is superficially similar to how varnish [1] handles caching: mmap it all and let the OS figure it out. [1] http://varnish.projects.linpro.no/wiki/ArchitectNotes http://varnish.projects.linpro.no/wiki/ArchitectNotes
- liuliu 17y agoIMHO, that kind of plan (flush old data to disk and keep new data) is too much work and likely to hit both performance and durability. I'd like to see redis adding more features for production ready such as this one (append only log file). The RAM usage really is not a big deal since most people have their dedicated server and can easily add more RAM. Another question about the rewrite append only log file strategy. Will that have a possibility for loss data if the filesystem fails to recover from last power off? I mean, if you $rewrite$ a file, there is always a possibility.
- antirez 17y agoHello, actually the rewrite happens against another file and only when everything is ok it gets renamed atomically and the fd for next appends switched.