Why upgrade Concurrent map cache to Redis?
Concurrent maps in java have always been an old school caching method, easy, native, fast and no external dependency makes it perfect choice for legacy code lovers and if you are still using this in your project now is the time you upgrade and here are some reasons why I suggest to
Concurrent map memory constraint
Cache is very similar to Concurrent Map, but it isn’t exactly the same. The basic difference is that a Concurrent Map persists all elements that are added to it until they are explicitly removed. A Cache on the other hand is generally configured to evict entries automatically, in order to constrain its memory footprint. This alone eviction policy implementation is an overhead, why re-create the wheel when you’ve got Guava or it’s java 8 version Caffiene is here to do it, it’s documentation states
Generally, the Guava or Caffiene caching utilities are applicable whenever:
· You are willing to spend some memory to improve speed.
· You expect that keys will sometimes get queried more than once.
· Your cache will not need to store more data than what would fit in RAM. (Guava caches are local to a single run of your application. They do not store data in files, or on outside servers. If this does not fit your needs, consider some other tool.)
As it says they do not store data in files or outside servers, then a popular and modern outside server option could be redis.
What is Redis?
Redis website says it like this:
Redis is an open source (BSD licensed), in-memory data structure store, used as a database, cache and message broker. It supports data structures such as strings, hashes, lists, sets, sorted sets with range queries, bitmaps, hyperloglogs and geospatial indexes with radius queries. Redis has built-in replication, Lua scripting, LRU eviction, transactions and different levels of on-disk persistence, and provides high availability via Redis Sentinel and automatic partitioning with Redis Cluster.
When to use Redis?
If you need more than just caching! A software written in multiple languages will use your cache! Then use Redis. Found beautiful someone explaining on Stackoverflow while comparing memCache and Redis:
Redis is not just a cache, it can be viewed as a key value storage (database — like) where the data is stored on a machine in the RAM memory, but it can also be flushed to disk (to keep it persistent).
You’ll almost always want to use Redis because of its data structures. With Redis as a cache, you gain a lot of power (such as the ability to fine-tune cache contents and durability) and greater efficiency overall. Once you use the data structures, the efficiency boost becomes tremendous for specific application scenarios.
Redis’ superiority is evident in almost every aspect of cache management. Caches employ a mechanism called data eviction to make room for new data by deleting old data from memory. Memcached’s data eviction mechanism employs a Least Recently Used algorithm and somewhat arbitrarily evicts data that’s similar in size to the new data.
Redis, by contrast, allows for fine-grained control over eviction, letting you choose from six different eviction policies. Redis also employs more sophisticated approaches to memory management and eviction candidate selection. Redis supports both lazy and active eviction, where data is evicted only when more space is needed or proactively. Memcached, on the other hand, provides lazy eviction only.
Redis gives you much greater flexibility regarding the objects you can cache. While Memcached limits key names to 250 bytes and works with plain strings only, Redis allows key names and values to be as large as 512MB each, and they are binary safe. Plus, Redis has five primary data structures to choose from, opening up a world of possibilities to the application developer through intelligent caching and manipulation of cached data.
When you dive in to the caching options for your project, I would surely suggest you to review Redis, use its maximum features you want to use to make your application faster and better.