POLARDB v2.0 技术解读

回顾POLARDB 1.0

POLARDB 1.0 主要的改进包括采用了计算存储分离的架构，完全兼容MYSQL，性能是原生MySQL的6倍。一个用户集群可以在分钟级弹性扩展到16个计算节点，对业务完全透明的计算和存储分离代理，从库延迟仅毫秒级。存储为分布式块存储，可以弹性扩展至100TB的规模。存储层面采用多副本技术，使得数据库的RPO做到了0，完全没有丢失数据的风险。

POLARDB 1.0 完美的解决了传统数据库的如下痛点：

1、升级硬件需要迁移数据，升级周期长，无法从容应对突如其来的业务高峰。
（POLARDB的计算节点可以分钟级扩容，任何时刻发现业务量突变即可快速扩容。）

2、金融级可靠性要求RPO=0，传统架构使用实例层同步多副本，性能损耗巨大。
（POLARDB的存储为多副本，底层使用RDMA、Parallel Raft、3D Xpoint等最新的软硬件技术，性能比传统架构最高提升6倍。）

3、实例层复制HA架构，主从切换时间长，无法满足金融级连续性要求。
（POLARDB采用共享存储，主从切换可以做到秒级，同时在计算与业务层之间有一层代理层，代理层可以帮助用户识别计算节点的异常，自动切换，在大多数时候业务感知不到计算节点的切换，保证了业务连续性。）

4、传统HA架构采用主从异步复制，切换后从库可能需要重建，耗费资源多，重建时间长，存在长时间单点故障。
（POLARDB采用共享存储架构，主从切换不需要数据重构。）

5、每个只读节点都需要一份与主完全一样的副本，成本高。
（POLARDB采用共享存储架构，增加计算节点，不需要增加存储副本数，使得整体成本相比传统架构低很多。）

6、读写分离采用逻辑REDO复制，主从延迟高。
（POLARDB的数据存储为共享存储，不需要同步REDO数据，只需要同步REDO的位点，主从延迟在毫秒级。）

7、sharding架构没有想象的好，功能阉割、对业务有巨大侵入（限制SQL较多）。
（POLARDB完全兼容MYSQL，对业务没有任何侵入，用户不需要修改一行代码即可使用POLARDB。）

8、TB以上实例备份慢，往往数十小时。
（POLARDB使用快照备份技术，无论数据量多大，秒级备份）

POLARDB 1.0 已经发布两年以来，赢得了很多企业级客户的青睐。POLARDB 1.0已经很完美了，我们为什么还要研发2.0呢？

为什么要研发 2.0

1、用户的去O需求旺盛，却屡试屡败

为什么很多用户去O会屡试屡败呢？

1、企业有非常严重的历史包袱

1.1、企业通常技术栈为Oracle技术栈(团队)，适应其他产品的周期长，调头难

1.2、迁移如果涉及大量代码改造，周期长、风险高、收益低

1.3、通常目标引擎数据库Oracle兼容性非常差，用户需要大量的改造

2、缺乏有效的迁移方法、工具

2.1、迁移改造工作量很难评估，迁移周期很难评估，周期通常非常长（别人的成功去O经验无法复制