ByConity 技术详解与运行 字节跳动开源云原生数仓引擎

ByConity是基于 ClickHouse 发生。ClickHouse 社区曾经开展了很多年。字节从 2017 年开局大规模经常使用 ClickHouse。在验证了多款产品之后,最终发现 ClickHouse 是惟一能够撑持字节过后的体量以及保证查问体验的产品。在经常使用 ClickHouse 环节中遇到了很多的痛点,比如说运维老本居高不下,扩缩容老本高,同时也无关联查问的局限性。

字节从 18 年开局对 ClickHouse 启动很多性能优化,但字节的业务开展比拟快,无论是数据量还是业务的复杂度,回升得十分快。开展了两年之后发现便捷的性能迭代或许曾经难以满足业务开展须要,所以启动了整个架构从新的设计。过后从拥抱云原生架构的初衷,从新设计了存算分别架构,过后这个版本可以算是一个 ByConity 的雏形。这个版本之后,字节外部有很多业务从原先 MPP 架构向存算分别架构迁徙。目前曾经有一半以上的场景曾经迁徙到存算分别架构过去。在 22 年的时刻,咱们选择将这些优化回馈到社区。在与 ClickHouse 官方探讨之后,官方倡导咱们自己去开源产品。在 23 年 1 月份字节发布了开源的第一个版本 Beta 版。而后阅历了大略半年的社区的反应,以及自身性能的迭代后,咱们在 23 年 5 月份正式发布了 GA 版本。如今 ByConity GA 版本曾经开展了一年多时期。在这当中也陆续推出了几个小版本,像 0.2.0、0.3.0、0.4.0 等等。这些小版本当中,一方面是启动性能的迭代以及疑问的修复,另一方面不停地启动性能的优化。

这里说下经常使用 ClickHouse 的一些痛点,ClickHouse 是一个典型的 MPP 架构数据库,它有很好的性能长处。比如说单表查问,尤其是聚合查问的时刻,它领有抢先其余竞品的性能,然而经常使用它的时刻也会有很多的痛点,其中一个最关键的痛点就是扩容老本十分高,由于自身架构的设计的要素,以及数据与计算节点捆绑的要素。咱们每次启动扩容的时刻,须要数据交启动重散布,会有很高的运维老本以及数据验证等资源方面的代价,对线上会是很大的影响。同时它很难平衡资源的有效应用,以及资源隔离。比如说假设宿愿一个业务能够与其余业务启动隔离,最好给他一个独自的集群,然而独自集群又很难把配件资源很好地利用起来,由于当业务比拟闲暇的时刻,这些资源就或许会糜费。

在读写方面也是一样,有时刻假设大家都是读写同一份资源上,写恳求一旦大了之后,就会很大影响线上的一些读恳求,读写这块也没有方法很好的分别。同时 ClickHouse 另外一个比拟痛的点是只管它的单表查问性能十分好,然而在多表 join 这块是业界不时诟病的,没有方法做很高效多表查问,它的 join 优化成果十分差。所以咱们在经常使用 ClickHouse 时,通经常常使用方法是在数据进入 ClickHouse 之前,启动很多的前期处置,会由 ETL 环节生成大宽表,而后把大宽表内容导入到 ClickHouse 后再启动查问。

ByConity是怎样处置这些痛点的呢?首先来引见一下 ByConity 整个架构设计,ByConity 架构可以分为三层,最上方是共享服务层,两边是计算层,最上方存储层,先看最上方共享服务层,这层是整个集群所共享的公共资源节点,这些节点中有一组就是 ByConity 整个集群的入口,一组 Server 以及多个共享的服务,如 TSO,Resource Manager、Daemon Manager 等组成,同时这层有元数据存储,ByConity 有一致的中央元数据层。Server 承当的上班关键是 SQL 解析、生成执行方案,以及优化器对执行方案启动优化,同时它会跟元数据存储打交道,把元数据存储很好地治理起来,并且 Server 里有元数据的 Cache,所以可以减速元数据访问。这些共享服务中其中比拟关键的一个是 TSO,它生成散布式事务所须要干燥递增的时期戳,Resource Manager 关键治理 Workload 两边计算中所须要的资源,并启动资源调配的组件。Demon Manager 治理 Daemon。Daemon 相似 ClickHouse 里经常所须要做的 Merge task,在 ByConity 里也雷同须要做。同时还有一些比拟关键的后盾进程,比如像 Kafka 的 Consumer,假设咱们在启动实时数仓的数据导入,须要用到这样的组件,也是由 Daemon Manager 启动治理。

