您还未登录! 登录 | 注册 | 帮助  

您的位置: 首页 > 软件开发专栏 > 数据库 > 正文

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

发表于:2022-12-26 作者:白鳝 来源:白鳝的洞穴

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

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

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

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

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

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

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

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

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

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

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