写点什么

面向 OLTP 场景,火山引擎跑在 Kubernetes 上的数据库有何不同?

  • 2022-12-23
    北京
  • 本文字数:3700 字

    阅读完需:约 12 分钟

面向 OLTP 场景,火山引擎跑在 Kubernetes 上的数据库有何不同?

几年前,行业内关于是否可以把数据库跑在 Kubernetes 上就不乏讨论。Google Cloud 解决方案架构师本杰明·古德(Benjamin Good)曾发文讨论了这件事情的可行性:想要讨论这个问题,开发者们需要先明确需要通过把数据库 Kubernetes 上解决什么问题,再来看下可行性。如今,业内不乏有将数据库跑在 Kubernetes 上的产品出现,火山引擎数据库系列产品也是其中之一。我们可以从火山引擎数据库产品出发,了解云时代大规模场景下数据库跑在 Kubernetes 之上有何不同。

为什么选择在 Kubernetes 之上跑数据库?


火山引擎存储 & 数据库产品解决方案架构师魏巍告诉 InfoQ,业内不少存算分离的数据库采用的是基于物理机或者虚拟机的方式进行部署,不管是 CPU、内存还是存储的调度方式都偏传统,而字节跳动的 veDB 完全基于 Kubernetes 进行部署。目前我们可以看到也有一些企业把数据库部署在 Kubernetes 上,只是更多是放在容器里了。


业内对于云原生数据库的理解有共同之处:面向应用,不再关注底层需要多少 CPU、内存等等,而是更关注应用的状态,比如是否高可用。这些就可以通过 Kubernetes 自带的 Operator 来实现。在魏巍看来,部署在 Kubernetes 上的数据库,比部署在虚拟机或者物理机上的数据库,云原生的程度更高一些。“我们完全是基于 Kubernetes 做了深度整合的数据库系统。”


魏巍提到的火山引擎跑在 Kubernetes 上的数据库产品,主要面向 OLTP 场景,包括关系型数据库 RDS、云原生数据库 veDB MySQL、缓存数据库 Redis、文档数据库 MongoDB、表格数据库 HBase 和图数据库 veGraph。


据他介绍,火山引擎数据库团队并不是从一开始就想要自研在 Kubernetes 上跑数据库的。内部在进行整体的数据库产品开发的时候秉承着这样的思路:最开始是效率优先,使用开源的产品来满足业务需求,后来发现因为字节跳动内部数据规模越来越大,尤其像 2021 年春晚红包雨活动时,使用开源的数据库产品无法满足业务需求,才开始在开源产品的基础上进行迭代和优化。可是新的问题又来了。由于开源产品的架构设计有自己的规则,有一部分的性能就无法进行优化。所以火山引擎数据库团队开始寻找其他的办法——从架构层面对数据库进行改造,比如云原生数据库 veDB MySQL,改造成计算、存储分离的架构,让整体的性能更高,峰值集群达到百万级别的 QPS。


2015 年到 2017 年间,火山引擎数据库处在相对初级的阶段,仅依赖人工和脚本的方式进行数据库管理运维,就足以满足业务量的需求;2018 年到 2021 年,火山引擎开始改造云原生数据库 veDB MySQL、缓存数据库 Redis 等。从今年年初开始,火山引擎开始在内部大规模推广自研的 veDB,融入了很多像 AI for DB 之类的技术,把之前 DBA 沉淀下来的经验,通过 AI 的方式,让系统自动优化和调整数据库系统。


火山引擎数据库团队在进行数据库技术产品优化时主要考虑两个关键点:其一是尽可能地提高资源利用率,实现降低成本的目的;其二是尽可能减少对客户在线业务产生影响。在魏巍看来,基于 Kubernetes 实现云原生化可以更细粒度的对资源进行管理,减少资源碎片,进而提高整体资源利用率,达到降低成本目的。同时,计算资源与存储资源可以借助 Kubernets 进行统一调度,可以更充分的释放云计算弹性的能力。火山引擎数据库团队也在向 serverless 方向发展,以上能力都是面向 serverless 的重要基础。


“数据库本身的体系类似,所以大家做的优化也是类似的。像我们的 veDB 也做了 log is database 分离,把一些 mysql 的内核进行非常大的改造,让它写数据的时候只写日志,而不会去刷新数据,这样就极大程度减少了网络开销,进而提升了整体的性能。”魏巍表示:“veDB 和原生的 Mysql 相比,基本上是原生 Mysql5-6 倍的性能。”云时代,业务大规模要求下数据库性能的大幅度提升,是火山引擎坚定了让数据库跑在 Kubernetes 上的信心。此外,阿里云、亚马逊云科技做数据库产品比较早,当时底层的技术依赖虚拟机和虚拟化,而火山引擎云数据库做得晚,赶上了 Kubernetes 发展的好时候。

