《Serverless数据库技术研究报告》——二、 Serverless数据库关键技术及应用场景——（一）Serverless数据库关键技术（2） https://developer.aliyun.com/article/1223710?groupCode=polardbforpg

3、高性能

（1） 高性能全局一致性

因为云原生数据库横向扩展的RO节点上的数据和RW节点上的数据会存在复制延迟，用户通常无法在RO节点获取准确的最新数据。如下图所示，用户先后发起了事务1和事务2。事务1先发起，然后在RW上完成了数据A的更新。此时只读事务2发起在RO节点上，假设事务2与事务1的间隙时间是t1。因为事务1的事务日志在传输到RO时存在复制延迟和回放延迟t2，如果t2>t1, 则事务2在RO上读到的数据结果是A=0。

然而，根据数据库事务的定义，在Read Committed、Repeatable Read和Serialization隔离级别下，事务2都应该读到事务1的数据，也就是A=1。因此若不能实现在RO节点读强一致性的事务数据，数据库系统事务的一致性就遭到了破坏。在此情形下，为了保持数据正确性，数据库Serverless实例只能在单节点弹升。但是部署在物理机上的数据库实例能力会被物理机的单机规格上限所限制。因此，云原生数据库Serverless需要有跨节点全局一致性读的能力才能真正实现多节点横向扩展的弹性能力。

因此，云原生数据库必须提供全局强一致的事务读能力，才能使事务一致性的RO节点替RW节点透明地分担用户负载。全局强一致性当前有两种技术方案，一是引入Proxy的辅助，让数据库RO节点上的事务等待日志回放到指定位点才能返回。但是所有读事务都等待，将使得数据库的性能极大回缩；二是PolarDB高性能全局一致性集群SCC（Strict Consistency Cluster）解决方案，PolarDB数据库引擎的PolarTrans事务系统利用提交时间戳技术CTS和RDMA网络，在内核层面提供集群全局一致性读SCC服务，保证发往集群任意副本的读请求都可以获得全局一致性的结果。

（2）计算算子（Shufflfflffle、Scan）进一步分离，写跟读会分离

在OLAP应用场景，由于计算与存储分离后，计算相对没有状态。但是Shufflfflffle在本地会导致BSP恢复成本较高，Scan操作需要将远程的数据拉取到本地。针对Shufflfflffle会有类似ShufflfflffleService的服务出现，Scan操作会将算子尽量推送到缓存端或者远程的存储之上，降低实际计算的数据量；存储层面，写操作由于需要较大吞吐量，读操作在计算后，将少量数据返回；一般会将写操作做成单独的服务，进而承接大吞吐量的写操作。

（3）引入新的硬件解决瓶颈问题

引入如GPU、FPGA、P-Memory来解决 Shufflfflffle、Scan等池化后，进一步提升性能；新的芯片带来的新的指令集，如阿里云的倚天，计算需要在新的芯片下提供更高的性能；在向量化或者串通执行跟指令集做更加深层次的结合，在单机runtime层面进一步提升性能；核心在于单位硬件的投入可以带来数单位的性能提升；如果不选择对象存储，则需要厂商自己提供机型，采取通用机型性价比较低，需要定制新的存储机型满足需求。

《Serverless数据库技术研究报告》——二、 Serverless数据库关键技术及应用场景——（一）Serverless数据库关键技术（4） https://developer.aliyun.com/article/1223640?groupCode=polardbforpg