，言归正传。前两天有朋友在微信公众号问我对云原生数据库有什么新的看法。其实很多新出现的概念，我的认知也有一个从模糊到逐渐清晰的过程。每隔一段时间，对某些问题的看法就会发生变化。尤其是数据库领域的一些比较新的术语，没有严格的定义。关于云原生数据库的问题，我也写过几篇文章，谈谈自己的认知和看法，这段时间也有了一些新的认识。云原生数据库最先由国外云厂商提出，最著名的是亚马逊的极光。刚开始的时候，我把云原生数据库和RDS搞混了，以为云原生数据库就是RDS换个更好的名字。后来仔细研究，发现不是这样的。国外的一些云原生数据库，真是当得起“云原生”二字。首先，这些数据库可以像其他云资源一样轻松交付，包括能够支持自助服务。这个特性和RDS非常相似，RDS在某些方面可能比云原生数据库做的更好。二是资源的动态调度能力。云原生数据库可以在CPU、内存、存储容量、IO能力等方面进行动态调度，随着业务的增长不断提供新的计算能力。在这方面，云原生数据库比RDS更强大。这些是我们的用户可以看到的能力。其实，云原生数据库与普通RDS的区别不仅如此。云原生数据库充分利用云基础的能力，构建支撑提供云服务的能力。数据库与云基础能力的有机结合，是云原生数据库区别于其他数据库的最重要特征。云厂商也会在云基础上进行优化和扩展，以增强云原生数据库的能力，使其能力更好地支持云原生数据库。不仅仅是把数据库从物理机搬到云环境，做一些资源调度的接口，可以通过云平台对外提供数据库服务。可以说这个数据库是一个云原生数据库。这种数据库顶多是RDS的一种。这样的数据库服务不能算是云原生数据库。下面我们以云原生数据库的鼻祖极光来分析一下这个问题。Aurora支持Mysql、PG等数据库，实际上是使用开源数据库为基础开发的。今天我们以Postgresql为例。虽然Aurora也是以PG的开源社区代码为基础，但是Aurora对PG进行了适配云的适配，也就是日志作为数据库的概念的改造。Aurora通过WAL播放，可以实现基于共享存储的一次写入多次读取。在一个AuroraPG实例中写入的数据可以立即在多个（目前最多16个）只读PG实例中读取，无需数据库复制，因为底层数据文件是共享的。利用云基的云存储服务，一方面极光可以平衡多副本云存储的IO负载，从而提升整体IO能力。Aurora还可以实现低延迟的存储级数据库复制，并进一步扩展WAL回放数据库能力。Aurora的CPU和内存容量的扩展可以通过只读实例进行横向扩展。IO容量可通过云基的云存储进行动态扩展。还可以通过云基的多副本机制扩展IO处理能力。数据库与云库的深度融合是极光作为云原生数据库的基础。通过云平台提供向上的服务能力，其实只是在应用层，和RDS没有太大区别。这里提出一个观点，就是云原生数据库必须和特定的云深度融合。亚马逊的Aurora无法运行在谷歌云上，只有AlloyDB等竞品可以运行在谷歌云上。如果我们拿Aurora做参考来看一下我们国内的一些云原生数据库，会更容易理解。无论是集中式数据库还是分布式数据库，都不能说云原生数据库就可以跑在云上。如果我们以RDS的形式在云平台上管理一个国内知名的数据库，在云平台上可以像云原生数据库一样方便使用，我们还是不能把这个数据库称为云原生数据库，在大多数是RDS。因为数据库和云基在本质上并没有深度融合，云基并没有针对数据库进行优化，也没有优化数据库来更好的利用云基的能力。再过两天就是过年了，我也准备休息了。过年的时候，写点吃喝玩乐的心得，舒缓心情，放松身心。过去的一年很艰难，希望新的一年一切顺利。
