导读：文章次要介绍 BaikalDB在同程艺龙的残缺落地实际，文章把BaikalDB总结为六个外围个性，别离是《BaikalDB高可用与HTAP个性实际》、《BaikalDB 高性能与扩展性实际》、《BaikalDB 低成本的思考》，心愿对大家有帮忙。

全文14032字，预计浏览工夫 19分钟。

一、BaikalDB高可用与HTAP个性实际

咱们从2019年开始调研开源NewSQL数据库BaikalDB，尝试解决工作中遇到的一些理论问题，例如OLAP业务跑在行存数据库上查问速度慢，数据库跨核心部署高可用计划待欠缺，在近6个月的钻研与实际中，咱们向社区提交了列存个性，并应用BaikalDB别离部署了基于列存的OLAP类业务，基于行存的OLTP类业务，及基于双核心的高可用部署计划，无效的解决了相干问题，在这里做一个相干应用教训的分享，心愿能够给遇到相似问题的同学提供参考。

1、BaikalDB选型思考

1.1业界纷纷布局NewSQL

1.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， RPO<30s
  • 高扩大：Share-nothing架构，存储与计算拆散， 在线缩扩容不停服 5分钟内实现，动静变更schema 30s失效
  • 高性能：表1000张，单表：10亿行，1千列状况下：QPS >1W 点查 P95 < 100ms
  • 易用性：兼容MySQL 5.6协定

2、BaikalDB线上迁徙过程

咱们在线上已部署了50个存储节点百亿行数据规模的BaikalDB集群，本章将重点讲述业务迁徙到BaikalDB的步骤以确保上线过程安稳与业务无缝迁徙。整体的上线过程可分为如下几个阶段：

2.1 列存个性开发

因为咱们上线的首个业务是剖析类业务，适宜列式存储，在社区的帮忙与领导下，咱们开发并提交了列存个性，原理见列式存储引擎

2.2 配套运维工具

  • 部署工具：线上暂以自研部署脚本为主，将来会对接公司k8s；
  • 监控工具：Prometheus，BaikalDB对接Prometheus非常简单，参见监控指标导出到Prometheus
  • 数据同步工具：Canal + 数据同步平台，原理相似不再开展；
  • 物理备份工具：SSTBackup，应用阐明见基于SST的备份与复原 ，能够实现全量+增量的物理备份，外部数据格式，仅实用于BaikalDB；
  • 逻辑备份工具：BaikalDumper，模仿MySQLDumper，导出的是SQL语句，能够导入到其余数据库，目前只反对全量导出；
  • 测试工具：Sysbench 应用阐明见BaikalDB Sysbench
  • 欠缺的工具：基于MySQL binlog的数据订阅工具，开发中。

2.3 数据迁徙

数据同步采纳全量+增量同步形式，全量采纳批量插入，增量原理相似于MySQL binlog订阅，采纳Replace模式同步。共计80亿条数据全量同步约3天，增量同步稳固在10ms以内。

2.4 业务测试

通过数据同步环节，BaikalDB曾经具备与线上等价数据集，业务测试阶段重点在于看待上线零碎实在SQL的反对能力，咱们采纳全流量回放的形式进行。

如下图： 

通过实时回放线上实在流量咱们次要验证了：

  • 业务应用SQL的100%兼容性
  • 业务峰值的性能承载能力
  • 7*24小时的稳定性

2.5 业务上线

通过以上环节，业务上线须要的惟一操作就是更改数据库连贯配置。

2.6 运维与监控

下图是上线后局部指标Prometheus监控截图，能够看到从qps，响应工夫，环比变动看均非常安稳。

2.7 注意事项

BaikalDB尚在欠缺的性能：

  • 子查问：开发中
  • information\_schema：图形化工具反对与零碎变量反对不全，开发中
  • 行列并存：一张表可抉择行存或列存，但不能并存，开发中
  • 分布式时钟：影响事务隔离级别，与Follower一致性读，开发中
  • 视图：排期中
  • 触发器，存储过程等传统关系型数据库性能，暂无布局

应用BaikalDB须要留神的事项：

  • 数据建模：DB并不能取代数据库使用者的角色，好的数据模型，表构造的设计，主键与索引的应用，SQL语句，在咱们理论测试中比坏的用法会有10倍以上的晋升；
  • 写放大：与RocksDB层数无关，倡议单store数据大小管制在1T以内；
  • 参数调优：默认配置已十分正当，仅有大量参数倡议依据理论状况批改：