上方是服务层的组件,两边 Worker 层设计是有形态的,这是存量分别的比拟关键要素。也就是说 worker 是可以弹性无感的扩缩容。为什么能做到呢?首先数据寄存在远端的 CFS 层,远端数据层可以允许 HDFS 或许 S3 存储。Worker 查问会从远端存储把数据拿过去,而后在本地会有必定的基于磁盘的缓存启动减速,但这个缓存是由集群齐全智能治理的,也不触及到数据的分歧性等,所以可以以为 Worker 是有形态的。同时引入了 Virtual Warehouse 的概念,一组 Worker 可以成为一个 Virtual Warehouse,资源隔离基本上基于这个概念。比如说架构里介绍的是做读写分类,也就是读和写 Load 须要树立不同的 Virtual warehouse 去做,这样的话就可以相当水平上能够让这个重的写操作不会去影响到在线读操作。雷同在不同业务之间的资源隔离也可以用相似的方式去做。

上方引见整个架构设计,再来说 ByConity 在性能的优化做了哪些。首先比拟关键的就是处置了 ClickHouse 复杂查问这个大痛点。ByConity 对这种复杂多 Join 查问允许得十分好。为什么可以允许得十分好呢?这当中就须要触及到整个查问 Pipeline 的变革,以及自研优化器的引入。整个计算层的变革关键是比如在 Server 改写了整个 ClickHouse 解释器,外面引入了 Query Planner 组件,Planner 可以生成 Query plan,而后 Query plan 经优化器优化,可以生成改写后的经过优化的 Query plan。每个 Query plan 是由多个 Plan Segment 组成。每个 Plan Segment 都可以下发到前面的计算层进后退一步的解析和计算。每一个 Plan segment 的计算可以经常使用相似原先 ClickHouse 的Pipeline schedule 的执行方式。在这个环节中就会触及到自研的查问优化器,对 Query Plan 启动优化和改写。允许比拟经常出现的优化手腕,比如 RBO、CBO。RBO 是基于规定的,有基于像 Visitor 的改写方式,以及基于这种 Query patterner 的改写方式。基于 Visitor 的比如像谓词下推,列裁剪等。CBO 是基于 Cost,是用 Cascade 这种搜查框架对 Join 启动 Reorder。同时优化器还允许一些初级的优化手腕,像 runtime filter,或许像 CT 的一些优化等等。

优化的成果也发过文章,在 ByConity 最后 GA 的时刻,就对比了业界的一些比拟盛行的开源产品,在 TPC-DS 的规范数据集上跟这些产品做了 Benchmark,结果 ByContiy 全体性能十分好。可以在外面找到这些文章看 Benchmark 的细节。其真实 ByConity 开源并启动了一年迭代之后,也有了更多的性能优化,包含像 QPS 的优化、Projection 的优化等,这些优化会进一步优化性能。目前假设再从新做 TPC-DS Benchmark 会进一步优化。

除了自身的性能优化以外,ByConity 还有一些在真正消费经常使用当中所须要的十分关键的才干,比如说分歧性。ClickHouse 另外一个比拟痛的点就是它不足分歧性,由于它自身是不允许事务的,它只能在一个有限的范围内允许必定的原子性 ACID 级别,但这在很多业务场景下是不够的。假设不允许事务,在很多时刻一旦抢先出现 fail,须要启动 recover 的时刻,或许说数据有必定的意外,须要启动 Retry 等一些操作的时刻,假设不足分歧性,会对 OLAP 中的数据发生很大影响,也会影响到后续的业务剖析以及后续系统的正确性。所以在 OLAP 系统中,事务和分歧性也是比拟关键的。在 ByConity 中是允许散布式事务的,并且能够允许到 Read committed 的隔离级别。怎样做到的呢?首先 ByConity 有一致的元数据层,这个元数据层是用 FoundationDB 开源组件成功的,FoundationDB 自身允许原子性操作,比如像 CAS,所以 ByConity 可以很好地利用 FoundationDB 的才干去成功散布式事务当中的一些比拟关键的原子操作。另外就是引入了散布式的时钟,就是这个 TSO 组件可以为散布式事务提供干燥递增的事务 ID。这是比拟关键的散布式事务中的组件吧。由于这些组件的允许,可以成功典型的两阶段提交。在阶段一写入数据的时刻,可以同时写入事务 ID,并且将 undo buffer 写入远端的存储并提交元信息。第二阶段是对这个事务真的启动提交,提交事务的时刻,可以依据事务记载的提交时期启动处置。比如假设事务执行成功,可以真正更新 part 的提交时期,把 undo buffer 清算掉,并且把这个事务的记载点给清算掉。假设事务失败,须要启动一些回滚。那刚才记载的 undo buffer 就可以在回滚中施展作用,首先把两边环节的 Part 数据删掉,由于失败它曾经没有用了。依据 Undo buffer 把远端存储当中曾经写了的数据启动回滚,同时在这些都处置好之后,再把 Undo buffer 和事务记载给处置掉,这就是一个十分典型的两阶段提交的散布事务操作。由于这样的允许,ByConity 在分歧性上方是有很好的保证。

