I scoured stack overflow and reddit trying to gather as much information as possible and wanted to ask for suggestions on which caching solution to use for the following use cases (with persistence in mind)migrating from ehcache and if any of the 3 will make the migration easier :
- Caching profiles and metadata of users on caching layer
- Notifications with firebase for tokens on multiple devices
- Caching Profiles of users available on siebel in cache at cutover times
- Caching as a service on openshift exposing end points for the developer to use
from my understanding couchbase works best when your data is in document format and when you want to perform multiple queries, but for simple get/set redis and aerospike excel. If I understand correctly redis is single threaded in memory and aerospike is multithreaded with in memory available but can add the indexes to the in memory and the actual data is on the ssd. Does aerospike have the cache concurrency overhead since it’s multithreaded ? also if I will persist data probably won’t be on every write but will that make redis slower to the extent that aerospike would be better ? Any suggestions and clarifications are highly appreciated .
2
Answers
Full disclosure, I’m a Couchbase employee, and these kind of opinion-based questions are not what Stack Overflow is for.
However, just to give you a few more facts to help you in your search:
Aerospike Database 7 has several advantages as a cache. TLDR: the ability to store data persistently in-memory without a disk persistence layer, extremely fast restarts, inline compression.
When you configure a namespace to run on
storage-engine memory
, its data gets stored in shared memory slices, basically RAM devices. This means that when you take down the Aerospike daemon (asd), for example to upgrade it to a new patch release, the data is still there when you restart. The server doesn’t need to reload data from a disk persistence layer back to memory, so the process of upgrading and restarting a node is extremely fast.If you configure data storage to be in-memory and don’t define a disk persistence layer, asd will also successfully restart off a crash and still have the memory fully present. In the event you need to restart the host, the Aerospike shared-memory tool (ASMT) allows you to just-in-time copy the data from shared memory to a persistent device like EBS, restart the host, and load this data back to shared-memory for a fast restart.
Aerospike also gives you the ability to do inline compression of data with support for several compression algorithms. This feature lets you squeeze more data into the same amount of memory.
For reference
I’m the product manager for Aerospike Database, so take that into account that I’m biased.
To answer your other question – Aerospike does a lot of things correctly to maximize performance, such as being cache coherent (the per-record metadata in the primary index is 64 bytes for a reason). It’ll provide the predictable low latency you need, but you should test it for yourself. You have access to do anything you want with a single-node instance of Enterprise Edition – just grab a container image and try it for yourself, or use Aerolab.