百度BaikalDB在同程艺龙的成功应用实践剖析

见贤思齐

导读：文章主要介绍 BaikalDB在同程艺龙的完整落地实践，文章把BaikalDB总结为六个核心特性，分别是《BaikalDB高可用与HTAP特性实践》、《BaikalDB 高性能与扩展性实践》、《BaikalDB 低成本的思考》，希望对大家有帮助。全文14032字，预计阅读时间 19分钟。一、BaikalDB高可用与HTAP特性实践我们从2019年开始调研开源NewSQL数据库BaikalDB，尝试解决工作中遇到的一些实际问题，例如OLAP业务跑在行存数据库上查询速度慢，数据库跨中心部署高可用方案待完善，在近6个月的研究与实践中，我们向社区提交了列存特性，并使用BaikalDB分别部署了基于列存的OLAP类业务，基于行存的OLTP类业务，及基于双中心的高可用部署方案，有效的解决了相关问题，在这里做一个相关使用经验的分享，希望可以给遇到类似问题的同学提供参考。1、BaikalDB选型考虑1.1业界纷纷布局NewSQL1.2 NewSQL数据库核心技术对比注1：ShardingSphere基于MySQL MGR的Paxos复制协议尚未发布。注2：TiDB 3.0起已同时支持乐观事务与悲观事务。注3：由于笔者精力所限，尚有很多NewSQL未参与对比：Amazon Aurora，Aliyun PolarDB， AnalyticDB，Apple FoundationDB， CockroachDB, 华为GaussDB， Yandex ClickHouse等。1.3 NewSQL技术选型路径选择：纯自研：能力有限，投入有限纯开源：无法及时满足定制化需求云服务：安全与成本考虑，短期内核心业务自建IDC，k8s化半自研：我们的选择，不重复造轮子，主体功能交由社区完成，集中有限力量满足公司需求，可供选择的NewSQL有：TiDB，BaikalDB，CockRoachDB等。从以上几款开源DB中，最终选择BaikalDB的原因有：背景相似：BaikalDB来源于百度凤巢广告业务团队，由于广告业务的增长走过了从单机到分库分表到分布式的全过程，而我们面临类似的问题。经受考验：已经有百度广告平台多个业务实际使用经验，千级别集群节点，PB级数据规模，我们跟进使用，风险可控。技术栈匹配：BaikalDB（c++实现， 10万行代码精炼），依赖少而精（brpc，braft，rocksdb），社区友好，部署简单，技术栈匹配。特性比较完善：基本满足我们需求，我们可以专注于满足公司需求。1.4 BaikalDB简介BaikalDB是一款百度开源（github.com/baidu/BaikalDB ）分布式关系型HTAP数据库。支持PB级结构化数据的随机实时读写。架构如下：其中：BaikalStore 负责数据存储，用 region 组织，三个 Store 的 三个region形成一个 Raft group 实现三副本，多实例部署，Store实例宕机可以自动迁移 Region数据。BaikalMeta 负责元信息管理，包括分区，容量，权限，均衡等，Raft保障的3副本部署，Meta 宕机只影响数据无法扩容迁移，不影响数据读写。BaikalDB 负责前端SQL解析，查询计划生成执行，无状态全同构多实例部署，宕机实例数不超过 qps 承载极限即可。核心特性：强一致：实现Read Committed 级别的分布式事务，保证数据库的ACID 特性高可用：Multi Raft协议保证数据多副本一致性，少数节点故障自愈， 支持跨机房部署，异地多活，可用性>99.99%， RTO=0， RPO1W 点查 P95 x limit 1000;?语法。io.util满可导致rocksdb的L0层文件压缩不过来，出现快速的空间放大，进而导致磁盘快速被写满。相关参数：max_background_jobs=24rocksdb数据文件不建议超过1T，按照默认配置，超过1T后rocksdb将增加1层，写放大增大10，写放大会导致io.util出现瓶颈。若服务器磁盘远大于1T，建议单机多实例部署。io.util满可导致内存刷盘不及时进而引起内存满（store）；慢查询过多时，会导致查询积压于store，进而引起内存满（store）；相关参数db：slow_query_timeout_s=60s?；store内存建议配置为所在实例的40%以上，因为内存直接影响cache命中率，cache miss过多的话，会增大io.util及sql用时；相关参数：cache_size=64Mexport TCMALLOC_MAX_TOTAL_THREAD_CACHE_BYTES=209715200 #200M，当大value时，调大可以避免线程竞争，提高性能 。CPU : 多发生在读qps过大时（db，store），可监控vars/bthread_count指标IO：多发生在写qps过大时（store），可监控io.util指标，及store/rocksdb/LOG日志。Mem：Disk：NetWork：3.1.1用户视角联合主键 vs 自增主键BaikalDB是按主键进行分片的，主键的选择影响了数据的物理分布，好的做法是把查询条件落在尽量少的分片上，查询时基于前缀匹配，一般建议按范围从左到右建立联合主键，例如：class表主键可设置为schoolid，collegeid，classid # 学校，学院，班级;BaikalDB实现自增主键主要是为了与MySQL兼容，由于全局自增是通过meta单raft group完成，会存在rpc开销及扩展性问题；另外全局自增主键也容易导致数据批量插入时请求集中于最后一个Region节点，容易出现瓶颈。全局索引 vs 局部索引全局索引与主表不在一起，有自己的分片规则，好处是有路由发现功能，坏处是多了与全局索引的RPC开销，局部索引与主表一起，需要通过主键确定分片，否则需要广播，好处是RPC开销。小表建议用局部索引；大表（1亿以上），查询条件带主键前缀，用局部索引，否则用全局索引。行存 vs 列存宽表少列（查询列/总列数 小于 20%）， 聚合查询的olap请求用列存其他情况用行存3.1.2实现视角Balance：BaikalDB会周期性的进行Leader均衡与Peer均衡，负载均衡过程中若数据迁移量较大，可能是影响性能，一般发生在：增删节点时批量导入数据时机器故障时SQL Optimizer：目前主要基于RBO，实现了部分CBO，若性能与执行计划有关，可以使用explain，及 index hint功能调优。3.1.3扩展性考虑因素稳定性meta，尤其是主meta挂了情况下，将不能提供ddl， 主auto incr 挂了情况下，将不能提供自增主键表的insert功能。store读正常，但瞬间一半store leader挂了情况下，写功能需要等到所有leader迁移至健康中心为止。扩容：从实测情况看，扩容情况下比较平稳缩容：缩容较少发生，但在双中心单中心故障的情况下，相当于缩容一半，此时稳定性还是值得注意与优化的，主要包括：极限容量：计算逻辑如下理论上Meta 20G， Store 1T磁盘情况下，预计可管理 10k个store节点， 10P大小数据。实际上百度最大的集群管理了1000个store节点，每store 1T磁盘， 共计约1P的集群总空间。Region元数据=0.2k， Meta20G内存共计可管理的 Region总数 = 20G/0.2k = 100MRegion数据量 = 100M，Store 1T磁盘共可管理的 Region个数每store = 1T/100M = 10k共计可以管理的数据量 = Region总数 * Region数据量 = 100M * 100M = 10P共计可以管理的store个数 = Region总数 / Region个数每store = 100M/10k = 10k线性固定范围：O（1）可以下推store全量：O(n/db并发度)不可下推store全量：O（n）JOIN查询：O（n^2）4、后记本文的性能与扩展性分析数据均来源于实际项目，而非TPCC，TPCH标准化测试，但测试项目具有一定的代表性。BaikalDB测试数据基于V1.0.1版，最新发布的V1.1.2版又有了较多优化：优化seek性能，实测range scan速度提高1倍；rocksdb升级6.8.1，使用Partitioned Index Filters，进一步提高了内存使用效率；增加利用统计信息计算代价选择索引功能（部分）；事务多语句Raft复制拆分执行，提高了Follower的并发度。三、BaikalDB 低成本思考这也是我们在业务推广中的关注次序，即1、首先必须（Must to）业务场景匹配精?准（1一致性）和运行平稳（2高可用）；2、其次最好（had better）是数据多（3扩展性）与跑的快（4高性能）；3、最后应该是（should）使用友好（5高兼容性）与 成本节省（6低成本）。简称：稳准多快好省。作为系列文章的最后一篇，是关于成本的思考，如果说强一致与高可用是用户关心的在功能上是否满足需求，扩展性与高性能是老板关心的在规格上是否值得投入，那么兼容性与成本则是项目实施者应该关心的问题，因为它关系到项目推进难度。如果你认可NewSQL的发展趋势，也发现了公司的实际业务场景需求，本文将会讨论在项目实施中需要克服的问题，并建议用成本的角度进行评估，这样有助于对项目的工作量进行计算。例如如果调研发现公司的潜在目标用户均跑在mysql数据库上，那么是否兼容mysql协议直接决定了用户的意愿，用户的学习成本，业务代码的改造成本，生态的配套成本，如果潜在用户超过10个以上则成本将会放大10倍；如果大部分潜在业务使用的是PostgreSQL，那么最好在选型时选择兼容pg的NewSQL。这也是本文将兼容性归类到低成本一并讨论的原因。1、成本的分类狭义的成本：指数据库软件的开发，授权，运维及硬件成本，特点是可量化，例如：1、开发投入：24人月2、License授权：10万/年3、运维投入：DBA 2人4、硬件成本：服务器10台广义的成本：泛指在组织实施数据库应用工程实践过程中，所产生费用总和，特点是与项目管理与实施有关，包括：1、学习开发成本2、测试验证成本3、业务迁移成本4、用户习惯5、运维配套工具6、软件成熟度7、技术前瞻性狭义的成本可以理解为这件事值不值得做，广义的成本可以理解为把事情做成需要做的工作，截止到本文发表为止，BaikalDB已在公司10余家业务上进行了落地应用，这些应用实际产生的成本与收益如何评估（狭义）？项目落地过程中需要落实哪些工作(广义）？下面将就这两个问题展开讨论。2、狭义的成本理论上可减低100倍由于BaikalDB是开源的，开发成本可以忽略，部署简单，其狭义成本主要集中在硬件成本上。结合公司的双中心建设与Kubernetes云原生平台战略，我们给出了BaikalDB两地四中心三副本行列混存的方案，理论上有望使硬件成本降低100倍，方案如下图：1、注1：图中省去了meta节点部署2、注2：每个IDC会实际部署了多个store与db节点。3、注3：行列混存的特性还在开发中上图采用了完全对称的双中心部署方案，每个数据中心又存在2个对等IDC机房，基于BaikalDB的逻辑机房与物理机房概念，可以完成以上部署，并提供城市级别的容灾能力，通过Raft Group层面的行列混存技术实现仅需3副本即可提供HTAP的能力，配置细节已经在第一篇文章HTAP部署有所描述，本文在之前基础上增加了行列混存（功能尚未实现）的方式，进一步合并了应用场景，减少副本个数，从而达到节约成本的目的。以上方案具体成本节约主要体现在三个方面：2.1 HTAP带来的成本降低为5倍为了满足不同的应用场景，通过同步工具，数据会被分发到ETL，ES，HBASE，kafka，TiDB等不同数据组件中去，核心业务的存储资源存在5倍以上的放大。依据数据库使用现状情况，核心业务一般1套OLTP主库+数据同步平台+5套OLAP数据库，采用此方案后能同时满足以上全部场景，并且省去了异构数据源之间数据同步延迟问题，因为异构数据源超过了5个，合并为1个后，预计收益增大5倍。2.2 单位资源效能带来的成本减低为4倍行存OLTP类场景性能提升85%BaikalDB存储层使用RocksDB的LSM-Tree存储，相较于innodb的B+树，通过平衡读，写，空间放大使得读写性能更加均衡，通过out-of-place update及一定的空间放大来优化写性能（对比innodb相当于牺牲全局有序性及存储空间换取写性能），能充分发挥SSD硬盘的随机读优势及利用高效缓存来加速点查询，对于范围查则主要通过data reorganization（merge/compaction）及SSD的并发读来优化速度。参考第二篇性能测试文章的基准性能测试结果，适用于OLTP场景的行存BaikalDB综合性能可提升85%。列存OLAP类场景性能提升10倍OLAP类场景下的SQL查询语句一般是宽表少列，以聚合函数为主，数据比较适合按列存放在一起，一个例子如下：cstore vs rstoreDemo#统计每个广告平台的记录数量SELECT?CounterID,?count()?FROM?hits?GROUP?BY?CounterID?ORDER?BY?count()?DESC?LIMIT?20;行式列式使用BaikalDB的列存引擎，使我们第一家接入OLAP业务（约100亿数据量的聚合查询）查询速度提升10倍。业务一般会有1个OLTP场景加n个OLAP场景组成，平均来看BaikalDB可以使单位资源效能提升4倍左右。2.3 云原生弹性能力带来的成本减低为5倍以mysql为例，由于缩扩容升降配困难，为了应对少数发生的业务高峰时段（例如双11一年只有一次）而不得不一直留够Buffer，导致硬件资源的投入不能随着流量的变化而动态变化，弹性不足，资源利用率普遍较低约8%的水平。公司也意识到相关问题，在积极构建基于kubernetes云原生平台（见下图），具体文章参见同程艺龙云原生 K8s 落地实践[4]?。BaikalDB的share –nothing云原生特性能完美的k8s的调度能力进行结合，预计可以把资源利用率提升到40%，因此弹性收益为5倍。之所以没有提升到80%以上是为了满足双中心容灾互备的需要，以应对城市级故障带来的单中心双倍压力。综上所述，总收益 ?= ?HTAP收益 ?* 单位资源能效收益 * 资源利用率收益 = ?5 * 4 * 5 = 100倍3、实际上广义的成本难以量化但不能有短板在狭义成本评估值得做的情况下，需要从项目管理或项目实施的角度思考如何把项目顺利推进，由于每家公司每个项目的实际情况均不一样，项目的评估很难统一量化，但我们在进行项目实施时必须要慎重考虑这些因素，并且任何一个环节不达标均可能导致项目的失败，在这里把项目推进中要完成的工作量称为广义的成本，以我们实践经验进行总结评分，满分为10分，分值越高越好，评价不同于以往的性能测试，具有很强的主观性，仅供参考。3.1 学习开发成本：9分BaikalDB的学习主要包括依赖与BaikalDB代码本身。BaikalDB的依赖少而精，主要有三个：1、brpc：Apache项目，百度内最常使用的工业级RPC框架；2、braft：百度开源的Raft一致性与复制状态机工业级实现库；3、RocksDB：kv存储引擎，集成了Google与Facebook双方大牛的力作；以上三款开源项目，社区都比较成熟，每一款都值得好好学习。BaikalDB本身作为一款纯开源的分布式数据库，代码10万行，以C++语言为主，代码架构简洁，组织清晰。虽然目前文档不是很多还在完善中，但项目保持了良好编码风格，代码可读性强，大部分实现原理可以通过直接阅读代码掌握，少部分需要结合数据库及分布式领域的理论知识与论文学习。在模块化抽象与分层上保持清晰保持简洁，在一些核心对象例如逻辑计划：LogicalPlanner，表达式：ExprNode，执行算子：ExecNode?仅有一层继承关系，具有薄胶合层显著特点，有效的减低了软件的学习成本，体现了Unix开源文化的KISS原则（Keep It Simple， Stupid！）总之，BaikalDB是一款非常值得学习的DB，给9分。3.2 测试验证成本：7分BaikalDB的测试验证工作量与其它DB差不多，中规中矩给7分。3.3?业务迁移成本：8分业务的迁移成本主要包括数据迁移与SQL改写两个部分，由于BaikalDB兼容MySQL协议，公司已研发了基于MySQL生态的数据同步平台，数据迁移成本不大。使用MySQL开发的业务代码，大部分情况不需要改写SQL，改写主要发生在BaikalDB尚未支持的MySQL语法例如（子查询，一些系统函数上）和慢查询改写上面，业务迁移成本给8分。3.4 用户习惯：7分1、图像化工具：能使用Navicat， IDEA自带MySQL UI， DataGrip进行简单的表浏览，SQL执行功能，不能进行复杂管理操作；2、公司已有系统对接（例如工单，权限，一站式查询等）：尚未打通；3、对新概念的接受过程（例如新的数据文件，部署方式，资源隔离，多租户等）。3.5 运维配套工具：7分备份工具：热备：基于SST的备份恢复冷备：通过SQL语句逻辑备份。/{"full_export":true}/ select * from tb where id > x limit 1000;监控工具：Prometheus运维脚本：script[5]部署工具：Ansible压测工具：sysbench订阅工具：Binlog功能开发中同步工具：Canal3.6 软件成熟度：7分3.7 技术前瞻性：9分BaikalDB提供的PB级分布式扩展能力，动态变更Schema能力，分布式事务，异地多活，资源隔离，云原生K8s，HTAP能力均与公司未来的需求或规划匹配，因此给9分。4、后记至此BaikalDB在同程艺龙的应用实践系列文章就结束了，BaikalDB作为一款开源两岁的NewSQL数据库还非常年轻，存在很大完善空间。同时作为后浪也借鉴很多前浪的设计思想，有一定的后发优势。BaikalDB实现简洁，功能强大，社区专业友好，无论是用来代码学习还是业务应用均有很大成长空间，欢迎感兴趣的朋友一起参与。由于笔者水平有限，文中如有不妥之处，还望理解指正。招聘信息百度商业平台研发部主要负责百度商业产品的平台建设，包括广告投放、落地页托管、全域数据洞察等核心业务方向，致力于用平台化的技术服务让客户及生态伙伴持续成长，成为客户最为依赖的商业服务平台。无论你是后端，前端，还是算法，这里有若干职位在等你，欢迎投递简历， 百度商业平台研发部期待你的加入！简历投递邮箱：geektalk@baidu.com （投递备注【百度商业】）推荐阅读：｜面向大规模商业系统的数据库设计和实践｜百度爱番番移动端网页秒开实践｜解密百TB数据分析如何跑进45秒#文末福利#「百度定制手机支架」来谈谈你对本篇文章的看法文末留言点赞第一名??我们将送一个百度定制手机支架（好用又好看哦～）截止时间：8月11日18:00