另外由于是存算分别架构,所以大家或许会比拟担心一些疑问,比如说对远端存储的数据 IO 是不是真的能够满足查问的须要?所以在 ByConity 对冷读,也就是间接对远端存储读写的操作,做了很多的优化。冷读的性能无论如何都会比曾经在 Disk Cache 当中缓存的数据的热读操作还是要慢。ByConity 不时在对这个环节启动优化,使得它对整个系统的查问影响尽量小。这些优化手腕包含很多很细节优化,很多也是自创了操作系统的 IO 优化手腕,以及其余散布式系统中的 IO 优化手腕。上方引见其中的一些。

比如 IO schedule 就是一个比拟关键的组件,这个组件能够让 IO 恳求的并发量比拟大,并且恳求所触及到的数据比拟凑近的状况下,能够获取比拟好的优化成果。首先会对 lO 恳求启动必定的兼并和合成,兼并是针对比如两个 lO 恳求比拟小,但它其实是相邻的,或许说基本上相邻,两边或许隔了很少的一局部数据,那可以把这两个 IO 恳求兼并成一个。拆分是说有的时刻一个 IO 恳求十分大,它所触及到的数据块十分大,假设间接启动恳求的话,会有一个比拟高的等候时期。所以在这种状况下,咱们可以把它拆分红多个 lO 恳求,而后驳回并发方式去 load 数据。这两种状况在真正 IO 环节中其实都会有。

同时 ByConity 也会做一些 Prefetch 预读,尤其是在远端存储的单次 IO 恳求比拟高延,然而可以引入很多并发的状况下,它能够上班得十分好。另内在预读的时刻,ByConity 引入了很多细节的考量,能够在 ClickHouse 的数据结构状况下使预读成果尽量的好。咱们知道 ClickHouse 对远端数据的 IO 读取,是用 Mark range 作为单位的,在读取一个 Block 数据的时刻,它会看 mark 的 range,在每个 mark range 中咱们可以把数据合成成多个 task 去启动并行的读取。尤其在 S3 这样的存储时,可以去发很多的并行读的线程去同时做读取,在这种时刻拆分红 task 是十分有效的。这些 task 区分去做 IO 的读取,同时在这个环节当中还会引入比如 task stealing 的操作,比如有的线程十分重的话,它所承的一些 task 可以被其余线程 steal。优化环节中也经过了很多迭代,对比成功的第一个版本发现 task 是依照 mark range 平均散布的。但发现成果不是特意的好,由于在这个当中有很多延续的数据块,还是可以稍微兼并一下,所来成功了一个版本会把 Mark Range 进执行态散布,会依据读取数据的恳求的 mark range 延续性去做。同时这些 task 也会被多个线程去散布式执行。同时咱们也发现线程启动 task 的时刻有一个比拟长的启动时期,在这里也启动了很多异步化的处置,能够让启动时期尽量的少。经过一系列的冷读优化后,无论是从 HDFS 还是从 S3 去做冷读数据读取,都比最后的版本好很多。假设大家用到比拟早期的 ByConity 版本,遇到冷读这共性能感觉有疑问的话,可以尽快更新到最新的版本。

