关于后端:百度BaikalDB在同程艺龙的成功应用实践剖析

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

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

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

注 1：ShardingSphere 基于 MySQL MGR 的 Paxos 复制协定尚未公布。
注 2：TiDB 3.0 起已同时反对乐观事务与乐观事务。
注 3：因为笔者精力所限，尚有很多 NewSQL 未参加比照：Amazon Aurora，Aliyun PolarDB，AnalyticDB，Apple FoundationDB，CockroachDB, 华为 GaussDB，Yandex ClickHouse 等。

纯自研：能力无限，投入无限
纯开源：无奈及时满足定制化需要
云服务：平安与老本思考，短期内外围业务自建 IDC，k8s 化
半自研：咱们的抉择，不反复造轮子，主体性能交由社区实现，集中无限力量满足公司需要，可供选择的 NewSQL 有：TiDB，BaikalDB，CockRoachDB 等。

从以上几款开源 DB 中，最终抉择 BaikalDB 的起因有：

背景类似：BaikalDB 来源于百度凤巢广告业务团队，因为广告业务的增长走过了从单机到分库分表到分布式的全过程，而咱们面临相似的问题。
经受考验：曾经有百度广告平台多个业务理论应用教训，千级别集群节点，PB 级数据规模，咱们跟进应用，危险可控。
技术栈匹配：BaikalDB（c++ 实现，10 万行代码精炼），依赖少而精（brpc，braft，rocksdb），社区敌对，部署简略，技术栈匹配。
个性比较完善：根本满足咱们需要，咱们能够专一于满足公司需要。

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 协定

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

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

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

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

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

如下图：

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

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

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

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

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

数据建模：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 将被剔除。

咱们的 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 代表。则相干的配置过程如下：

初始化 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

设置每个 baikalstore 的物理机房信息

#IDC1 store 的机房信息配置 #vim store/conf/gflag-default_physical_room=bj1

设置每个 baikaldb 的物理机房信息

#IDC1 db 的机房信息配置 #vim db/conf/gflag-default_physical_room=bj1

创立表时依据须要指定正本策略与存储类型

-- 业务 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 在性能与扩展性方面的数据。

如果把 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 失效对集群 无影响。

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

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

测试部署

最佳容量（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
最佳容量断定办法

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

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

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

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

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

资源瓶颈视角
查问及事务大小倡议管制在 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：

联结主键 vs 自增主键
BaikalDB 是按主键进行分片的，主键的抉择影响了数据的物理散布，好的做法是把查问条件落在尽量少的分片上，查问时基于前缀匹配，个别倡议按范畴从左到右建设联结主键，例如：class 表主键可设置为 schoolid，collegeid，classid # 学校，学院，班级;
BaikalDB 实现自增主键次要是为了与 MySQL 兼容，因为全局自增是通过 meta 单 raft group 实现，会存在 rpc 开销及扩展性问题；另外全局自增主键也容易导致数据批量插入时申请集中于最初一个 Region 节点，容易呈现瓶颈。
全局索引 vs 部分索引
全局索引与主表不在一起，有本人的分片规定，益处是有路由发现性能，害处是多了与全局索引的 RPC 开销，部分索引与主表一起，须要通过主键确定分片，否则须要播送，益处是 RPC 开销。
小表倡议用部分索引；
大表（1 亿以上），查问条件带主键前缀，用部分索引，否则用全局索引。
行存 vs 列存
宽表少列（查问列 / 总列数小于 20%），聚合查问的 olap 申请用列存
其余状况用行存

Balance：BaikalDB 会周期性的进行 Leader 平衡与 Peer 平衡，负载平衡过程中若数据迁徙量较大，可能是影响性能，个别产生在：
增删节点时
批量导入数据时
机器故障时
SQL Optimizer：目前次要基于 RBO，实现了局部 CBO，若性能与执行打算无关，能够应用 explain，及 index hint 性能调优。

稳定性
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 = 100M
Region 数据量 = 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）

本文的性能与扩展性剖析数据均来源于理论我的项目，而非 TPCC，TPCH 标准化测试，但测试项目具备肯定的代表性。
BaikalDB 测试数据基于 V1.0.1 版，最新公布的 V1.1.2 版又有了较多优化：
优化 seek 性能，实测 range scan 速度进步 1 倍；
rocksdb 降级 6.8.1，应用 Partitioned Index Filters，进一步提高了内存应用效率；
减少利用统计信息计算代价抉择索引性能（局部）；
事务多语句 Raft 复制拆分执行，进步了 Follower 的并发度。

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

