数据库应用需要什么样的云原生能力

​原本早上起来想写点什么的，不过这些天一直觉得有点乏力，早上起来啥也不想干。吃过午饭才感觉好一些。正好脑子里在想些问题，就立即把它写下来吧，否则有可能这种一闪念的灵感就消失无踪了。

前两天有个客户问我啥叫云原生数据库，我给他讲了半天，他听的还是有点云里雾里，最后说，这东西听起来确实不错，不过对于我们这种企业来说，用处并不大。确实是的，像他们这种央企的二级子公司，一共就二十来套数据库系统，谈得上大系统的几乎没有。我给他介绍的云原生数据库的好处，对他们来说确实也没有太吸引人的地方。

国外的云原生数据库在公有云上运营的较多，如果我的这个客户在国外，选择购买云原生数据库服务应该是首选，不过在国内，受到一些数据安全方面的限制，无法采购公有云服务。国内的所谓云原生数据库往往都不是构建在公有云上，通过数据库服务来获利的。只要是能够横向扩展的，能在云上跑的数据库，都可以打出云原生数据库的旗号来。

实际上对于云原生数据库，也没有特别恰当的定义。我认为能够与云平台紧密融合的，能够像云上的标准组件一样提供服务，并且具有与云平台一样的横向扩展能力的数据库产品，都可以称为是云原生数据库。那么一个云原生数据库产品应该有哪些能力呢？

首先是要符合“云”的特点，具有极强的自服务能力，即买即用，即申请即用。让数据库服务可以像云主机或者云上RDS一样便捷的申请，申请完成后可以实现秒钟级或者分钟级快速交付。这一点实际上实现起来并不难，普通的云上RDS也是这样实现的，数据库软件安装在裸金属服务器上，需要时创建数据库实例，并绑定相应的资源即可。

其次是弹性可扩展能力，云的特点就是弹性可扩展，不受单机硬件资源的限制。谈到弹性可扩展，大家往往就会直接想到分布式数据库。如果按照这个标准，难道只有分布式数据库才算是云原生数据库吗？实际上情况并非如此。弹性可扩展其限制并非只有CPU，内存这些具有单机上限限制的资源。在上云的绝大多数数据库应用里，这方面存在限制的寥寥无几。存储的IO能力，IO延时实际上对于很多应用来说更为重要。这也是目前用户对云原生数据库产品诟病较多的地方。如果我想购买1TB的存储容量，但是我需要5万IOPS，那么不好意思，我没法卖给你，我们的的IOPS是按照5000/TB来卖的，你必须买10TB的容量才能买到5万IOPS。云原生数据库产品应该能够和云平台紧密融合，并利用云平台的弹性可扩展能力来为用户提供不同选项的配置。亚马逊的AURORA可以通过读写分离来提供CPU资源的横向扩展能力，并且通过云平台的底层存储机制动态复制副本，扩充IO能力，从而满足不同种类的业务需求。因此一个数据库产品号称是云原生的，数据库与云底座之间肯定不是简单的叠加部署的关系，必须做大量的优化适配工作才能做好的。

第三是高可用，利用云平台的高可用能力，加强数据库的可用性。数据库产品本身就有高可用解决方案，云平台也有，但是二者可能不完全兼容，因此云原生数据库在云上必须与云底座做更好的融合，综合双方的优势才能够形成最佳的解决方案。

第四是跨数据中心高可用能力，无论是私有云还是公有云环境，一朵云总不可能是永远不会出问题的。因此作为云原生数据库产品，必须能够支持这种跨数据中心的，跨云的高可用。

第五是弹性资源调度能力，上云的最终目的还是为了不断地降低企业的IT成本，我们的企业中，经常会存在某套系统，峰值资源需求极大，但是峰值应用往往只是月底月初的几天，但是为了不出问题，我们必须为其配置最大的资源。资源动态调度，动态扩缩容目前还没有成为大多数大型企业的刚需。不过地主家也会缺钱的，随着数据库的爆发式增长，未来动态缩容也会成为刚需的。

和国外不同，我国的企业级应用大多数还是部署在私有云环境的，甚至还有一些像本文开头说的那家企业一样，如果为了享受云原生数据库的一些便利，还非得上一套复杂的云底座，那么就比较麻烦了。因此如果云原生数据库厂商能够提供一套小型的云数据库底座，那么对于用户来说就十分友好了。不必像Oracle Database Cloud一样连硬件都配置好，只需要提供一套通用硬件环境的小型云底座即可。还有一些数据库厂商并不是云平台厂商，他们想和某个云厂商合作，人家也不见得搭理你。既然云不来就你，数据库厂商可以自己去就云啊。自己开发一个数据库云底座，作为一个完整的解决方案去为客户服务也是不错的方式。

这几天脑子还是有点乱，今天也是想到哪写到哪，总之我的观点是云原生数据库的需求是强烈存在的，但是我们目前的号称云原生数据库的产品大多名不副实，数据库厂商也不能只是喊喊口号，而应该让你的产品变得真正像是云生的。​