接上去引见 ByConity 典型的经常使用场景。首先是字节外部的一些经常使用,引见一个抖音个人做行为剖析的场景。首先抖音的数据量是十分大,在这个场景中抖音的用户行为数据在经过埋点日志上报之后,它会在数仓层建模去寄存这些埋点数据,以及有像用户画像的关系数据。这些数据有离线的,也有实时的。实时这块还是还在存算分别变革迁徙环节中。但离线这块曾经齐全从原来存算一体的版本迁徙到存算分别版本,也就是 ByConity 中。所以说抖音行为剖析的离线剖析,曾经齐全可以在 ByConity 外面做。它是对整个抖音的用户行为剖析平台启动了很好的撑持。这个平台被称为>

由于 ByConity 是开源产品,有其余的公司基于 ByConity 做平台的通常。那这边引见一个展心展力,基于 ByConity 的可观测平台的通常。可观测也是 OLAP 查问引擎的畛域用的十分多的场景,那么展心展力的这个场景也是比拟典型的。客户端上报的日志,以及有一些可观测的工具上报目的,经过实时链路传输到 OLAP 引擎中,而后再由 OLAP 引擎做作为计算层,对上方的BI 剖析以及报表运行提供引擎的计算才干,展心展力在 OLAP 的迭代也有一个环节,最早是经常使用了 ES,前面换成了 ClickHouse,如今最终再换成 ByConity,所以这个也是从 ClickHouse 迁徙到 ByConity 的一个十分典型的场景,迁徙的成果也十分好。首先性能,由于 ByConity 性能在很多或大局部的查问场景下,关于 ClickHouse 是有长处的。尤其是查问相对比拟复杂,或许说有一些比拟不凡的场景,比如像 like 这样场景状况下,都有一些显著的性能长处。这些性能长处会造成做雷同查问的流量,处置会比用原先用 ClickHouse 须要更少的资源,所以可以帮整个 OLAP 层节俭很多的资源。展心展力的 CPU 和内存资源都获取了相当水平的节俭。另外展心展力自己引入了另一个十分好的,称为定时扩缩容的方式机制。这个定时扩缩容的意思是可以在系统流量波峰的时刻,把资源启动扩容,而后在流量波谷的时刻再启动缩容,由于存算分别架构以及扩缩容无感的长处,使得扩缩容可以做得十分频繁,并且运维的代价十分低,所以这种方式也可以十分好的节俭他们的老本。假设说原本这些资源是预备好的,那在如今,就可以进执行态的伸缩。

最后引见 ByConity 未来到的版本 1.0。这个版本有一些从新的定位,以及一些新特性。首先说 ByConity 1.0 版本提供了三个外围的观点。首先就是不时秉持的业界抢先的性能长处,由于 ByConity 性能,刚才也引见了有很多优化手腕。除了自研的优化器处置自身 ClickHouse 的多表 Join 的场景以外,在过去的一年的迭代当中也做了很多的优化,所以全体性能必需是业界抢先的。另外存算分别从设计之初时,整个架构设计就是秉持着云原生和存算分别的理念去启动设计的,称为整个业界最纯正的存算分别的版本,整个 worker 层是真正有形态的,真正是可以无感扩缩容的。这是不时秉持的理念,另外一个是宿愿新引入的一个理念:完整的数据仓库。ByConity 1.0 不只可以定位成一个 OLAP 层引擎,而且宿愿把它定位成一个完整的数仓,也就是说宿愿 ODS 层就可以从 ByConity 开局去树立,也要提供一系列的才干。能让数仓的树立不只仅是能够做它的查问层,同时也可以做数据的处置,包含 ELT 才干。