跑在 Kubernetes 之上的数据库有何不同?


不过从技术角度看,其实 Kubernetes 整体来看对于数据库并不友好。根据 Google Cloud 解决方案架构师本杰明·古德的“数据库应该跑在什么环境中”思维导图,首先,跑在 Kubernetes 之上的数据库,相比跑在物理机、虚拟机环境的数据库更容易出现故障自动转移事件;其次,持续产生高工作负载的场景,无法控制并发量,对于跑在 Kubernetes 上的数据库也不友好,会导致数据库不受控。


Operator 的出现让数据库真正在 Kubernetes 上变得好用。云厂商可以通过扩展 Kubernetes API,使用 Operator 来实现数据库的运维能力和管理能力。对于非 Kubernetes 友好的数据库如 Mysql,就可以借助 Operator 来实现故障自动转移等;对于高工作负载高并发量的场景,数据库没有银弹,可以选择不同的数据库产品组合。


数据库跑在 Kubernetes 之上的好处也开始被看见,比如数据库实例资源的增加变得更简单、跨多云部署的兼容性更好、运维的复杂性更低……从架构视角看,魏巍认为部署在 Kubernetes 之上的数据库资源调度的粒度将更小。以前用虚拟机,至少需要一台虚拟机做调度,但是 Kubernetes 上以 Pods 为单位去做资源调度,由 Kubernetes 进行资源分配,提升了整体的资源利用率,也就降低了成本。“开一个虚拟机的时间和开一个 pod 的时间相比,肯定是 pod 的时间更短。这也是我们说火山引擎云数据库具备非常强弹性能力的重要原因之一。”魏巍谈道。


随着应用场景更加宽泛,Kubernetes 也会受限。对此,火山引擎专门配备了一个团队负责进行 Kubernetes 的优化和改造,让它能更好地满足大规模应用场景。同时,该团队还会负责云数据库和 Kubernetes 更充分的融合。“业内还没有哪个厂商这么大规模地把云数据库部署在 Kubernetes 上,火山引擎是第一家。”


目前,火山引擎数据库产品系统分为自研 veDB 和社区版优化两大类,还提供了一些生态工具 DTS。除了前文提到的云原生数据库 veDB MySQL,火山引擎缓存数据库 Redis 也与社区版 Redis 有很大不同。

社区版 Redis 采用无中心化的架构,底层节点之间使用的是 gossip 协议。这个协议导致一旦节点数过多时,会产生严重的网络风暴,导致整个集群的不稳定,并且也无法提升整体的容量规模。所以,火山引擎缓存数据库 Redis 采用字节跳动内部实践的 Achemy 架构,对社区版 Redis 的整体架构做了改造。



改造主要体现在 2 个方面。

其一,把社区版 Redis 的架构从无中心化转变为中心化。通过引入集群组件 config server,对整个 Redis 集群做元数据的管控,这样就可以避免 gossip 协议通信引起的网络风暴。

其二,Achemy 架构分为三层,第一层是 proxy,第二层是 config server 进行元数据管理,第三层是 server 层用于真正存储数据。这三层架构让字节跳动的 Redis 可以支持上千的节点分片,让 Redis 的集群规模变得非常大。


“其实最开始字节跳动也是在用开源的版本,也没有想直接从架构角度推倒重来,只是对于规则协议进行优化来提高节点数量,但是做下来发现投入产出比低,面对不断上涨的业务量也不是长久之计,毕竟社区开源版的 Redis 可能没有预估到如今如此大规模的场景。”魏巍谈道,过去大家专注在数据库本身的优化工作,现在上云之后,其实可以借助云的能力优化数据库的架构,让数据库的性能和稳定性整体从云的维度得到一个比较大的提升。


火山引擎图数据库 veGraph 是火山引擎自研的产品,类似 Achemy 架构,以属性图为基础结构数据,提供了海量关系的数据存储和毫秒级的在线查询服务,广泛应用于社交网络、欺诈检测、推荐引擎、知识图谱等场景。“比如抖音和头条里,你给哪个文章或者视频点赞,你的好友也能看到这条文章或者视频,其实就是借助了图数据库的这种关系分析能力。也是因为业务量大,所以开源的图数据库满足不了抖音头条这种大规模海量数据的要求。”


魏巍表示:“我们自研的图数据库 veGraph 可以做到万亿条边。如果两个人是好友关系,这一条好友关系就被称作是一条边。不仅规模可以达到万亿条边,单集群已经可以达到亿级别的 QPS 性能水平。”这里底层的技术支撑和 Redis 类似,通过分层拆开不同的组件,分别对每个组件进行集群化处理,三层集群共同对外提供服务能力,所以可以达到万亿条边的数据量,整体 QPS 达到亿级别。