export TCMALLOC_SAMPLE_PARAMETER=524288 #512kexport TCMALLOC_MAX_TOTAL_THREAD_CACHE_BYTES=209715200 #200M，当大value时，调大能够防止线程竞争，进步性能-bthread_concurrency=200 # 倡议（cpu核数- 4）* 10-low_query_timeout_s=60 # 慢查问阈值，倡议依据需要设置-peer_balance_by_ip=false # 默认为false，单机多实例时倡议开启-max_background_jobs = 24 #倡议（cpu核数- 4）-cache_size = 64M #倡议不超过单实例内存空间40%
  • 大事务限度：行锁限度：per\_txn\_max\_num\_locks 默认100w；DB与Store RPC 包的大小限度：max\_body\_size默认256M；音讯体限度：max protobuf size =2G，此为protobuf限度不可批改。个别倡议事务影响行数不超过10M；
  • 双机房资源预留Buffer：资源使用率倡议40%左右，容灾时单机房须要承载double的压力，调配正本时disk\_used\_percent 超过80%的store将被剔除。

3、高可用与HTAP部署计划

咱们的BaikalDB一套集群部署在两个城市4个IDC机房，同时撑持基于行存的OLTP业务与基于列存的OLAP业务，本章将阐明咱们是如何通过设计部署计划来施展BaikalDB高可用与HTAP能力的。

双核心HTAP部署示意图：

  • 注1：图中省去了meta节点部署
  • 注2：每个IDC会理论部署了多个store与db节点。

如上图城市 A与城市 B双核心采纳齐全对称的部署构造，在BaikalDB里Region是存储的根本单位，每张表至多有一个Region组成，每个Region有若干个peer合在一起形成了一组Raft Group。每个store即可创立行存表也能够创立列存表，业务建表时能够依据场景的不同进行抉择，另外业务也能够依据地区的不同抉择正本的散布，例如城市 A的业务能够抉择城市 A 2正本+城市 B 1正本，城市 B的业务能够抉择城市 A 1正本+城市 B 2正本。

假如有2家业务在应用BaikalDB集群，业务A是一个部署在城市 A的OLAP类业务创立了表ctable用Region1代表。业务B是一个部署在城市 B的OLTP类业务创立了表rtable用Region2代表。则相干的配置过程如下：

  1. 初始化meta机房信息
echo -e "场景：增加逻辑机房bj sz\n"curl -d '{"op_type": "OP_ADD_LOGICAL","logical_rooms": {"logical_rooms" : ["bj", "sz"]}}' http://$1/MetaService/meta_managerecho -e "插入bj物理机房\n"curl -d '{"op_type": "OP_ADD_PHYSICAL","physical_rooms": {"logical_room" : "bj","physical_rooms" : ["bj1","bj2"]}}' http://$1/MetaService/meta_managerecho -e "\n"echo -e "插入sz物理机房\n"curl -d '{"op_type": "OP_ADD_PHYSICAL","physical_rooms": {"logical_room" : "sz","physical_rooms" : ["sz1","sz2"]}}' http://$1/MetaService/meta_manager
  1. 设置每个baikalstore的物理机房信息
#IDC1 store的机房信息配置#vim store/conf/gflag-default_physical_room=bj1
  1. 设置每个baikaldb的物理机房信息
#IDC1 db的机房信息配置#vim db/conf/gflag-default_physical_room=bj1
  1. 创立表时依据须要指定正本策略与存储类型
--业务A是一家部署在城市 A的OLAP类型申请采纳列存表，建表语句如下：CREATE TABLE `TestDB`.`ctable` (`N_NATIONKEY` INTEGER NOT NULL,`N_NAME` CHAR(25) NOT NULL,`N_REGIONKEY` INTEGER NOT NULL,`N_COMMENT` VARCHAR(152),PRIMARY KEY (`N_NATIONKEY`))ENGINE=Rocksdb_cstore COMMENT='{"comment":"这是一张列存表", "resource_tag":"bizA", "namespace":"TEST_NAMESPACE","dists": [ {"logical_room":"bj", "count":2}, {"logical_room":"sz", "count":1}] }';--业务B是一家部署在城市 B的OLTP类型申请采纳行存表，建表语句如下：CREATE TABLE `TestDB`.`rtable` (`N_NATIONKEY` INTEGER NOT NULL,`N_NAME` CHAR(25) NOT NULL,`N_REGIONKEY` INTEGER NOT NULL,`N_COMMENT` VARCHAR(152),PRIMARY KEY (`N_NATIONKEY`))ENGINE=Rocksdb COMMENT='{"comment":"这是一张行存表", "resource_tag":"bizB", "namespace":"TEST_NAMESPACE","dists": [ {"logical_room":"bj", "count":1}, {"logical_room":"sz", "count":2}] }';