首先是 ELT 才干,就是宿愿能够把 ByConity 定位成一个数仓引擎的十分关键的性能,ELT 才干是指在 ByConity 外部进能够启动必定的数据处置,能够启动长义务的允许,这个区别于之前 ClickHouse,它就是查问层引擎的定位。定位是查问层引擎的话,基本上一切的查问都是同步的,都是短时的,在这种状况下,它整个的计算层以及存储层设计就专门针对短时的查问启动优化,跟须要启动数据处置的长义务允许是齐全不一样的。比如须要去启动长时义务的状况,首先须要异步化的变革,须要引入查问队列入。对 Server 以及 worker 里的很多才干启动了变革和扩大。比如在 server 引入了队列的 manager,以及维持多个队列的方式。在 worker 中引入了启动资源管控的一些模块,也结合 resource manage 才干,可对整个 worker 里的资源消耗状况启动很好的管控。同时也可以对整个查问的资源启动预估。在这种状况下就可以很好的去评价一个查问,它究竟须要经常使用多少资源,目前这个资源够不够等?假设不够的话可以把它放到队列外面稍后去执行。假设够的话,驳回哪些 worker、哪些资源去启动计算?整个这块启动了很好的变革和允许。同时也启动了整个执行形式的变革,从整个 MPP 执行形式改形成为 BSP 的形式。BSP 形式咱们以为是分阶段的一个形式,它关键的理念是下一个阶段的执行都必需等到上一个阶段执行齐全成功之后才会启动。跟原来 MPP 形式有很大的不一样。在 MPP 形式很多的并行计算义务以及资源会在一开局就 plan 好,并且调配好。调配好之后,当中很难去灵活扭转,当中假设出了疑问,它也能只能从头开局重试,没有方法从两边的出疑问的点开局重试。那 BSP 形式就可以很好地处置这个疑问,这也是为什么能够撑持长时义务的十分关键的点。BSP 形式从执行的分阶段启动,除了这个撑持之外,它还须要可以经过磁盘启动数据的 shuffer 的一个十分关键的性能。这两特性能要能够很好地整合,咱们才干够对 BSP 形式启动十分好的允许。基于磁盘数据 shuffer 是 ByConity 1.0 外面会引入的一个十分关键的才干。例如在一个 worker 内有必定数据计算结果之后,会把这些两边结果落地到 worker 的磁盘当中,并且 exchange manager 可以让其余的 worker 从磁盘中启动读取。这也是允许长时义务所要求必备的基于磁盘的 Exchange 才干。同时在 1.0 还会提供一些比拟初级的才干,比如 Adaptive query execution 才干。AQE 其实是在启动 Spark 和 Flink 运行的时刻都会遇到的比拟初级的 Adaptive 的才干。在 ByConity 1.0 也会提供比如说像这种 parallelism 的智能调整的 AQE 才干。

另外一个比拟关键的 1.0 提进去的是湖仓一体才干。湖仓一体是 1.0 宿愿能够用湖上建仓的方式去启动这个湖仓一体的树立。也是依赖 ByConity 1.0 提供进去的很多才干去启动的。在湖仓允许方面,ByConity 1.0 很好地对接到 Hive meta store,能够对 Hive meta store 的元数据启动很好的处置。除了能够间接读取元数据之外,还能够对元数据启动缓存以及启动智能的从 Hive Meta store 启动同步。除此以外,还对很多类型的外表做了允许,比如 Hive 的外表,以及 Hudi 格局的外表也做了很好的允许。在数据结构方面,对 Parquet 和 ORC 的数据结构都启动了很好的允许。同时也允许在 HDFS 和 S3 里启动存储允许。为了进一步减速数据湖的外表查问在仓外面的查问性能,引入了物化视图,允许了多种物化视图。除了基于单表的同步物化视图以外,还可以启动多表的异步物化视图的构建,同时也可以对外表启生物化视图,也就是对外表的查问的两边结果可以物化上去放在物化视图里,前面就智能的查问改写,查问恳求间接经过访问物化视图的方式获取,不用真正去访问远端的湖外面的这些数据。同时也允许外表和内表能够启动关联查问,在很多湖上建仓的场景下也是十分广泛的。这样的话离线数据进湖,实时数据进仓,可以对实时数据和离线数据启动关联的查问。这些才干的允许就可以给融合数仓和数据湖的运行,提供了一个十分好的参考形式。前面还会进后退一步地迭代开发,在 1.0 之后,还会提供比如说数据湖的写入这样的才干。一些像仓下存湖的场景能够获取进一步的允许。

