最新动态
PolarDB 存储包，越用越便宜
如果您需要存储大量数据（例如1,000 GB或更多数据），则存储计划更具成本效益。即刻使用PolarDB存储包，即刻节约存储费用。
了解详情 >
PolarDB MySQL 8.0 历史库商业化
历史库使用单节点架构，最大容量支持200TB，X-Engine做存储引擎，最高节省70%的存储成本，适合订单、消息等数据的归档存储需求。
了解详情 >
PolarDB：开启云原生数据库时代，实现生产力的腾飞
揭秘面对业务的增长和突发的请求洪流，PolarDB 如何将挑战转变为信心
云原生关系型数据库 PolarDB MySQL 版
100%完全兼容开源MySQL和云数据库 RDS MySQL 版
学习如何使用 >
云原生关系型数据库 PolarDB PostgreSQL 版
存储计算分离，极致的弹性能力，更少的开销
学习如何使用 >
云原生关系型数据库 PolarDB Oracle 版
高度兼容 Oracle 语法，支持从任意Oracle版本迁移
学习如何使用 >
PolarDB是专门为业务变化快、高并发、有自动扩展需求的关键业务场景而设计的数据库。单实例可通过增加15个低时延只读实例扩展为集群，达到数百万QPS和最高100TB存储空间。PolarDB的速度是标准MySQL数据库的6倍，只需传统商业数据库1/10的成本，就能享受同等甚至更好的安全性、可靠性和可用性。PolarDB经受过诸如双十一全球购物节这类超大规模活动的考验，很好地体现了过去十年阿里巴巴所打磨出的成熟数据库技术和最佳实践。
2018年11月11日，PolarDB在24小时内成功支持了10亿个订单，期间每秒收到的查询量（QPS）激增122倍。
业界领先的优势
- 支持数据海量存储 PolarDB支持最大容量100T，最多可横向扩展16个节点，每个节点最高88 vCPU，Serverless分布式存储空间根据数据量自动伸缩，仅须为实际使用的容量付费。
- 极速弹性应对突增负载 采用计算&存储分离架构，摆脱CPU、内存和磁盘互相制约的困扰，对计算和存储节点进行了针对性优化，大幅提升了资源利用率与性能。高并发场景下相比传统MySQL性能最高提升6倍，单节点最高100万QPS，增加计算节点只需5分钟，快速弹性应对突发业务负载。
- 数据安全可用 PolarDB采用“一主多从”架构，同一实例的所有读写和只读节点都访问存储上的同一个数据副本，极大降低了用户的存储成本。可实现主备切换0数据丢失，彻底解决了异步复制带来的只读节点数据与读写节点数据非强一致缺陷，几分钟内即可扩展只读副本，备份和恢复数据。
- 与多种数据库引擎兼容 PolarDB完全兼容 MySQL，不需修改代码即可以迁移到阿里云的企业数据库平台。PostgreSQL/Oracle兼容引擎也即将在国际站上线。
精心打造的功能
计算与存储节点分离
PolarDB对计算层关注CPU与内存性能的优化，对存储层关注低成本的存储实现。
计算与存储功能划分
计算节点：主要承担SQL解析以及存储引擎计算。
存储节点：使用存储集群，主要承担数据块存储和数据库快照。
计算节点和存储节点之间通过RDMA网络连接。
提升资源利用率与性能
高并发场景下，PolarDB相比传统MySQL，性能最高提升6倍，单节点最高100万QPS，增加计算节点只需5分钟。
存储单独购买
在购买实例的时候不需要指定购买的磁盘大小，存储单独购买，按量付费。
共享存储
同一个实例的所有节点都访问存储节点上的同一份数据。
海量存储空间
PolarDB支持最大容量100T，最多可横向扩展16个节点，每个节点最高88 vCPU。
快速扩展只读实例
只读实例的扩展不需要拷贝数据，创建新的只读实例只需几分钟。
不需单独增加存储成本
新增只读实例仅需要付出计算的成本，不需要单独增加存储成本。
RDMA网络和备份优化
借助了优秀的RDMA（Remote Direct Memory Access）网络以及最新的PAXOS块存储技术。
秒级数据备份和恢复
PolarDB 的数据备份耗时可以缩短到秒级，服务器宕机后无需搬运数据，重启进程即可恢复服务。
分钟级全量备份
使用了Copy On Write技术，实现秒级快照，分钟级全量备份。
主备切换0数据丢失
彻底解决了异步复制带来的只读节点数据与读写节点数据非强一致缺陷。
从RDS一键迁移PolarDB
目前 PolarDB数据库内核支持从RDS for MySQL 5.6一键迁移到 PolarDB。
迁移流程详见产品文档
应用场景
-
PolarDB典型应用场景
PolarDB典型应用场景
广泛应用于新零售、游戏、互联网金融、社交直播等行业客户。
轻松应对高并发的应用场景，在促销、秒杀等流量峰值的场景中实现秒级扩容，支持企业应对大规模数据分析的读写需求。实现海量数据低成本存储、快速弹性扩容，保障数据库集群可用性。
能够解决的主要问题
-
数据量瓶颈
传统MySQL数据库，数据增长过TB后需要定期扩容、迁移、拆表，开发成本高，还可能造成业务中断。太大的实例将是运维的灾难。
-
扩展难
传统只读实例备份技术，读写实例和只读实例各自拥有一份独立的数据，新建一个只读实例需要重新拷贝数据，将极大影响只读实例的快速扩展。
-
数据一致性和可用性难保证
传统读写实例和只读实例通过增量逻辑数据同步，导致主备延迟非常普遍，这会影响应用从备库读取数据的一致性，也影响各种切换任务和集群可用性。
推荐搭配使用
