聊聊云原生数据库

​回归正题，前两天有朋友在微信公众号问我对云原生数据库有没有新的看法。实际上很多新兴的概念，我的认知也是从模糊到逐步清晰，有个过程的。每过一段时间，对于一些问题的看法就会有些变化。特别是一些比较新的，没有严格定义的数据库领域的新名词。

对于云原生数据库的问题，我以前也写过几篇文章谈了我的认知和看法，最近这段时间也有一些新的认识。云原生数据库是国外云厂商最先提出来的，最著名的是亚马逊的aurora。我刚开始的时候把云原生数据库和RDS搞混淆了，认为云原生数据库是RDS换了个更为高大上的名字而已。后来仔细研究以后发现不是那么回事，国外的一些云原生数据库真对得起“云原生”这三个字。

首先，这些数据库可以像其他云资源一样便捷交付，包括可以支持自服务。这个特性与RDS是十分类似的，RDS可能在某些方面会做的比云原生数据库更好。

其次是资源的动态调度能力，云原生数据库在CPU,内存，存储容量，IO能力等方面都可以十分便捷的动态调度，可以随着业务增长不断交付新的计算能力，在这方面，云原生数据库比RDS更为强大。

这些都是我们用户能够看到的能力，实际上云原生数据库与普通的RDS的区别不仅仅如此。云原生数据库充分利用云底座的能力构建起支持提供云服务的能力。数据库与云底座的能力的有机融合是云原生数据库区别于其他数据库的最为主要的特征。云厂商也会为了增强云原生数据库的能力而在云底座上进行优化与扩展，使其能力能够更好的支撑云原生数据库。

不是随便一个数据库从物理机搬到云环境里，做一些运资源调度的接口，通过云平台能够向外提供数据库服务，就可以说这个数据库是云原生数据库了，这种数据库顶多算是RDS之类的数据库服务，不能算是云原生数据库。

我们还是以Aurora这个云原生数据库的鼻祖级的数据库来分析一下这个问题。Aurora支持Mysql和PG等数据库，实际上也是使用开源的数据库作为基础研发的，我们今天以Postgresql为例。虽然Aurora也使用了PG的开源社区代码作为基础，但是Aurora对PG做了适应云的改造，那就是日志即数据库概念的改造，通过WAL回放，Aurora可以实现基于共享存储的一写多读。在一个Aurora PG实例中写入的数据，可以在多个（目前最多16个）只读PG实例中立即读出，而不需要做数据库复制，因为底层的数据文件是共享的。利用云底座的云存储服务，一方面Aurora可以从多副本的云存储中通过均衡IO负载，从而提升IO的整体能力，Aurora还可以实现低延时的存储级的数据库复制，配合WAL回放进一步扩展数据库的能力。

Aurora在CPU、内存容量上的扩展可以通过只读实例去做横向扩展，IO容量可以通过云底座的云存储去动态扩展，IO处理能力还可以通过云底座的多副本机制去做扩展。数据库与云底座的深度融合是Aurora作为云原生数据库的基础。向上的那些通过云平台向外提供的服务能力实际上只是应用层的了，和RDS区别并不大。

这里有一个观点，那就是云原生数据库一定是要和具体的云深度融合的，亚马逊的Aurora不可能在谷歌云上运营，谷歌云上只能运营AlloyDB之类的竞品。

如果以Aurora为参考来看我们国内的一些云原生数据库，就更容易看明白了，不管是集中式数据库还是分布式数据库，不能说能在云上跑就算是云原生数据库。如果我们把某著名的国产数据库按照RDS的方式纳管到某个云平台上，能够像云平台内的云原生数据库一样方便的使用，我们还是不能把这个数据库叫作云原生数据库，顶多就是RDS。因为数据库和云底座在本质上并没有深度的融合，云底座并没有针对数据库做相应的优化，数据库也没有为了更好的使用云底座的能力而做相应的优化改造。

再过两天就要过年了，我也准备休息休息。过年期间写一些吃喝玩乐的心得，放松放松心情。过去的一年过得不容易，希望新的一年一切顺利。​