云数据库的未来方向


“云厂商提供的云数据库应该做到简单易用,安全稳定,极致弹性,高性价比。把客户 DBA 需要做的事情都做了,而且要做的更多,做的更好。”在魏巍看来,DBA 应该有更高的价值,应该和业务开发走得再近一些,才能让业务和数据库更好地结合。“开发如何建索引这个事情很多企业的 DBA 都会遇到。一旦出现问题,大家会发现开发同学索引建得不好,SQL 语句写得不好。其实,可以让 DBA 同学提前介入到开发工作中,这些事情完全可以避免,让 SQL 语句更加高效,进而让业务可以用更少地资源去做更多的事情。”魏巍解释道。


业务视角下,云数据库未来的重点方向在于能否稳定支撑企业业务运转的同时降低使用成本,所以从技术角度看,无论是哪一家云厂商,未来都会在底层技术上做更多的优化,并在上层打造一个更加稳定的平台来供企业客户长久、安心地使用数据库产品。

2022-12-23 10:573425

评论

发布
暂无评论
发现更多内容

手把手教你,从零开始搭建Spring Cloud Alibaba!这份笔记太牛了

Java~~~

Java 面试 微服务 Spring Cloud 架构师

脚本测试服务器处理URL非法传参

liuzhen007

8月日更

趁着课余时间学点Python(四)真的花点课余时间就能理解的分支控制语句

ベ布小禅

8月日更

数据中心的组织架构是怎样的?

Taylor

大数据 数据中心 数字化 组织架构

Docker可视化管理工具对比(DockerUI、Shipyard、Rancher、Portainer)

xcbeyond

Docker Portainer shipyard rancher 8月日更

配置ssh免密码登录

一个大红包

8月日更

导致我们形不成「自律」的「罪魁祸首」

非著名程序员

提升认知 个人提升 自律 8月日更

它来了!靶机渗透题目的一次实战记录

网络安全学海

网络安全 信息安全 实战 渗透测试 安全漏洞

KIE(Knowledge Is Everything)

LeifChen

drools 8月日更 KIE 知识库

特斯拉自研超算Dojo本月亮相? UCLA教授发推提前泄密

百度开发者中心

自动驾驶 最佳实践 方法论 科技信息

15 道超经典大厂 Java 面试题!重中之重

程序员鱼皮

Java c++ 面试 后端 Go 语言

金九银十面试分享!字节跳动Java研发岗(内附万能模板)

Java 编程 架构 面试 架构师

前方高能预警!阿里大佬出品“Spring实战学习笔记”震撼来袭

Java~~~

Java spring 面试 微服务 架构师

圆梦腾讯之后,我收集整理了这份“2021春招常见面试真题汇总”

Java~~~

Java 面试 微服务 多线程 架构师

怎样回到常识做投资?

石云升

投资 8月日更 启发

模块四考试试卷存储方案

kitten

模块四

【Vue2.x 源码学习】第二十六篇 - 数组依赖收集的实现

Brave

源码 vue2 8月日更

就这?腾讯云高工熬夜手写'Java微服务学习笔记'也就让我月薪涨3k

Java~~~

Java spring 面试 微服务 架构师

国内外 DevOps/DevSecOps 报告对比解读:安全与云原生持续升温

极狐GitLab

DevOps 安全 DevSecOps

同态加密算力开销如何弥补?港科大团队提出FPGA加速方案

星云Clustar

联邦学习 同态加密 隐私计算 算力加速 FPGA加速

fil矿机有哪几种?fil矿机算力怎么计算?

fil矿机有哪几种 fil矿机算力怎么计算

涨薪50%,从小厂逆袭,坐上美团L8技术专家(面经+心得)

Java~~~

Java 面试 微服务 JVM 架构师

2021年《中国DevOps现状调查报告》正式发布!GitLab被选为使用率最高的开源软件安全类工具(内附下载链接)

极狐GitLab

ipfs矿机怎么买?ipfs矿机在哪买?

ipfs矿机怎么买 ipfs矿机在哪买

毕业设计

方堃

Python3 数字

Geek_aee0b4

我从外包辞职了,10000小时后,走进字节跳动拿了offer

Java~~~

Java 面试 微服务 JVM 架构师

Python3 运算符

Geek_aee0b4

Java程序员3个月从月薪6k涨到15k,你知道我是怎么过来的吗?

Java~~~

Java 面试 微服务 JVM 架构师

面向 OLTP 场景,火山引擎跑在 Kubernetes 上的数据库有何不同?_数据库_张俊宝_InfoQ精选文章