长处：

  • 容灾能力：任何多数节点故障，无论是机器级，机房级还是城市级故障，均可做到RPO(数据失落时长) = 0s，RTO（数据恢复时长）< 30s。
  • Async Write：因为Raft少数Peer写胜利即可返回，尽管3peer会有1个peer散布在另一个城市存在提早，但写操作个别写完同城的2个peer即可，异地的peer在进行异步写，写性能靠近同城写性能。
  • Follower Read：因为每个城市至多有一个正本，对于读业务须要别离部署在两个城市的场景，BaikalDB提供了就近读性能，路由抉择时会优先选择与DB同在一个逻辑机房的Region进行读操作，所以读性能能够在两地均失去保障。
  • HTAP能力：业务能够依据业务场景别离抉择行存表与列存表，每个store能够同时反对这两种表。
  • 资源隔离：如果放心HTAP的业务workload会相互影响，业务能够通过resource\_tag字段对store进行分组，例如store1的resource\_tag = bizA， 那么store1只会给建表时指定resource\_tag = bizA的表调配Region。

待欠缺：

  • 容灾能力：少数节点故障RPO最大可到3s，BaikalDB正本的调配策略后续能够减少降级策略，如果少数机房故障，降级到在多数机房调配正本，从而保障RPO仍旧为0。
  • Async Write：当写产生在多数城市时依旧会存在提早，但这种状况理论业务很少产生；如确有须要例如两地业务均需对同一张表产生写操作，必然有一个处于异地写状态，这种状况倡议写时拆成两张表，读时用Union或视图。
  • Follower Read：能够加强为Follower一致性读。就是对Follower可能落后与Leader的申请进行弥补，须要分布式时钟个性（开发中）的反对。

二、BaikalDB 高性能和扩展性实际

