ApsaraDB for PolarDB is designed for business-critical database applications that require fast performance, high concurrency, and automatic scaling. You can scale up to millions of queries per second and 100 TB per database cluster with 15 low latency read replicas. ApsaraDB for PolarDB is six times faster than standard MySQL databases, and delivers the security, reliability, and availability of traditional commercial databases at 1/10 the cost. ApsaraDB for PolarDB embodies the proven database technology and best practices honed over the last decade that supported hyper-scale events such as the Alibaba Double 11 Global Shopping Festival.
On November 11, 2018, ApsaraDB for PolarDB successfully supported 1 billion orders in 24 hours, during which the number of queries received per second spiked by 122 times.
- Large storage capacity PolarDB supports up to 100 TB of data. You can scale out an instance up to 16 nodes and each node supports up to 88 vCPUs. PolarDB also automatically adjusts the storage space based on your requirements. Fees are charged based on the storage that you use, helping you lower development costs.
- Top performance and quick response to a sudden load PolarDB decouples compute and storage resources, giving it 6 times faster than standard MySQL databases in high concurrency scenarios. The compute and storage nodes are optimized to increase resource utilization rate. A single node can handle up to 1 million QPS and takes less than 5 minutes to be added.
- High stability and data security PolarDB uses the ‘one primary node, multiple replicas’ architecture, in which all read/write and read-only nodes of the same instance access the same replica, greatly reducing storage costs. PolarDB also supports active/standby switchovers to prevent data loss and data inconsistency caused by asynchronous replication. Read-only replicas can be created within minutes to back up and restore data.
- High compatibility ApsaraDB for PolarDB is fully compatible with MySQL. You can migrate data to Alibaba Cloud without modifying the code. ApsaraDB for PolarDB will soon be fully compatible with the PostgreSQL and Oracle engines.
Compute and Storage Decoupling
PolarDB has optimized the performance of CPUs and memory, and reduces the costs of storage.
Dedicated compute and storage features
Compute nodes (DB servers) execute SQL statements, read data, and write data. Storage nodes (data chunk servers) store data and database snapshots and are grouped into clusters.
Improves resource usage and computing performance
PolarDB is 6 times faster than standard MySQL database in handling large amounts of concurrent queries. Each node can handle more than 1 million QPS, and it takes less than 5 minutes to scale out the number of compute nodes.
On-demand storage capacity
When you purchase an ApsaraDB for PolarDB cluster, you do not need to specify the storage space.
For ApsaraDB for PolarDB, all nodes in a cluster share the same replica stored on storage nodes.
Large storage capacity
Each ApsaraDB for PolarDB cluster supports to scale up to 100 TB and can be scaled out to up to 16 nodes. Each node can have up to 88 vCPUs.
Quick scale-out of read-only instances
You do not need to replicate data when adding read-only nodes. A read-only instance can be created in a few minutes.
Free storage for read-only instances
To add a read-only instance, you only need to pay for the compute nodes. There are no storage fees for the read-only instance.
RDMA-capable network and optimized backup feature
ApsaraDB for PolarDB supports RDMA-capable networks and the latest PAXOS block storage technology.
Quick data backup and recovery
ApsaraDB for PolarDB enables you to back up data in a few seconds. When a node fails, you can simply restart the process to resume the service.
A full backup within minutes
ApsaraDB for PolarDB features the copy-on-write technology that create a snapshot in a few seconds, or create a full copy of the data in a few minutes.
Zero data loss during primary and secondary switchovers
This resolves the issue of data inconsistency between read-only and read/write nodes caused by asynchronous replication.
Quick data migration
ApsaraDB for PolarDB supports easily migrating RDS for MySQL 5.6 databases to ApsaraDB for PolarDB.
For more information, see the ApsaraDB for PolarDB documentation.
Learn How Alibaba Cloud's Databases Could Support 87 Million Transactions per Second
Uncovers how ApsaraDB for PolarDB maximizes its performance in transactional scenarios.
All-New High-Performance PolarDB Box, Completely Compatible with Oracle
Introduces the features of PolarDB Box and the best practices for Oracle scenarios.
Seizing the Opportunity in the New Cloud Native Battlefield
Introduces the technical benefits of ApsaraDB for PolarDB.
PolarDB: A Technical Guidebook
PolarDB User Guide
Creating a Robust Cloud-Based Database for Fintech, E-Commerce and Gaming
Introduces typical industry solutions of ApsaraDB for PolarDB.
Introducing Alibaba Cloud's Database Solutions
Describes how Alibaba Cloud database services support and secure your workloads.
ApsaraDB for PolarDB is widely adopted by users in New Retail, Gaming, Internet Finance, and Live-streaming.
PolarDB supports scenarios challenged by high concurrency and sudden traffic volume increase, such as in promotions and flash sales. Instances can be scaled out within seconds, meeting the read/write requirements for enterprise-level large-scale data analysis. Scale-out events can be quickly implemented and the availability of database clusters is enhanced, while keeping storage costs at a minimum.
Due to the limitations of traditional MySQL databases, such as the use of physical disks and traditional data backup technology, a MySQL database is typically no more than 3 TB. To keep up with the rapid growth of data, you have to scale-out clusters, migrate data, and shard databases. This not only increases development costs but also causes service interruptions.
In a traditional storage architecture, read/write and read-only nodes have their data replicas. If you want to add a read-only node, you have to replicate all of the existing data. Typically, the full replication process is time-consuming, making this scaling option inefficient.
Data Consistency and Availability Limitations
Traditional MySQL read/write nodes and read-only nodes use incremental synchronization to sync data, which takes time to reach read consistency on both nodes. If an application retrieves data from the read-only node, the consistency of the data read cannot be guaranteed. In addition, the synchronization delay may also adversely affect node switchover and cluster availability.
Upgraded Support For You
1 on 1 Presale Consultation, 24/7 Technical Support, Faster Response, and More Tickets.