以下是精彩视频内容整理，主要内容为三个方面：
一、云原生数据库POLARDB;
二、POLARDB应用场景；
三、未来期待。
一、云原生数据库POLARDB
(一)业务发展中遇到的数据库问题
我们以典型的主备架构为例，左边这个图是一个双可用区（同城异地容灾）的高可用架构。这种典型的主备架构已经可以满足我们大多数的业务场景的需求。但是我们在实际的使用过程当中，也遇到了一些问题。
(1)升级变配慢
变配有可能发生数据迁移，可能需要数小时，甚至更久。
(2)新增只读节点慢
根据备份/日志大小，有可能需要数小时，甚至更久。
(3)存储空间有上限
存储空间跟计算规格关联，升级存储要同时升级计算规格，而且存在上限。
(4)主备延时
主库大表DDL后会导致备库延时，延时期间无法查询到最新数据。
(二)POLARDB从集中式到共享存储
POLARDB是一个从集中式到共享存储的架构的演变，也是一个原生的计算存储分离的架构。
最底层是一个分布式的共享存储，上面是计算节点。
优势：第一，存储计算分离，快速的新增只读节点，实例升降级。第二，存储分布式，最大100TB存储空间，分钟级备份。第三，基于redo log物理复制，只读节点延时更小。第四，智能代理转发，透明读写分离，负载均衡。
劣势：第一，DB节点扩展能力受限。第二，存储扩展能力及IO性能依赖高端共享存储。
(三)产品对比
将RDS与POLARDB从不同的维度做一个比较，如下图所示。
(四)基准测试对比
将POLARDB与Oracle作基准测试对比，基于单表5千万以上的存量数据做查询、写入和更新操作，比较不同规格的性能指标。测试结论如下图所示。
将POLARDB与RDS作基准测试对比，基于单表5千万以上的存量数据做查询、写入和更新操作，比较不同数据库间的性能指标。测试结论为，相同场景下POLARDB MySQL具有更大的吞吐量，但RDS的RT更快。
(五)POLARDB并行查询特性
POLARDB有并行查询特性，在存储层将数据分片到不同的线程上，多个线程并行计算，将结果流水线汇总到总线程，最后总线程做些简单归并返回给用户。
如下图所示，通过调整max_parallel_degree参数，使用8个并发线程执行后，性能提升了3倍。
二、POLARDB应用场景
(一)高并发读写
第一个场景是一个高并发读写的场景，存在大并发的这种复杂的读写和更新。而且业务上对响应的时间是比较敏感的，要求整个应用的响应时间不要超过一秒。如果超过一秒的话，有可能就会造成业务上的超时，影响交易。
有对相同规格的RDS、POLARDB主地址、POLARDB读写分离地址相同场景下测试，经过参数优化后的POLARDB主地址直连模式有更优的表现。优化后CPU的使用率相比优化前有所提高，使用率也相对稳定，不存在波动。
(二)新主从关系
新的主从关系，通过DTS数据同步服务把数据同步到POLARDB，POLARDB维护必须的索引、采用面向OLAP的引擎。利用POLARDB大存储、并行查询的能力。架构更灵活，POLARDB开启日志，所有数据访问需求通过这里进行汇聚与分发。
(三)拆分表聚合
分库分表的不好之处是，所有SQL都要带上拆分键，不支持全局二级索引，否则会全表扫描。当表特别大的时候，DDL变更会导致只读延时很久。如果把拆分的表聚合到一张表，利用POLARDB的并行计算能力，满足实时在线分析。对DDL进行控制，不耦合主库，则不存在主从延时。
三、未来期待
(一)存储成本
每个数据库都有自身的优势，我们可以结合自己的业务场景，还有一些成本的考虑来做好一些技术的选型。
POLARDB的存储成本相对来说是还是比较贵一点。如下图所示，这里包含计算节点的和存储节点的费用。总的来说，POLARDB计算资源性价比更高，存储成本相对高一些。所以说我们要结合业务场景，数据库本身的特性，还有成本来综合的考虑，做好技术选型。
(二)云原生+分布式+HTAP
最后提一下云原生，分布式和HTAP，这三个都是非常流行的技术。就像阿里数据库掌门人李飞飞教授所说的，原生数据库就像一辆跑车，而传统的数据库就像马车，会被淘汰掉。
云原生数据库，兼容开源的生态。我们在实际的使用过程当中有更多的诉求，希望它能够集HTAP事务处理和分析一体化，打造智能的企业级数据库。
关键词：POLARDB，云原生，数据库，分布式，并行查询