![图片](https://p3-juejin.byteimg.com... "外围
个性")外围个性

这也是咱们在业务推广中的关注秩序，即

  • 首先必须（Must to）业务场景匹配精 准（1一致性）和运行平稳（2高可用）
  • 其次最好（Had better）是数据多（3扩展性）与跑的快（4高性能）
  • 最初应该是（Should）应用友好（5高兼容性）与 老本节省（6低成本）

简称：稳准多快好省。

本文将会通过介绍业务落地前的两个理论测试案例，来分享总结BaikalDB在性能与扩展性方面的数据。

1、基于行存OLTP场景的基准测试

1.1测试指标

如果把BaikalDB看成一款产品，基准测试的目标就是加上一份产品规格说明书，在性能测试同学的参加下，咱们进行了为期2个月的基准测试，并给BaikalDB这款产品的外包装上写下如下对于规格的信息：

  • 设计的集群最大规模，在 1000 个节点状况下，能反对 18 种数据类型，单节点 1T 数据容量，集群整体1P容量。
  • 在基准数据测试下，集群单点性能达到，write不低于2000 QPS，单次write不超过 50 ms， read性能达到不低于4000 QPS,单次read不超过 20 ms。
  • 对外接口根本兼容MySQL 5.6版本协定。
  • 基于Multi Raft 协定保障数据正本一致性，多数节点故障不影响失常应用。
  • Share-Nothing架构，存储与计算拆散，在线缩扩容对性能影响仅限于外部的数据主动平衡，而对外部通明，新增字段30s失效对集群无影响。

1.2测试范畴

  • 性能测试（行式存储，大表104字段，小表63字段，集群总根底数据1TB，2TB，3TB）
  • 与mysql基准比照测试
  • 表构造字段个数影响（大表104字段，小表63字段）
  • 集群总根底数据大小影响（1TB，2TB，3TB）
  • 表构造影响（"自增主键"，"片键做全局索引"，"片键做主键"）
  • 带压力的扩展性测试
  • 加节点（store）
  • 减节点（store）
  • 动静加列

1.3测试环境

五台机器混合部署3 meta, 5 db, 5 store获取基准，另有一台机器作为增减节点机动（centos 7.4 32核 2.4GHZ，128G内存 1.5TSSD硬盘）

测试部署

1.4次要指标阐明

  • 最佳容量（KTPS）：
  • 5台机器配置的集群（3 meta, 5 db, 5 store）
  • 间断两分钟能够稳固撑持的最大吞吐能力
  • 均匀读响应工夫小于20ms，均匀写响应工夫小于50ms
  • 零碎最大吞吐能力: 每秒dml操作申请数
  • 单位为KTPS（千次操作申请/秒）
  • 定义
  • 前置条件：
  • 响应工夫：dml操作从发送到收到返回后果所通过的工夫，单位为毫秒
  • diskIOUtil 磁盘使用率: 一秒中有百分之多少的工夫用于 I/O 操作,或者说一秒中有多少工夫 I/O 队列是非空的
  • 如果靠近 100%，阐明产生的I/O申请太多，I/O零碎曾经满负荷，该磁盘可能存在瓶颈。
  • 大于30%阐明I/O压力就较大了，读写会有较多的wait
  • 最佳容量断定办法

绘制零碎的性能指标随着并发用户数减少而呈现降落趋势的曲线，剖析并辨认性能区间和拐点并确定性能阈值。

1.5测试论断

  • 性能测试
  • 读：片键做主键模式，5节点读容量为72K+TPS，性能比mysql高85%+，瓶颈为CPU
  • 写：片键做主键模式，5节点写性能为9.6K+TPS，与mysql相当，为mysql的85%~120%之间，瓶颈为DiskIO
  • 扩展性测试
  • 加节点：前端吞吐安稳
  • 减节点：减节点操作须要确保集群能力有足够的余量，能承载被减掉节点转移的压力
  • 加列：22秒新列失效（1.25亿根底数据）

1.6性能测试详情

与mysql基准比照测试：

表构造字段个数影响：

集群总根底数据大小的影响：

表构造影响：

扩展性测试详情

不停服增减节点：

不停服减少列：

不停服加列测试过程曲线图（22秒后所有的带新列的insert语句全副胜利，红色曲线代表失败数降为0）

2、基于列存OLAP场景测试

2.1测试背景

指标监控零碎用于实时（定时）监控线上某实时业务数据，生成对于衰弱状态的相干指标，如果指标超出阈值，则触发报警性能。数据表约50列20亿行，查问sql10余种均为聚合类查问，检索列数不超过4列，查问条件为肯定工夫区间的范畴查问，之前是跑在一款行存的分布式数据库之上，这是一个典型的olap类场景，咱们采纳baikaldb的列存模式与线上进行了比照测试，测试对象均为线上实在数据，两款DB集群配置相当，测试查问性能的同时，均承当等同的写负载。

2.2测试后果：

从测试后果能够看出，在宽表少列与聚合查问的sql查问，应用baikaldb的列式存储，能够无效缩小磁盘IO，进步扫表及计算速度，进而进步查问性能，这类查问也是olap场景sql的常见写法。

3、性能与扩展性总结与思考

3.1性能剖析的几个角度

  • 资源瓶颈视角
  • 查问及事务大小倡议管制在10M以内，数据量过大会触发事务及RPC包大小限度；
  • 若需全量导出，用 /*{"full_export":true}*/ select * from tb where id > x limit 1000; 语法。
  • io.util满可导致rocksdb的L0层文件压缩不过去，呈现疾速的空间放大，进而导致磁盘疾速被写满。相干参数：max_background_jobs=24
  • rocksdb数据文件不倡议超过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=64M
  • export 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的集群总空间。
  1. Region元数据=0.2k， Meta20G内存共计可治理的 Region总数 = 20G/0.2k = 100M
  2. Region数据量 = 100M，Store 1T磁盘共可治理的 Region个数每store = 1T/100M = 10k
  3. 共计能够治理的数据量 = Region总数 * Region数据量 = 100M * 100M = 10P
  4. 共计能够治理的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 rstore

Demo

#统计每个广告平台的记录数量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性能开发中
  • 同步工具：Canal

3.6 软件成熟度：7分

3.7 技术前瞻性：9分

BaikalDB提供的PB级分布式扩大能力，动静变更Schema能力，分布式事务，异地多活，资源隔离，云原生K8s，HTAP能力均与公司将来的需要或布局匹配，因而给9分。

4、后记

至此BaikalDB在同程艺龙的利用实际系列文章就完结了，BaikalDB作为一款开源两岁的NewSQL数据库还十分年老，存在很大欠缺空间。同时作为后浪也借鉴很多前浪的设计思维，有肯定的后发优势。BaikalDB实现简洁，功能强大，社区业余敌对，无论是用来代码学习还是业务利用均有很大成长空间，欢送感兴趣的敌人一起参加。因为笔者程度无限，文中如有不妥之处，还望了解斧正。

招聘信息：

百度商业平台研发部次要负责百度商业产品的平台建设，包含广告投放、落地页托管、全域数据洞察等外围业务方向，致力于用平台化的技术服务让客户及生态搭档继续成长，成为客户最为依赖的商业服务平台。

无论你是后端，前端，还是算法，这里有若干职位在等你，欢送投递简历， 百度商业平台研发部期待你的退出！

简历投递邮箱：geektalk@baidu.com （投递备注【百度商业】）

举荐浏览：

｜面向大规模商业系统的数据库设计和实际

｜百度爱番番挪动端网页秒开实际

｜解密百TB数据分析如何跑进45秒

---------- END ----------

百度Geek说

百度官网技术公众号上线啦！

技术干货 · 行业资讯 · 线上沙龙 · 行业大会

招聘信息 · 内推信息 · 技术书籍 · 百度周边

欢送各位同学关注