PolarDB PostgreSQL版：商业数据库替换与企业上云首选
内容介绍：
一、PolarDB技术架构
二、PolarDB弹性、性能、降本与多模特性更新
三、商业数据库替换与上云解决方案与案例
本次演讲将介绍PolarDB for PostgreSQL弹性、性能、成本、多模等方向上新的技术突破，包括Serverless、HTAP、冷热数据自动分层、Ganos多模引擎等，同时介绍产品在汽车、交通、零售等行业上云和商业数据库替换的典型案例。
一、PolarDB技术架构
首先，回到基本问题，客户在上云合作商业数据库替换当中，到底是该稳妥的使用原来的传统的储备式单点式的这种架构，还是在云上使用云原生的像polarBD这样的云原生的架构数据库。我们是坚定的认为，在云上面最理想的选择是使用像polarBD这种云原生的数据库的架构。
polarBD架构的优势，第一就是实现了存储计算分离和共享存储，这样会让它具有极致的弹性和扩展性。可以加一个通过只读节点的方式扩展计算资源，可以无缝的支撑业务负载的图层。
其次因为供养存储的，所以它的各个节点之间不需要做这种磁盘数据的同步，解决了传统的那种祖辈式架构延，祖辈延迟不可控的这种这个问题而言，确保了这个稳定性。
最后由于是存储计算分离，所以存储是充分共享的，所有的计算节点也可以被集群化的访问，这样提高了资源的利用，就相对于主备室的架构会有很大的提高，为客户做降本奠定了一个基础，除了这些架构带来的优势以外，这个产品的各个层次进行不断深度优化，比如在性能方面，是在持续的做优化，那这样让产品虽然是存储计算是分离的，但用了io汇总网络，它的性能不仅不比原来的本地盘的这种数据库性能差，而且还要好得多。
再比如在这种智能代理层做了深度的优化，支持了内置的连接池能够大幅度的减少空闲连接和对于资源的消耗。
另外支持无缝的无感的切换，能够在实地做升降，还有版本升级时做到连接不断，因此就是基于架构的优势，和持续的优化，这是要让polaeBD云原生的架构，从成为上云和3g数据库替换当中的最佳的一个选择。
二、PolarDB弹性、性能、降本与多模特性更新
1、在弹性方面更新
polarBD的弹性本来就是共享存储的架构，所以它添加节点非常方便，它就本来就有一个非常好的弹性，在此基础上，我们又做了两个增强。一个是推出了这个serverless形态，那这个serverless形态可以做到每秒就可以抬升一个pcu的极致弹性，同时polarBD架构可以支持纵向的抬升以外，就是每个节点的资源可以秒级抬生。
另一方面还可以根据需要去动态的加减节点，可以横向的进行扩展，这是polarBD架构所特有的，我们也有客户，就是用到了这个特性，在业务的顺利度过业务高峰可这是polarBD的service的一个独特的优势，另一个增强是实现了全局一致性，是在对于一致性要求比较高的，类似金融的这种应用，是不能接受，各个节点之间的数据不一致，我们在实现了这个全局一致性以后，这部分应用可能占到整个所有客户应用的里面的20%、30%是可以实现的，它可以访问所有的节点，享受这个弹性所带来的好处，那这个全局一次性的能力也很快会在个控制台里面去看到，在9月份9月底之前应该能就能看到，这是polarBD在弹性方面的一个增强。另外，在性能方面，polarBD有专门的人员持续在做性能上的优化。
在性能优化主要有两个方向，第一个方向是在交易型ORTB的情境下进行，这种场景下面的性能优化。第二个方向是在复杂查询的大数据扫描方面做优化，第一个方向上面，在过去的一年里面，至少我们的性能提升了30%以上。同时，友商也在不断的提升，就最新的这个的测试对比里面，无论是CPU型还是LO密集型的这种场景。我们都相较于友商和用户自建的ess形态的性能领先2倍到4倍。
比如在CPU这种密集形成里面，我们主要做的优化就是这种OS还有编译层面，还有这种事物层面等等。全方位的优化在IO上面是借助于polarBD的强大的IO能力，带来的优势，是可以保持性能上的领先。
另外一个方向就是在复杂查询上的性能优化，借助于很早就有一个功能：1PK。1PK是单个的查询，可以放在多个io节点上去执行，又借助这个能力是可以让查询把所有的资源都用上的。
2、性能方面更新
在提升查询的性能方面，很多客户也是因为这个特性而没有选择那些mpv的数据库，而选择polarBD体系来做查询的加速。最近又推出了一个向量化加速引擎，向量化加速引擎是用same的批量批处理的CPU指令，再加上代码级的批处理的优化，能够让我们的查询大幅度的提升，在tbc标准测试里面，同样是pd这种单机并行，现代化引擎的并行，同样的并行度在性能和数量级上面有提升。
3、成本方面更新
我们和云安全中心合作，利用阿里云现在已有的一系列安全的防护措施能够对模型的VPC的访问的控制，能够对于模型相关的这些存储计算网络等等产品的安全配置进行检查从而保证除了AI系统之外，周边系统上下游系统也始终处于一个安全的可控的状态，这样进一步提升了整体AI系统的安全性。
总的来说PAI是基于保护数据和隐私安全、优化和治理算法推理的结果保证模型的可用性和机密性，来最终实现一个可信的AI，未来我们也期望和更多的企业和开发者一起携手共建安全的可靠的值得信赖的AI。
下面是在成本上的优化，那第一个是压缩能力，很早推出了pl4这种磁盘类型。现在，在此基础上psl4支持压缩的能力，这种压缩能力能够让压缩存储成本再降低40%左右是非常可观。最重要一点，压缩是不同于软件压缩，一般软件压缩会消耗系统的CPU自然会让整体的存储量降低，此次是一个硬件压缩，是借助于存储端的fft能力去实现压缩和解压。因此，对整体性能的影响在5%以内其是可以忽略的。
另外一个降本的能力是冷热数据分成，冷热数据分成，有一个明显的特征，是使用了云盘作为缓存，也就是说，数据是先放到对象存储上面，但是你在访问的时候可以设定一些规则，或者根据你RRU的原则可以自动会加载到我们云盘上面，下次再去访问这部分热数据的时候，速度就会很快。
解决方案相对于其他的这种归档，有几大优势：第一是他对于所有的circle的语法，包括ddl等功能是全兼容的。甚至说索引扫描也就是索引访问也是全兼容的，就是像普通数据一样去使用这部分数据。
第二是性能会非常好，特别是写的性能可以基本不受影响，重复读的性能是可以跟云盘一样的。
最后就是它是可以做到，不需要单独去指定哪部分数据，它可以根据你的访问的模式，自动去把热数据放到云盘冷数据留在OS上面，大幅度的降低运维上面的成本。
4、多模特性方面更新
最后说一下PolarDB，在多模上面的一些进展，首先我们有一个团队专门去做Ganos时空引擎。目前是首先覆盖了posQS的开源引擎的能力，引擎本身是自研的是会先覆盖这种基本的空间数据处理能力。在此基础上，支持了重点对移动对象和孪生三维数据的数据和场景的支持。除了时空数据以外，又添加了各种数据的处理能力。
比如通过PG vector支持向量的检索，通过TIMBD和RAM支持持续数据和全文检索。PolarDB上添加了一个引擎，是处理引擎数据图的，这是同图数据的存储和计算，的有已经有客户做过已经使用过，然后，他原来是在ecs端作为应用上做图关系的一个出搜索和处理，用我们的图的处理引擎以后，它的ecs的这种计算的资源的消消耗立马就下降了原来的3、4倍。在数据库里面，用更高效的方式用更少的资源，更快速的实现想要达到的效果。
最后是PolarDB，有一个oracle兼容版，之前有1.0版本，去年也推出了2.0版本。最近在2.0上进行进一步的兼容性的增强，解决了一大批的编码、隐私类型转换、大小写等这些以前非常头疼的问题。兼容语法的兼容度全面提升，并且具备了一键迁移的能力，不但覆盖了1.0的能力而且就更加接近于Oracle的语法。
PolarDB的输出的形态，以前是有三种形态，公共云的形态，大飞天、飞天企业版，还有DB stack。在公共云支持的全部的版本从11到14、15、16、17。17上马上会进行推出，然后每年也会跟着社区去发布新的版本，在企业版和DB stack版本上、企业版上面是有完整的暗示底座。
在DB stack上是一个相对轻量化的输出，但是也是有底座的要求的，为了让我们能更轻量化的输出，我们现在推出了软件化的输出形态，就他没有底座的资源要求，单台就可以部署。当然它的功能也相对来讲最基础的，是包含这些基本的高可用、监控，和备份等这种能力，然后它是由我们的合作伙伴负责交互运维大家在我们的云市场上就可以去下单并且它是完全符合信创认证的要求的，所以可以用于做国产化的这种替换。
上云和Oracle替换的一个解决方案，我们是有从兼容性的评估到数据的到应用的改造到迁移到各界有一连串的完整的工具链。经过了至少200多个客户的核心系统的上云和Oracle替换的这种这种考验，所以有非常成熟的这么一个解决方案。
三、商业数据库替换与上云解决方案与案例
一是小鹏汽车，主要的要求就是要性能，本来打算使用这种MPp的解决方案，但是又有这种交易的这种需求，所以最后他测试了PolarDB的 epq发现完全满足它性能上的需要，甚至比一般的像GOMPLASS这种这种开源方案还要性能还要好，在使用了很长时间以后就把他在自动驾驶场景下面一个业务往前移上来，后续又把其他的业务也都迁移上来。
二是中远海科它的一个传世宝，APP后台使用了我们PolarDB，痛点是有自建的多个分库分表的pg，管理起来非常麻烦要做一些时序数据的处理特别是热力去除的处理，原来是在应用里面去处理的，还有开发的成本非常高，用了PolarDB以后，一个是他用了一个大的示例，50多T的数据存在一个示例，里面就已经可以就不用它管理多个示例了，解决了它运维成本的问题。第二个就是我们的刚才是引擎也支持了这种对热力图场景的专门优化，使他的应用不需要去自己处理这些数据，让开发的周期能缩短一倍。
下面是一个就是上云和Oracle替换的案例——汇付天下，是我们第三方支付的丧失第一股，那它的主要的挑战呢就是一个是它的系统非常老旧，
所以对兼容性要求比较高。另外它是金融应用对可靠性和正确性要求比较高，那也是选用了PolarDB之后能快速的实现了从原来的小G加okra到上云的这么一个切换，在兼容性上面是完全能满足他的这种要求的，在可靠性和正确性方面也经受住了这种金融级的系统的考验。
最后一个是欧派家居，它的主要的它的核心系统是生产上的生产调度，它的主要的挑战在于写入压力非常大，每秒都要都要更新几千行，要求秒级的响应，然后还有一些大表，像3T的这种大表去性能问题。
最后这是它有些慢circle，其实需要专业的这种调优服务的，那这几个挑战，在上云过程当中，通过专门的代表，首先是采用了一组两重的这种架构，能够对应到他们原来aura的这种能力，然后针对代表我们做了深度的优化，最后做了深度的 circle性能调优，最后能够顺利的能把最核心的一个系统填到云上来，并且实现了商业数据库的替换，大幅的降低了成本。
