火山引擎云数据库 veDB 在字节内部的业务实践大数据和云原生时代

文章图片
大数据和云原生时代，企业数据量迎来急剧增长、数据类型日益丰富多样，各类新兴业务对数据库的各项能力不断提出挑战。伴随云原生理念的广泛传播和真正落地，如何进一步整合云计算基础设施和数据库，推动数据库实现高可扩展、高度自动化、快速部署，以满足企业真实业务需要，已成为业界关注的重要方向。火山引擎veDB是一款全托管的云数据库，简单易用，兼容MySQL、PG和MongoDB等数据库引擎，业务代码几乎无需修改即可接入使用。据介绍， veDB的架构遵循的是“分离”哲学，包括计算和存储的分离、日志和数据的分离、读写分离，因此veDB拥有敏捷灵活、性能和容量大、低成本、高可靠、高可用等优势。火山引擎是字节跳动旗下的云服务平台，也是字节跳动最佳技术实践的对外输出窗口。本文将围绕veDB（forMySQL）在字节内部遇到的各类挑战和解决方案，介绍企业级大规模数据库的演进历程。 veDB（forMySQL）介绍veDB整体架构呈现计算与存储分离的总体特征。以veDB（forMySQL)为例，其技术架构具有以下特点：

文章图片
veDB计算存储分离架构完全兼容MySQL：计算层基于PerconaSever8.0版本打造，完全兼容字节线上的MySQL生态，字节的应用迁移到veDB上不需要任何改造；计算存储分离：云原生架构，计算引擎能力和存储能力均可以独立扩展；超大实例容量：数据库容量不受单机磁盘容量限制，存储层容量可以按需扩展；只读线性扩展：添加只读节点无需拷贝数据，并且只读节点支持页面级别REDO并行回放技术，提供低读延迟（~10ms）；闪速备份恢复：存储层支持快照备份，通过PITR技术快速恢复至历史任意时间点。开发历史veDB（forMySQL)具体的发展历程如下图所示：

文章图片
目前，在字节跳动内部， veDB已大规模接入线上业务，包括在国内预生产环境已完成了对RDSMySQL的全量替代，已接入国内生产环境~40%的业务库，基本覆盖所有业务门类。预计到2022年底， veDB将替代内部RDSMySQL约80%的国内业务，并使综合成本下降约30% 。同时， veDB也已亮相字节跳动云服务平台火山引擎，对外提供NewSQL类DBaaS服务。
veDB（forMySQL）技术挑战
在构建veDB（forMySQL）的过程中，团队遇到了以下三方面的技术挑战：
相比于本地的NVMESSD磁盘，计算存储分离架构会带来时延的增加；在只读节点读延迟方面，如何做到比较低的读延迟；由于业务会有各式各样的个性化诉求，需要对其个性化的数据进行优化。对于这些技术问题，下面是一些针对性的解决方案。如何克服时延挑战
虽然计算存储分离架构带来了一定的灵活性，但是相对于传统的单机主备架构，也带来了写日志和读页面的时延增加。具体来说，比如传统单机主备架构的读写时延大概是十微秒，但是计算存储分离架构由于经过一层网络TCP/IP ，时延大概是1毫秒左右，这会造成部分时延敏感性业务体验受损。
文章图片
解决方案
针对上述问题，团队提出了以下三种解决方式：共享内存写缓存/NVMESSD读缓存：首先， Redo日志在写入远端LogStore之前，会写入一个共享内存，然后再批量写入远端，这样做虽然类似于原生MySQL异步提交，但效率上要比异步提交高很多；其次，团队提供了二级读缓存的特性，虽然本地盘比较小，但是也有一部分存储空间，团队利用这部分存储空间来实施BufferPool的扩展，大大减少对远端PageStore的读取操作；页面预取/计算下推：团队面对部分业务场景可以针对性地进行页面预取优化，提前从PageStore读取页面到缓冲区，可以避免在有需求时临时读取；RDMA/AEPStore：这个其实类似于PolarDB读写PolarFX ，但是RDMA部署会受到一些条件限制，团队目前是在有部署条件的场景下推行使用RDMA网络，并且结合AEPStore优化读写时延。通过以上解决方案，总体而言， veDB（forMySQL）与本地NVMESSD磁盘相比，在延时敏感型业务体验上变化不大，在部分场景有更优表现，因为veDB去除了许多操作，比如不用刷脏页、没有Checkpoint 。只读节点如何做到超低读延迟