1、首先必须（Must to）业务场景匹配精准（1 一致性）和运行安稳（2 高可用）；

2、其次最好（had better）是数据多（3 扩展性）与跑的快（4 高性能）；

3、最初应该是（should）应用敌对（5 高兼容性）与老本节俭（6 低成本）。

简称：稳准多快好省。

作为系列文章的最初一篇，是对于老本的思考，如果说 强统一与高可用 是用户关怀的在性能上是否满足需要，扩展性与高性能 是老板关怀的在规格上是否值得投入，那么 兼容性与老本 则是我的项目实施者应该关怀的问题，因为它关系到我的项目推动难度。

如果你认可 NewSQL 的发展趋势，也发现了公司的理论业务场景需要，本文将会探讨在我的项目施行中须要克服的问题，并倡议用老本的角度进行评估，这样有助于对我的项目的工作量进行计算。例如如果调研发现公司的潜在指标用户均跑在 mysql 数据库上，那么是否兼容 mysql 协定间接决定了用户的志愿，用户的学习老本，业务代码的革新老本，生态的配套老本，如果潜在用户超过 10 个以上则老本将会放大 10 倍；如果大部分潜在业务应用的是 PostgreSQL，那么最好在选型时抉择兼容 pg 的 NewSQL。这也是本文将 兼容性 归类到 低成本 一并探讨的起因。

广义的老本：指数据库软件的开发，受权，运维及硬件老本，特点是可量化，例如：1、开发投入：24 人月

2、License 受权：10 万 / 年

3、运维投入：DBA 2 人

4、硬件老本：服务器 10 台

狭义的老本：泛指在组织施行数据库利用工程实际过程中，所产生费用总和，特点是与项目管理与施行无关，包含：

1、学习开发成本

2、测试验证老本

3、业务迁徙老本

4、用户习惯

5、运维配套工具

6、软件成熟度

7、技术前瞻性

