Aurora

主要设计理念是降低 I/O，异步写 Page，并且把这个 task offload 到内部存储系统。存储计算解耦，可以做到分层扩容。比如说计算节点增加 500 个，存储节点只增加 100 个，按需分配。

Near Data Processing。既然存储计算完全分离，这会加重一些新的问题，比如查询得到的大量数据，如果不在存储层进行处理，而是全部传输给计算节点，这会极大地浪费网络 I/O。因此，现在计算分离的架构里面，通常都会有模块做算子的下推。TiKV 里负责下推的是 Coprocessor 模块。这方面的难点是，底层的 KV 存储没有完整的关系表信息，因此在做一些优化的时候无能为力。支持多写。在云原生数据库里支持多写是比较难的一件事情，比如 Aurora 就不支持（更新：是一开始的架构不支持，现在支持）。新的 PolarDB 是支持的。 内存虚拟化。把内存做高可用，通过 RDMA 连接。这个可以联想到 PolarDB 1.0。背后的大理念是资源池化。以前单体的时候，所有数据库kernel都在一台机器上，现在抽离每个部分并且做成一个资源池，方便上云。资源池的优势是封装了 low level 的细节，通过相关资源调度算法达到高效率的利用率。 这些也不是比较新鲜的研究问题了，业界已经开始大规模做了。个人思考，数据库 + k8s 是不是一个研究方向呢？虽然说 k8s 的设计初衷是运行无状态应用，但是如果能管理状态的话，那么可以说就是使得云上应用更加规范化了。这个方向还是比较有争议的，大多数难点还是工程上的，从学术的角度发文章可能比较难。