另外一个 1.0 外面比拟关键的才干是倒排索引。倒排索引其实是 ClickHouse 社区原本不时在迭代、允许的才干。在 ByConity 里倒排索引才干启动了必定的增强。首先在分词方式方面,允许 token 分词,Mgram 分词。除此以外,还允许中文分词,引入中文的分词库,经过性能分词库去启动中文的分词。同时引入了词组婚配和相似度的检索,目前还在开发,在下一个版本 1.0 会真正上线这个才干。这些才干上线之后,整个倒排索引会使得像这种 like查问的场景下,性能获取十分大的优化。比如说查问耗时能够降落 3- 4 倍,同时对 L(load)的恳求也能降落 4- 5 倍。这个场景大家会人造地联想到 elastic search,由于这个场景是 elastic search 的典型场景,那经常使用 ByConity 去做倒排索引的文本检索,关于 elastic search 有什么长处呢?首先它的整个架构设计,以及自身这个 OLAP 引擎性能的长处,写入的吞吐量是十分大的,同时查问性能也相比 elastic search 有更低的延时。这个是自身曾经具备了的性能长处。同时由于存算分别的架构,可以做很好的资源隔离。所以负载可以做得更平衡,运维老本也可以做得更低。另外就是易用性,由于 ByConity 是一个基于 SQL 的数仓引擎,它的经常使用就是规范 SQL 语法。还允许了很多种不同的 SQL 方言,所以经常使用上方来讲比 elastic search 要易用很多。

最后引见 1.0 推出后兼容性方面的允许,也就是 MySQL 兼容性。由于 ByConity 自身基于 ClickHouse,所以它对 ClickHouse 生态的允许以及 ClickHouse 的 SQL 的语法兼容性必需是没有疑问的。然而在很少数仓经常使用场景下,很多用户其实更宿愿能够经过 MySQL 的方式去经常使用数仓。或许说他们如今数仓经常使用场景外面就曾经经常使用了 MySQL 很多的特性,以及曾经有很多积攒在 MySQL 上方,比如说 SQL 或许工具的经常使用等,都宿愿在 MySQL 的生态方面获取允许。所以在 1.0 版本对整个 MySQL 生态启动了片面的允许。那这个允许包含语法、函数、数据类型,包含 DQL、DML、DDL 等都启动了逐一排查去允许它。整个的允许兼容度是大于 90% 的,对一些目前没有兼容的,也在会在 SQL 层里做很好的说明,说清楚可以有什么代替方法或许改写方法。基本上可以保证什么呢?就是曾经经常使用了 MySQL 生态的工具的,比如说 BI 工具像 Tableau、quick BI、Fine BI 等等,或许说一些 IDE 工具,MySQL workbench, DBeaver, Navicat 等,经过这些工具能够无缝地经常使用和衔接到 ByConity去做各种查问或许各种操作。同时一些典型的 driver,像 JDBC driver,走 MySQL 协定连出去也是可以的,都能够无缝允许没有什么疑问,尽量保证经常使用的时刻是可以兼容的。

接上去引见 24 年整个迭代的路途。1.0 版本是下一个版本,这个版本或许会在 Q3 中,比如说 7 月底时期点收回来。整个一整年的迭代都会有各类性能的树立。其实上半年曾经成功了刚才提到的湖仓才干、MySQL 兼容性、LT 以及全文检索的才干树立。这些才干也不是一下放出,而是在那之前,比如 0.2、0.3 等版本中陆续放出这些才干的性能点。之前是以性能点的方式在小版本中提供进去,在 1.0 版本会以为整个树立能够比拟完备,是一个可以到达 GA 形态的版本,大家可以真正在消费环境下去比拟完整地经常使用这些方面的才干。下半年还会对上述的这些畛域进后退一步的允许,比如说在湖仓畛域会允许 iceberg 以及 Hudi 和 iceberg 写入等。另内在性能这块也是不时秉持的,必定要做到业界最优性能这样宗旨。所以在性能这块会不时不停地去做迭代,会有更多的性能优化点,像 Zero copy、一些系统的变革能够让性能获取进一步优化、散布式的缓存等。同时在生态这块也会进一步地允许,比如 ClickHouse,要不时是兼容它的生态,然而 ClickHouse 也在开展环节中。后续有更新版本的 ClickHouse,也会去思考对它的新 SQL 启动必定允许。同时也排汇了自于社区的一些反应,就像元数据,有很多社区小同伴反应说 Fundation DB 的运维是他们的痛点,Fundation DB 自身外面成型的生态及工具比拟少。前面会在思考对整个元数据启动重构,一方面看一下能不能缩小元数据存储的累赘。另一方面也可以看一下 FDB 的经常使用有没有代替。之前选型 FDB 产品也是由于性能上思考,还有比如像 range 查问等,这些须要依赖 FDB 的优越的性能,咱们也会获取必定的重构以及其余方案的允许。

您可能还会对下面的文章感兴趣: