Hi,
As per documentation, understood the valkey in cluster mode and sentinel mode but what are the main differences between them and when to use each?
Apart from the advantage that cluster mode supports horizontal scaling while sentinel doesn’t support scaling? any other things to consider which mode to consider in our environment
Hello @josephtryit
Sentinel’s are only used for managing/monitoring failures. Client applications will not connect to Sentinels to execute commands (client will connect to sentinel to discover primary/readers, then connect directly to correct node). If you have any type of replication, you should have sentinel’s to manage failover.
Hi Matt, Yes but in terms of client application, i can still use client which is cluster aware and connect to valkey in cluster mode instead of sentinel as i get the same benefits and scaling on top of it. Cluster mode mechanism can also auto failover and high availability can be configured and clients who support cluster aware can still identify the primaries/readers so any benefit of using sentinel if cluster mode can achieve all of it?
Note: cluster mode and sentinel cannot be combined
I’m also interested in this question
As I understand Sentinel it is analogous to replication, where the same data resides in multiple replicas. This is for fault tolerance and reliability, possibly for load balancing between replicas.
Cluster is analogous to sharding, for distributing large amounts of data across multiple servers, for example, if they do not fit into the memory of a single server.
1 Like
Sentinel is not for write scaling. Sentinel is for HA. Imagine a PRIMARY and two readers. Sentinel handles the failover by changing reader1 into the new PRIMARY and reconnecting reader2 to replicate from reader1-PRIMARY. The same data exists on all 3 nodes. If you have a relatively small dataset, replication+sentinel is a quick HA solution (with some read scaling in using the standby readers).
Clustering is sharding. The entire dataset is split between N servers (ie: userid 1-1000 on node1, 1001-2000 on node2, etc). If you have a massive dataset, or need to scale writes, use clustering. There is no HA by default (you can add readers and clustering will manage failover). If node4 goes down, then you’ve lost that data shard.
1 Like
Thankyou. what is the vertical size limit for a single writer or reader in sentinel mode before we convert to cluster mode for sharding. Is it as much as the virtual machine supports or any recommended limit best suits for valkey?
For comparison with redis enterprise its 25gb cache size recommenced per shard and need to add 2nd shard beyond that(1 shard per every 2gb increase) so will this formula be same for valkey? If yes, the max cache size a valkey cluster in sentinel mode supports will be 25gb as well beyond which we use cluster mode with sufficient readers for HA
Pretty much. I see no reason why you’d want to limit at 25GB (unless you’re trying to increase your license sales 
)
There is a bit of a game to play. Too much cache size, and you’ll be overloading the server with lots of requests because that’s the giant bucket were everything goes. Then you’d lower the cache (lowering the instance type/ram requirements), and shard to multiple nodes whereby the total cache across all nodes == dataset size.
1 Like
As I understand Valkey has no limitations and the only limitation is the amount of RAM, but now available servers and with terrabytes of RAM.
Another question is of course the performance and speed of execution of queries on such a volume of data, probably here the division into shards using Cluster will be more effective, if you divide the data correctly.
1 Like
what about number of cores. I am sure each core can only do something/support certain throughput(ops/sec). Example: we can’t have 2 cores with 128gb RAM for a 100gb cache size with 100k ops/sec or 10gb cache with 100k ops/sec. So how to determine the number of cores needed for my cache data set?
Again comparing the same with redis enterprise, they recommend/formula is 1 core per 25k ops/sec per shard and one core per dmc proxy thread and 2-3 cores for OS. How can we calculate the same for valkey
That’s not how you do it. You don’t equate cores to data set. Redis/Valkey are both single-threaded, except in some IO cases. Once CPU starts hitting 80%, you start sharding/clustering to spread the load. Valkey does not scale vertically (eg: more cpu, more $$).
The “formula” you are referring to is simply to optimize hardware efficiency:
Multi-Tenancy in Redis Enterprise - Redis By having more cores, you can run more instances of Redis on a single server. It’s no different for Valkey.