你说你说云生的，云同意吗？
现在的数据库产品不仅数量多，种类多，新概念也多，一个不小心就能被绕进去。最近这几天，我来做些功课，分析一下云原生、HTAP、AI4DB/DB4AI等目前纷纷扰扰的概念。今天先聊聊这些年十分热门的云原生数据库。
可能很多朋友对云原生的概念理解的不是十分清晰，对“云原生数据库”（Cloud native database）和“云就绪数据库”（Cloud Ready Database）这两个概念比较模糊。这些年我们上云了，在云上用RDS（关系型数据库服务），可以做到DBAAS，想用即用，但是很多RDS都只是Cloud-ready，云就绪的，而不是云原生的。
目前业内对云原生数据库的概念定义也十分模糊，很多企业都是自己说自己是云原生数据库，然后根据自己的特点来定义云原生数据库的概念。实际上云原生的概念最初是容器厂商提出来的，后来才被广大的分布式数据库厂商引用，现在几乎所有的国产分布式数据库都号称自己是云原生的。我们先不谈云原生到底是个什么概念，从云原生数据库出现的目的来看看云原生数据库应该具有的特征与能力吧。
云原生数据库是为了应用全面运行于云上而设计的数据库产品，其提供了云上其他的IT基础设施类似的特征，包括数据库服务开箱即用、高可扩展性、弹性、健壮性、资源隔离、自动化、简化管理、低成本以及区域可访问性。
某些传统数据库，比如Mysql、PG、Mongodb虽然也可以与云平台高度集成，并以RDS服务的形式在云上提供服务，但是其本质并不是为云而设计的，因此并不能直接称为云原生数据库，而只能说是“云就绪”数据库。
有些数据库，特别是现在的大多数分布式数据库，在设计上都借鉴了云的特性，并且尽可能符合云部署架构，但是它们并不能与云平台很好的融合，利用云平台的弹性资源能力获得更好的扩展性和弹性，并利用底层的云平台的能力获得高并发、低延时、稳定的数据库服务能力。这样的分布式数据库，如果非要说是云原生的，也是比较牵强的。
从严格意义上讲，云原生数据库是与云平台高度融合的，在设计时就已经考虑了依靠云底座的能力的分布式数据库系统。通过云架构的资源解耦、资源池化等设计，具备了高弹性、高可用性、可扩展性等特点。其弹性不仅仅在于横向扩展，而是更高要求的弹性伸缩，当业务负载高时可以扩容，业务负载和需求低时可以快速缩容，这样才可以更好地实现成本最低。从健壮性上看，云原生数据库必须能够在系统故障后不丢失任何数据。当系统的某个部分出现故障时，云原生数据库可以在运维人员不干预，不影响业务的情况下自动修复。
从管理方面，云原生数据库的重要特性是资源隔离、自动化、简化管理和低成本。资源隔离是云原生数据库的一个更为重要的特性，云原生数据库可能为很多应用服务，因为数据库中的各个租户会共享大量的资源，因此隔离十分重要，任何一个应用的故障都不能影响其他应用，这才能确保云原生数据库提供良好的服务能力给应用。自动化，自助服务是云基础设施最为重要的特性之一，云原生数据库也应该为用户提供此类能力。
简化管理应该是云原生数据库的一个最为重要的能力，只不过现在的大多数云原生数据库在这方面做的都不够好，一个优秀的云原生数据库应该把所有的管理都与云平台高度集成，利用云平台的管理能力来管理云原生数据库，对于用户来说，不需要为数据库的性能、可用性、数据安全、故障处置去操心，这一切都应该在云平台层面很好的解决了，甚至自动化完成了。
区域可访问性是云原生数据库需要提供的另外一个重要的能力，这个能力让用户可以随时随地访问数据。用户的应用可能会随着云而迁移，甚至切换到一个异地数据中心，数据库的访问能力也必须能够不受应用的迁移的影响，也应该自动的提供访问能力。不管底层是如何实现的，能力是必须具备的。
从上面的描述来看，云原生数据库实际上是和云底座紧密相关的，并不是把一个分布式数据库部署到某个云上，就算是云原生数据库了。数据库产品必须在底层设计，资源分层的时候就和云底座的资源池化技术相兼容。因此一个通用的第三方数据库产品要成为一个完善的云原生数据库，必须是支持多云部署，云异构部署的。实际上最初的云原生数据库都是以公有云或者私有云的方式供应的，因此在这方面都做了深度的适配。现在问题来了，传统的数据库厂商也在做云原生数据库了。那么这些数据库是如何做到云原生的呢？我想可能还是以喊口号为主吧。
实际上我们也不需要纠结数据库是不是云原生，能够与云上的应用很好的配合，并且满足我今天所说的一些云原生数据库的主要特征，并且在数据库内核中对云平台的资源供给不稳定性、IO延时不确定性等做了很好的处理，这样的数据库系统，就是“云友好”的数据库，云友好的数据库系统，对于企业的应用上云也就够用了。也不一定非要追求什么“云原生”了。真正的云原生数据库很可能是“云锁定”的，你选择云的时候，可能就捎带脚把数据库也已经选好了，或者说你要选择云原生数据库，那么你的选择权就被剥夺了。这又何苦来哉呢？
