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

文章图片
其实施效果如何呢？首先是扩容效果：假如分库分表有1000partitions ，并且1000partitions都在一个实例上，而要扩展成两个实例，此时扩容只需要在1min内就能完成。这样做的好处是拆分过程与数据量无关，只需要提前准备好计算节点资源（虚机或容器），即可迅速完成拆分。其次是缩容效果：缩容的方式与扩容的方式是一致的，它也是变更元数据，因此缩容与扩容的效率基本相同。 veDB（forMySQL）字节业务实践首先来了解一下veDB(forMySQL)在字节的部署情况，主要包含高可用和高可靠两种部署方案。
高可用部署方案
目前veDB(forMySQL)是三机房部署，对于高可用部署方案，团队分别在每个机房部署了存储池，如下图所示。第一个存储池用于存储Redo日志，第二个存储池用于存储Binlog ，第三个存储池是Pagestore 。为什么要将Redo和Binlog分开存储？因为Redo的存储实现与Binlog不同， Redo只需要存储两个小时，而Binlog需要存储一周左右，因此它们所需的容量是完全不同的。如果将二者都放入SSD ，会对SSD造成极大的容量负担，因此需要两个存储池。其次团队会在主机房（DC1）部署三个计算节点，在副机房（DC2、DC3）部署两个计算节点。 DC1、DC2和DC3通过Binlog同步，但是在机房内是通过Redolog同步。
文章图片
该部署方案的优点：一是保证最大服务可用性（RTO~=0），通过Binlog方式同步，无论哪一个机房出现问题， DC1依旧可以提供服务；二是性能好/时延低，因为事务提交没有跨机房延迟，技术团队利用RDMA+AEPStore能够提供进一步加速。该部署方案的缺点：比如跨机房不能保证RPO=0、副机房只读节点的读延迟会较高。如上图所示，在DC2中，第一个只读节点的延迟是Binlog延迟，第二个只读节点的延迟是Binlog的延迟+Redolog的延迟。在主机房DC1中只有Redolog的延迟。因此，该部署方案适用于对可用性和性能要求较高的业务场景，同时在极端情况下，比如机房整体故障，可能会损失失一点数据。
高可靠部署方案
该部署方案也可以被称为为三机房六副本，它是存储层跨机房部署，只包含两个存储池：LogStoreSSDforredo&binlog ，和PageStore 。由于它不需要依靠Binlog在机房间同步数据，所以可以不需要Binlog或者保留时间可以比较短，因此无需专门的HDD存储池来存储Binlog 。
文章图片
该部署方案的优点：一是保证最大数据可靠性：它依靠存储层通过column协议保证数据可靠，因此如果机房出现问题，其中的数据也不会消失；二是只读节点都延迟低：该方案中只有Redo日志延迟，比如DC1延迟是10毫秒左右， DC2的延迟大概是20毫秒左右。该部署方案的缺点：一是性能相对较差：如果要保证RPO=0 ，事务性能相对会较差；二是时延相对较高：因为事务提交时需要写三副本或者两副本，这个过程中必然会存在跨机房的RPC延迟。该部署方案适用于对数据可靠性要求比较高的业务，比如支付业务场景；同时它也适用于QPS不高，但是对备机读延迟敏感的业务。典型业务实践veDB(forMySQL)主要被应用于以下四类业务实践：小微库
该库的特点是数据量较小， QPS较低。 100%预生产环境实例和部分生产环境实例都属于这类情况，使用veDB可以显著地提升资源利用效率。历史库该库的特点是数据量超大， QPS较低，有复杂查询。钱包历史数据，财经历史数据都属于这类。以往的历史数据都是导出到Hive或者其它的分析系统，需要经过一个ETL过程。另外基于MySQL开发的一些应用，在Hive上需要重新开发。如果通过veDB来做历史库，就不会有以上问题，上层应用无需二次开发适应异构类型的历史库。单体大库单体库无法对分库分表进行拆分，该库的特点是数据量大， QPS较高，时延较低。广告库和财经库都属于这类情况。此时，团队会通过基于RDMA的AEPStore或者本地的二级读缓存，来应对该库的问题与挑战。分片库该库的特点是数据量超大， QPS较高，时延较低，同时它能够分库。目前，团队上线了激励中台和Ad-Hoc节假日活动。 veDB（forMySQL）下一步发展方向veDB目前往以下方向发展：