3 ms·
One of the easier things to do is pull out all the counters and sessions and put them in Redis or Riak. No use in tying up your database doing things it is not
by megaman821 15y ago
One of the easier things to do is pull out all the counters and sessions and put them in Redis or Riak. No use in tying up your database doing things it is not well suited for anyway.
- sehugg 15y agoYes, Redis rarely keeps me up at night, besides making me worry about what I'll do when I run out of RAM :)
- antirez 15y agoIn a "just counters" scenario you can't imagine how much data a single Redis server can hold! It is sensible to understand when it is a good idea to use a database that holds data in memory, as there are obvious limits (that are are trying to break in a comfortable way with Redis Cluster instead of forcing client-side sharding), but on the other hand it is good to do some math before being worried. Example: Redis can hold 1 million counters, every counter stored in a different key, for every 200 MB of memory. This means 5 million counters per gigabyte. Clearly you can have a lot of counters. But you can make this figure a lot higher if you aggregate counters using hashes: with this trick when applicable the above figure will be five times bigger.
- mike_esspe 15y agoCan you hint how many distinct counter increments can i expect to have per second with Redis?
- antirez 15y ago100k increments per second in an entry level Linux box. 50k increments in a decent EC2 instance. 150k - 180k increments per second in a fast modern Linux box.