Comparison between ApsaraDB for Redis and on-premises Redis

Compared with on-premises Redis databases deployed on your own servers, ApsaraDB for Redis has many advantages, such as high data security, easy O&M, and kernel optimization.

Item	ApsaraDB for Redis	On-premises Redis
Security protection	Supports Virtual Private Cloud (VPC) for network isolation. Supports whitelists for access control. Supports Secure Socket Layer (SSL) encryption. Allows you to create multiple accounts and grant different permissions to them. Supports audit logs, which allow you to view request records. The data sampling rate is 100%, and the performance consumption is less than 5%.	Requires a self-built network security system. It is difficult to construct such a system and brings high costs. Has data leakage risks owing to security vulnerabilities in the default access configuration of open-source Redis. Requires a third-party tool to implement SSL encryption. Has no account authentication system. Does not support audit logs.
Backup and recovery	Supports backing up data to RDB and AOF files. Archives the incremental data in the AOF file, which avoids the adverse impact of rewriting the AOF file.	Does not support backup and recovery. Rewrites AOF files irregularly, which deteriorates service performance.
O&M	Supports over ten groups of monitoring metrics and a minimum monitoring frequency of 5 seconds/time. Supports settings alerts based on monitoring metrics. Allows you to create instances of different architectures as needed and change the instance configuration. Provides accurate big key analysis based on the snapshots without performance consumption.	Requires a complex third-party monitoring tool to implement service monitoring. Stops services when you change the specification or the architecture. In addition, the specification or architecture change operation is complex. Supports big key analysis based on sampling, which is inaccurate.
High availability	Supports single-zone high availability. Supports zone-based disaster recovery. Uses an independent and central module to guarantee high availability, which is stable and highly efficient in decision-making. This module also prevents the split-brain issue.	Allows you to deploy high-availability architecture in an IDC based on the Sentinel mode. Allows you to deploy zone-based disaster recovery architecture based on the Sentinel mode. Depends on the Sentinel mode to guarantee high availability. The construction cost is high and the decision-making efficiency is low during service peak hours. Split-brain may occur, which brings loss to your business.
Kernel optimization	Provides performance-enhanced instances based on multithreading. The performance of a performance-enhanced instance is three times that of a standard-performance instance with the same configuration. Provides hybrid storage instances that store data in both the memory and disks. Hybrid storage instances can manage hot and cold data at the field level and effectively transfer data between the memory and disks. Supports cross-slot multi-key operations in the cluster edition.	Does not have a performance-enhanced edition. Supports systems such as SSDB or Pika as the persistent storage. However, these systems are not well compatible with the Redis protocol. They can manage hot and cold data only at the key level. Transferring big keys between the memory and disks is costly. These systems are difficult to manage. Does not support cross-slot multi-key operations in an open-source Redis cluster.