广义的老本能够了解为这件事值不值得做，狭义的老本能够了解为把事件做成须要做的工作，截止到本文发表为止，BaikalDB 已在公司 10 余家业务上进行了落地利用，这些利用理论产生的老本与收益如何评估（广义）？我的项目落地过程中须要落实哪些工作(狭义）？上面将就这两个问题展开讨论。

因为 BaikalDB 是开源的，开发成本能够疏忽，部署简略，其广义老本次要集中在硬件老本上。联合公司的双核心建设与 Kubernetes 云原生平台策略，咱们给出了 BaikalDB 两地四核心三正本行列混存的计划，实践上无望使硬件老本升高 100 倍，计划如下图：

1、注 1：图中省去了 meta 节点部署

2、注 2：每个 IDC 会理论部署了多个 store 与 db 节点。

3、注 3：行列混存的个性还在开发中

上图采纳了齐全对称的双核心部署计划，每个数据中心又存在 2 个对等 IDC 机房，基于 BaikalDB 的逻辑机房与物理机房概念，能够实现以上部署，并提供城市级别的容灾能力，通过 Raft Group 层面的行列混存技术实现仅需 3 正本即可提供 HTAP 的能力，配置细节曾经在第一篇文章 HTAP 部署有所形容，本文在之前根底上减少了行列混存（性能尚未实现）的形式，进一步合并了利用场景，缩小正本个数，从而达到节约老本的目标。以上计划具体老本节约次要体现在三个方面：

为了满足不同的利用场景，通过同步工具，数据会被散发到 ETL，ES，HBASE，kafka，TiDB 等不同数据组件中去，外围业务的存储资源存在 5 倍以上的放大。根据数据库应用现状状况，外围业务个别 1 套 OLTP 主库 + 数据同步平台 + 5 套 OLAP 数据库，采纳此计划后能同时满足以上全副场景，并且省去了异构数据源之间数据同步提早问题，因为异构数据源超过了 5 个，合并为 1 个后，预计收益增大 5 倍。

行存 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 倍 左右。

以 mysql 为例，因为缩扩容升降配艰难，为了应答多数产生的业务顶峰时段（例如双 11 一年只有一次）而不得不始终留够 Buffer，导致硬件资源的投入不能随着流量的变动而动态变化，弹性有余，资源利用率广泛较低约 8% 的程度。公司也意识到相干问题，在踊跃构建基于 kubernetes 云原生平台（见下图），具体文章参见同程艺龙云原生 K8s 落地实际[4]。

BaikalDB 的 share –nothing 云原生个性能完满的 k8s 的调度能力进行联合，预计能够把资源利用率晋升到 40%，因而弹性收益为 5 倍。之所以没有晋升到 80% 以上是为了满足双核心容灾互备的须要，以应答城市级故障带来的单核心双倍压力。

综上所述，总收益 = HTAP 收益 * 单位资源能效收益 * 资源利用率收益 = 5 * 4 * 5 = 100 倍

在广义老本评估值得做的状况下，须要从项目管理或我的项目施行的角度思考如何把我的项目顺利推动，因为每家公司每个我的项目的理论状况均不一样，我的项目的评估很难对立量化，但咱们在进行我的项目施行时必须要慎重考虑这些因素，并且任何一个环节不达标均可能导致我的项目的失败，在这里把我的项目推动中要实现的工作量称为狭义的老本，以咱们实践经验进行总结评分，满分为 10 分，分值越高越好，评估不同于以往的性能测试，具备很强的主观性，仅供参考。

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 分。

BaikalDB 的测试验证工作量与其它 DB 差不多，中规中矩给 7 分。

业务的迁徙老本次要包含数据迁徙与 SQL 改写两个局部，因为 BaikalDB 兼容 MySQL 协定，公司已研发了基于 MySQL 生态的数据同步平台，数据迁徙老本不大。应用 MySQL 开发的业务代码，大部分状况不须要改写 SQL，改写次要产生在 BaikalDB 尚未反对的 MySQL 语法例如（子查问，一些零碎函数上）和慢查问改写下面，业务迁徙老本给 8 分。

1、图像化工具：能应用 Navicat，IDEA 自带 MySQL UI，DataGrip 进行简略的表浏览，SQL 执行性能，不能进行简单治理操作；

2、公司已有零碎对接（例如工单，权限，一站式查问等）：尚未买通；

3、对新概念的承受过程（例如新的数据文件，部署形式，资源隔离，多租户等）。

备份工具：

热备：基于 SST 的备份复原

冷备：通过 SQL 语句逻辑备份。

/_{“full\_export”:true}_/ select * from tb where id > x limit 1000;

监控工具：Prometheus
运维脚本：script[5]
部署工具：Ansible
压测工具：sysbench
订阅工具：Binlog 性能开发中
同步工具：Canal

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

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

招聘信息：

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

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

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

举荐浏览：

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

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

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

———- END ———-

百度 Geek 说

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

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

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

欢送各位同学关注

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

1、BaikalDB 选型思考

1.1 业界纷纷布局 NewSQL

1.2 NewSQL 数据库核心技术比照

1.3 NewSQL 技术选型

门路抉择：

1.4 BaikalDB 简介

其中：

外围个性：

2、BaikalDB 线上迁徙过程

2.1 列存个性开发

2.2 配套运维工具

2.3 数据迁徙

2.4 业务测试

2.5 业务上线

2.6 运维与监控

2.7 注意事项

BaikalDB 尚在欠缺的性能：

应用 BaikalDB 须要留神的事项：

3、高可用与 HTAP 部署计划

长处：

待欠缺：

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

1.1 测试指标

1.2 测试范畴

1.3 测试环境

1.4 次要指标阐明

1.5 测试论断

1.6 性能测试详情

与 mysql 基准比照测试：

表构造字段个数影响：

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

表构造影响：

扩展性测试详情

不停服增减节点：

不停服减少列：

2、基于列存 OLAP 场景测试

2.1 测试背景

2.2 测试后果：

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

3.1 性能剖析的几个角度

3.1.1 用户视角

3.1.2 实现视角

3.1.3扩展性思考因素

4、后记

三、BaikalDB 低成本思考

1、老本的分类

2、广义的老本实践上可减低 100 倍

2.1 HTAP 带来的老本升高为 5 倍

2.2 单位资源效力带来的老本减低为 4 倍

2.3 云原生弹性能力带来的老本减低为 5 倍

3、实际上狭义的老本难以量化但不能有短板

3.1 学习开发成本：9 分

3.2 测试验证老本：7 分

3.3 业务迁徙老本：8 分

3.4 用户习惯：7 分

3.5 运维配套工具：7 分

3.6 软件成熟度：7 分

3.7 技术前瞻性：9 分

4、后记