The proper way of partitioning data in Elasticache (Redis) - amazon-web-services

Question

We are using Elasticache(Redis) to implement a caching layer for our cloud platform. It has a mongodb back end. We use Node.js and Java to access these data in different different platform components.
Node.js example code is given below,
var redisClient = require('redis').createClient(config.aws.redis.port, config.aws.redis.endpoint, {no_ready_check: true});
var redisKey="urls_"+url;
redisClient.get(redisKey, function (redisErr, reply) {});
In the redis cache we cache different categories of data. Say X, Y, Z. Currently we store them in single redis node. And we use namespace prefix to partition data.
Ex,
key ="X_"+url
key ="Y_"+money
key ="Z_"+length
But I cam across this article and it says its better to avoid name spaces. http://www.mikeperham.com/2015/09/24/storing-data-with-redis/
So what is the best solution for our use case?
Having different redis nodes per different data partition,
X type data will be cached in A redis node
Y type data will be cached in B redis node
Z type data will be cached in C redis node
Using multiple redis dbs in single redis node?
X type data will be cached in 0th DB of A redis node
Y type data will be cached in 1st DB of A redis node
Z type data will be cached in 2nd DB of A redis node

Answer 1

For elasticache, it is generally better to store each set of data in its own cluster.
the primary downside of having multiple cluster is the management overhead, but with elasticache, most of that is managed, minimizing this downside.
while scaling your elasticache cluster is managed, it still needs to move data around -- the more data you have in a single cluster, the longer it will take to scale it, and more performance impact you will suffer while doing online rescaling.
as for cost, by splitting data into multiple clusters, each cluster can use smaller instances. In the end, it may cost about the same.
Of course, there are always exceptions, and you should consider those issues within your unique context.