在架构上Aurora和PolarDB各有特色。我认为PolarDB的架构和技术更胜一筹。
1）现代云计算机型的演进和分化，计算机型向高主频，多CPU，大内存的方向演进；存储机型向高密度，低功耗方向发展。机型的分化可以大大提高机器资源的使用率，降低TCO。
因此PolarStore中大量采用OS-bypass和zero-copy的技术来节约CPU，降低处理单位I/O吞吐需要消耗的CPU资源，确保存储节点处理I/O请求的效率。而Aurora的存储节点需要大量CPU做redolog到innodb page的转换，存储节点的效率远不如PolarStore。
2）Aurora架构的最大亮点是，存储节点具有将redolog转换为innodb page的能力，这个改进看着很吸引眼球，事实上这个优化对关系数据库的性能提升很有限，性能瓶颈真的不在这里：），反而会拖慢关键路径redolog落地的性能。btw，在PolarDB架构下，redolog离线转换为innodb page的能力不难实现，但我们目前不认为这是高优先级要做的。
3）Aurora的存储多副本是通过quorum机制来实现的，Aurora是六副本，也就是说，需要计算节点向六个存储节点分别写六次，这里其实计算节点的网络开销又上去了，而且是发生在写redolog这种关键路径上。而PolarDB是采用基于RDMA实现的ParallelRaft技术来复制数据，计算节点只要写一次I/O请求到PolarStore的Leader节点，由Leader节点保证quorum写入其他节点，相当于多副本replication被offload到存储节点上。
此外，在最终一致性上Aurora是用gossip协议来兜底的，在完备程度上没有PolarDB使用的ParallelRaft算法有保证。
4）Aurora的改动手术切口太大，使得它很难后面持续跟进社区的新版本。这也是AWS几个数据库产品线的通病，例如Redshift，如何吸收PostgrelSQL 10的变更是他们的开发团队很头疼的问题。对新版本做到与时俱进是云数据库的一个朴素需求。怎么设计这个刀口，达到effect和cost之间的平衡，是对架构师的考验。
