aurora的总体思路就是 数据不下沉，下沉redo，下层靠storage layer来承接page apply的业务，reader的数据，物理上是由storage layer根据redo重新rewrite出来的。
至于为啥能这么做，根本原因还是innodb的实现中，trx都不需要递交，执行过程中就不停的在生成redo log，而且定时在往磁盘flush，innodb的trx几乎把全部状态都在执行过程中flush入redo了，所以redo的实时性是非常好的，每次刷的数据也不需要像binlog那样无法控制。（当然pg也是如此，所有工程实现上2pl + mvcc应该都类似）
而polar的话，writer和reader看到的还是同一份数据，逻辑上就是同一份文件在不同机器上的挂载，如果不用polarfs，哪怕用nfs之类的，也是同样可以把代码跑起来的。
然后按照aurora这样的实现，是不需要改redo格式的，但是polar不行，polar必须要改，否则按照mysql的设计，reader和writer根本就不能挂载在同一份数据上，其次一些必要的redo applier，polar需要在reader上做很多的操作，有的在buffer占用上更大。
最后native cloud模式来看，aurora只需要普通ec2，不需要特殊机器，管控和普通rds基本一致，而polar的管控和机器都需要自己来维护，这里也会带来更大的工作量和容错率。
