关于后端:面向大规模商业系统的数据库设计和实践

导读：目前关系型数据库从上世纪 70 年代诞生以来失去了广泛应用，各种数字化的信息系统都能见到关系型数据库的身影。在实在的场景外面，业务系统对关系型数据库这种根底软件的要求非常简单，那就是高牢靠和高性能，同时心愿尽可能借助简单的 SQL 语义来简化业务层性能的实现。传统数据库产品例如 Oracle、SQLServer、MySQL、PostgreSQL 等都倒退趋于成熟，新一代的云原生数据库产品例如 Aurora、PolarDB、TiDB、OceanBase 等又开始引发更宽泛的关注，那么什么样的数据库产品能力更好地适应业务倒退？数据库这种比拟古老的软件产品的将来又是什么？本文次要从商业产品零碎的需要登程探讨数据库技术的实际和思考。

全文 11241 字，预计浏览工夫 18 分钟。

一、商业产品系统对数据存储设施需要的特点

百度商业产品矩阵次要包含成果广告（搜寻广告、信息流广告）和展现广告（品牌广告、开屏聚屏广告）两大类广告产品，以及基木鱼和观星盘等营销工具，商业产品零碎是连贯百度客户和广告检索系统的桥梁，帮忙客户表白营销诉求，达成营销指标。

商业产品零碎实质就是一个简单、宏大的广告信息管理系统，有 toB、toC 的多种场景，需要多样丰盛且迭代频繁。

这些业务需要聚焦到数据存储层面，次要有：

• 投放，交易场景的 事务型需要（OLTP，On-Line Transaction Processing）；
• 广告成果剖析场景的 剖析型需要（OLAP，Online analytical processing）
• 特定场景的 高 QPS 查问，例如账户构造，权限关系等；
• 字面场景的 正反 KV 查问，例如关键词字面和 id 互查等；
• 物料列表场景的 含糊查问；

为了应答商业场景下如此多样且迥异的数据存储需要，如果应用传统的存储技术，至多须要应用关系型数据库（例如 MySQL）、KV 存储（例如 Redis）、OLAP 数仓（例如 Palo）、全文检索（例如 ElasticSearch）以及自定义内存构造的存储等。

那么业务系统对数据存储设施的要求是什么呢？

• 首先是 稳固牢靠，不可用就意味着客户体验受损乃至间接的经济损失；
• 其次 数据尽可能统一，如果客户在不同环节看的数据有差别则会产生误解甚至引发谬误的广告投放操作；
• 再次尽可能 低成本 的应答数据规模持续增长，不须要事后购买大量硬件，前期扩大时也尽可能简略；
• 最初综合 读写性能好，尽量毫秒级响应，不影响客户的操作体验。

对于业务研发的同学来说，他们心愿用到的数据存储产品是什么样呢?

• 接口的应用形式繁多，学习和迁徙成本低，不同的数据存储也尽量采纳雷同的接口模式；
• 数据变更行为可了解，不呈现数据失落或者笼罩，不因并发引入异样数据；
• 扩展性高，可能适应数据规模和流量从 1 到 N 的变动，业务最好无感知；
• 高可用，内建高度容错能力，业务对数据库异样最好无感知；
• Schema 变更老本低廉；
• 对各种读写模式都能提供很好的性能。

总结起来最好什么都能够干，什么负载都能够扛，什么运维都不必管！

二、BaikalDB 的倒退历程

商业系统最外围的存储需要就是广告库，广告库存储了所有的广告物料信息，用于实现整个广告生命周期的治理，帮忙客户实现全副广告投放性能，获取转化。随同百度凤巢零碎的倒退，广告库的存储设施经验了两个重要的阶段：
1. 单库到分库分表的 MySQL 集群
2. MySQL 主存储集群 + 镜像辅助存储形成的异构复合存储集群

2.1 分库分表的 MySQL 集群

最早的凤巢广告库采纳单机 MySQL，部署在独立的盘柜（高性能磁盘阵列）上，这种架构受限于过后的硬件条件当初看来比拟古老，但这个跟当初风行的存储计算拆散的云原生架构从思维上是完全一致的，AWS 的 Aurora 或者阿里云的 PolarDB 就是把 MySQL、PostgreSQL 等单机数据库部署到一个由 EBS 磁盘或者 RDMA 高速网络连接的分布式文件系统上，实现 100% 的 SQL 兼容。

随着业务倒退，单机部署的 MySQL 无奈撑持数据量和读写量的收缩，分库分表就成了过后乃至当初最优的抉择，通过分库分表，MySQL 能够实现容量和性能的高扩展性。

从 2010 年开始，凤巢广告库就顺次经验了 1 拆 4、4 拆 8、8 拆 16、16 拆 32 的分库过程，从一套单机集群倒退成了有 33 分库（多拆出来的一个分库是为了解决个别大客户购买巨量关键词的场景），每分库 1 主 11 从的多分库集群，存储了数十 TB 的广告物料信息，读写 PV 达到每日数十亿。拆库的服务进展工夫从一天到 6 个小时，再到分钟级别。

2.2 异构复合存储集群

凤巢广告库的业务场景是读多写少，查问场景多样，多分库 MySQL 集群在满足一些查问场景较为吃力，比方在账户 - 打算 - 单元 - 关键词层级构造里，获取账户下关键词数，打算下的关键词数等波及全表扫的 count，关键词字面高 qps 查问，创意含糊搜寻，物料列表分筛排等，这些需要应用 MySQL 都难以满足。

为解决这个问题，咱们通过数据流，把 MySQL 的数据实时同步到一个镜像的内存存储，这些镜像存储采纳针对特定查问场景的内存构造，来满足业务性能。同时为了业务利用的开发便当，还专门开发了 SQL 代理层，依照肯定规定在 SQL 不扭转的状况路由到镜像索引，并转化为镜像存储所须要的申请参数，这样尽管咱们应用了不同的数据源，然而业务利用依然认为是一个 MySQL 协定的数据库在提供服务，且无须要关注应该查问哪种数据源，由此造成一个异构的复合存储状态。架构如下图所示：

这是一种常见的架构设计，在另一些业务场景中会把 OLTP 数据库的数据同步到 OLAP 数据仓库，隔离离线剖析场景，它的劣势在于多套同种数据不同存储引擎的零碎通过分而治之来解决简单的查问场景，并具备肯定业务隔离性。

依附 SQL 代理层可能无效晋升业务利用的应用体验，并且能够把应用层分库分表逻辑也下沉到这个代理层，拆库时业务利用也无需感知。对于业务利用来说，看到的是一个单机的 MySQL 零碎，不再须要思考任何性能和容量的问题。

然而这种架构也有显著的毛病：

运维更为简单：除了关注 MySQL 自身，还须要运维数据实时同步流，SQL 代理层，镜像索引这些零碎。

数据实时同步容易呈现故障或者提早：客户可能感知到显著的不统一，从镜像索引查问到的数据跟从 MySQL 查问有差别。为了升高这种差别的影响，SQL 代理层还须要设计肯定的降级能力（发现提早时尽可能切换到 MySQL 查问）。还须要有疾速修改镜像索引数据的设施。

资源冗余节约：镜像索引理论是数据的复制，MySQL 为扛住读性能和同步需要须要大量的从库。

2.3 2017 年的抉择

工夫来到 2017 年，凤巢广告库曾经有 33 分库，磁盘也用上了 NVME SSD，对于限定场景的读写性能能够满足业务需要，然而如果再进行一次拆库，无论是资源耗费还是运维老本都更为微小。

到这个阶段，咱们开始思考是否存在一种老本更低的解决方案。新的信息流广告业务也在疾速倒退，如果再造成一套凤巢广告相似的存储架构，实际成本会十分可观。尽管 4 年后的明天，凤巢广告库依附硬件降级，包含 CPU 和内存降级、NVME SSD 降级到单盘 3T，仍然维持在 33 分库的部署架构，但性能瓶颈曾经开始突显，如果广告物料持续高速增长，预计 2022 年底就须要进行新的拆库。

过后广告零碎的业界标杆 Google AdWords 的外围存储是 F1/Spanner，采纳寰球部署能够跨远距离的数据中心多活，装备原子钟用于实现分布式强统一事务，具备极高的可用性和主动增容的扩展性。参考 Google 存储系统的设计理念，广告存储系统设计也有可见的两种路线：

2.3.1 基于 MySQL 深度定制

MySQL 是一种单机的架构，代码规模达到百万行级别，掌控和批改的难度都特地高。如果要把 MySQL 从外部革新成一种相似 F1/Spanner 能力的零碎根本不大可能。

这时个别有两种解决思路，都是从内部来寻求冲破：

相似 Aurora 和 PolarDB，在文件系统上进行冲破，应用 EBS 或者构建一种 RDMA 高速连贯的分布式文件系统，这并不是研发新的数据库系统。然而为获取更好的性能，仍然须要深刻 MySQL 的存储引擎和主从同步机制进行一些定制和深度优化。即便如此，总容量和性能也不能有限扩大，例如 Aurora 最高可达 128TB，性能是 MySQL 的 5 倍，PolarDB 最高可达 100TB，性能是 MySQL 的 6 倍。

相似凤巢广告存储的设计思路，通过数据同步并借助扩大的镜像索引晋升查问性能，但冗余老本高，数据一致性差。

2.3.2 应用满足分布式 + 云原生 + 多样化索引架构 + 强统一等条件的新数据库系统

2017 年的时候，无论是 Google 的 F1/Spanner 还是 OceanBase 都是闭源零碎，跟外部设施耦合很大。开源零碎次要有两个流派，一类是反对 SQL 的 OLAP 零碎，例如百度的 Palo（现开源名为 Doris）、Impala（无存储引擎）、ClickHouse 等，一类是参考 F1/Spanner 思维的 CockroachDB 和 TiDB。OLAP 零碎必定不太满足咱们 TP（在线事务）场景的主需要，过后 CockroachDB 和 TiDB 也处于起步阶段，生产场景的应用根本没有。

这时放眼望去，理论并没有特地成熟的解决方案，基于 MySQL 的计划也走到了一个瓶颈，那么咱们是否自研一个新的分布式数据库系统？过后的决策依据是看团队是否具备能力从零研发出一个高可用、高性能、低成本的 OLTP 为主兼顾 OLAP 的数据库（也就是 HTAP,Hybrid Transaction and Analytical Process, 混合事务和剖析解决）。

团队的条件：已有的存储方向团队（4 人）是 C ++ 技术栈，研发过 SQL 代理层和定制化存储，相熟 MySQL 协定，有实战的工程教训。

技术的条件：

1、分布式系统须要无效的通信框架，百度的 brpc 框架过后曾经十分成熟，是工业级的 RPC 实现，有超大规模的利用。

2、保障数据一致性过后支流的计划就是 Paxos 和 Raft，百度 braft 框架是基于 brpc 的 Raft 协定实现，倒退也很迅速，有外部反对。

3、单机存储节点须要一个牢靠的 KV 存储，Facebook&Google 联结出品的 RocksDB 是基于 LSM-Tree 的高性能 KV 引擎，CockroachDB 和 TiDB 都抉择了 RocksDB。

起初通过 8 个月的设计研发，咱们的 1.0 版本数据库就实现上线，后果也证实了咱们的决策是可行的。

2.4 面向商业产品零碎的新一代存储系统 BaikalDB

BaikalDB 是面向商业产品零碎的需要而设计的分布式数据库系统，外围的指标有三个：

1、灵便的云上部署模式：面向容器化环境设计，可能与业务利用混部，灵便迁徙，容量和性能反对线性扩大，老本低廉，不须要非凡硬件。

2、一站式存储计算能力：面向业务简单需要具备综合的适应性，次要满足 OLTP 需要，兼顾 OLAP 需要、全文索引需要、高性能 KV 需要等。

3、兼容 MySQL 协定：易于业务应用，学习成本低。

BaikalDB 命名来自于 Lake Baikal（世界上容量最大的淡水湖 - 贝加尔湖），贝加尔湖是世界上容量最大的淡水湖，相当于北美洲五大湖水量的总和，超过整个波罗的海水量，咸水储量占寰球 20% 以上。西伯利亚总共有 336 条河流注入贝加尔湖。冬天的贝加尔湖畔，淡蓝色的冰柱犹如分布式数据库一列列的数据稀稀拉拉然而有颠三倒四，令人惊艳。

BaikalDB 是一个兼容 MySQL 协定的分布式可扩大存储系统，反对 PB 级结构化数据的随机实时读写，整体零碎架构如下：

BaikalDB 基于 RocksDB 实现单机存储，基于 Multi Raft 协定（braft 库）保障正本数据一致性，基于 brpc 实现节点通信交互，其中

• BaikalStore 负责数据存储，用 Region 组织，三个 Store 的三个 Region 造成一个 Raft group 实现三正本，多实例部署。Store 实例宕机能够主动迁徙 Region 数据。
• BaikalMeta 负责元信息管理，包含分区、容量、权限、平衡等，Raft 保障的 3 正本部署，Meta 宕机只影响数据无奈扩容迁徙，不影响数据读写。
• Baikaldb 负责前端 SQL 解析，查问打算生成执行，无状态全同构多实例部署，宕机实例数不超过 QPS 承载极限即可。

BaikalDB 的外围个性有：

• 全自主化的容量治理：能够主动扩容和主动数据平衡，利用无感知，很容易实现云化，目前运行在 Opera PaaS 平台之上
• 高可用，无单点：反对主动故障复原和迁徙
• 面向查问优化：反对各种二级索引，包含全文索引，反对多表 join，反对常见的 OLAP 需要
• 兼容 MySQL 协定，反对分布式事务：对利用方提供 SQL 界面，反对高性能的 Schema 和索引变更
• 反对多租户：meta 信息共享，数据存储齐全隔离

在零碎研发过程中，BaikalDB 以业务需要为导向布局疾速迭代，在业务应用中深度打磨优化，随业务成长而成长，要害性能的工夫节点如下：

从 2018 年上线以来，BaikalDB 已部署 1.5K+ 数据表，数据规模达到 600+TB，存储节点达到 1.7K+。

三、BaikalDB 要害设计的思考和实际

分布式数据存储系统个别有三种架构模式，别离是 Shared Everthing、Shared Disk 和 Shared Nothing。

1、Shared Everthing：个别是针对单个主机，齐全通明共享 CPU、内存和磁盘，传统 RDMS 产品都是这种架构。

2、Shared Disk：各个处理单元应用本人的公有 CPU 和内存，但共享磁盘零碎，这能够实现存储和计算拆散，典型的代表是 Oracle Rac(应用 SAN 共享数据)、Aurora(应用 EBS)、PolarDB(应用 RDMA)。

3、Shared Nothing：各个处理单元都有本人公有的 CPU、内存和磁盘等，不存在资源共享，相似于 MPP（大规模并行处理）模式，各处理单元之间能够相互通信，并行处理和扩大能力更好。典型代表是 hadoop，各 node 互相独立，别离解决本人的数据，解决后可能向下层汇总或在节点间流转。

Shared Disk 是很多云厂商提倡的架构，云厂商心愿在云上提供一个齐全兼容传统 RDMS 零碎的云产品，心愿宽广的数据库使用者根本没有迁徙老本，然而各家云厂商的实现有比拟多差别，次要比拼性能、容量和可靠性，这些也是各家云厂商吸引客户的卖点。然而该架构的 Scale Out（横向扩容）能力比拟无限，所以云厂商的存储广告宣传语个别是百 TB 级别的数据容量。

Shared Nothing 是一种分布式的依附多节点来工作的架构，大部分 NoSQL 都是这样的架构，Sharding MySQL 集群也是一种 Shared Nothing 的架构，每个分片独立工作。这类架构最大的局限是难以同时保障一致性和可用性，也就是受限于驰名的 CAP 实践。对于 NoSQL 零碎大部分不反对事务，所以优先保障可用性。但对于 OLTP 场景，数据一致性十分重要，事务是不可或缺的环节。

因为 BaikalDB 的指标是一个面向业务需要的具备交融型能力的分布式数据存储，并且大规模数据场景更看重 Scale Out 能力（仅仅 100TB 容量远远不够），所以采纳的是 Shared Nothing 的架构。

对于分布式数据系统而言，设计最须要关注存储、计算、调度三个方面的内容。

3.1 存储层的设计

存储层的设计次要是关注用什么样的数据结构来形容数据寄存。对于分布式数据系统，还须要额定关注怎么利用多节点来协同存储同一份数据。

对于大规模数据场景的存储优先须要思考应用磁盘，而不是老本更高数据易失的内存。面向磁盘的存储引擎，RocksDB 是比较突出的代表，其外围模型是 Key-Value 构造。如果应用 RocksDB 就须要思考如何数据表的构造映射到 Key-Value 构造。

为了把数据扩散到多台机器，BaikalDB 还引入了 Region 的概念，用于形容最小的数据管理单元，每个数据表是有若干个 Region 形成，散布到多台机器上。这样的架构就须要思考如何对数据进行拆分，个别有 Hash（依据 Key 的 Hash 值抉择对应的机器）和 Range（某一段间断的 Key 都保留在一个机器上）两种。

Hash 的问题在于如果 Region 增大到须要决裂时如何动静批改 Hash 规定，而 Hash 规定的改变会波及大量数据的从新散布，每个 Region 的大小都很难平衡，即便引入一致性 Hash 也只能无限改善该问题。Range 尽管容易实现数据的决裂拆分，然而容易有热点，不过相对来说好克服。所以 BaikalDB 采纳了 Range 拆分。

Key-Value 不等同于数据库的 Table，须要把数据表的主键索引（也叫聚簇索引，存储主键值和全副数据），和面向查问优化的二级索引（也叫非主键索引、非聚簇索引，存储索引值和主键值）以及全文索引都要映射到 Key-Value 模型外面。

• 主键索引，为辨别 Region 和索引类型，除了蕴含主键值还须要蕴含 region\_id 和 index\_id，因为 region\_id 能够在同一集群全局惟一调配，也不须要 table\_id，同时思考到多字段形成的联结主键须要按联结主键的大小程序寄存，还须要引入对 Key 的 Memcomparable 编码来晋升 Scan 性能；整行的数据能够用 protobuf 进行编码后再存储到 Value 里，这样可有肯定压缩也能更不便的实现加列操作。

• 二级索引，次要须要思考采纳本地（部分）二级索引（Local Secondary Index）还是全局二级索引（Global Secondary Index）。

• 本地二级索引：只索引本机 Region 的数据，长处是索引和数据都在同一个节点，回表速度快，不须要实现分布式事务。然而查问总须要附带上主键条件，否则就只能播送给全副分区。
• 全局二级索引：可能索引整个表的全副分区数据，长处是没有主键条件时也不须要播送，但因为全局二级索引是一张独立的表，跟所有主键数据没法在一个存储节点上，须要引入分布式事务能力工作。

二级索引在 Key-Value 模型外面，不论本地的还是全局的，Key 都是由 region\_id、index\_id、索引键值、主键值（如果是二级惟一索引就无需蕴含），Value 是主键值，能够看出应用二级索引拿到整行数据还须要从主键索引再获取一次（也就是回表操作），如果相干数据都在索引键值里就不须要回表。

BaikalDB 在晚期没有引入分布式事务（切实太简单），所以先实现了本地二级索引，在实现分布式事务后再实现了全局二级索引。对于业务利用而言，能够按应用场景优先选择本地二级索引。

• 全文索引，次要波及索引构建及检索：

构建：将正排字段切词为一或多个 term。构建 term 的有序倒排拉链，并依照格局进行存储。

检索：依据检索词，对多个倒排拉链进行布尔查问。

在 Key-Value 模型外面，Key 为 region\_id、index\_id、分词后的 term，Value 为排序好的主键键值。

所以在存储层面，包含以上次要外围逻辑构造，以及列存、HLL、TDdigest 等都是 KV 的物理构造。对于更多的索引细节设计请参考 BaikalDB 的索引实现（https://my.oschina.net/Baikal…）。

数据基于 Range 形式依照主键切分成多个分片（Region）后，同时为晋升在分布式场景下的整体可用性，须要多个正本（Replica）来存储同样的 Region，这时就须要思考多个正本和多个分片的数据一致性：

• 多正本（Replica）的数据一致性：多个正本须要数据牢靠地复制，在呈现故障时，能产生新的正本并且不会产生数据错乱，这次要依附 Raft 一致性协定来实现。Raft 提供几个重要的性能：Leader 选举、成员变更、日志复制，每个数据变更都会落地为一条 Raft 日志，通过 Raft 的日志复制性能，将数据安全可靠地同步到正本 Group 的少数节点中。在强一致性要求的状况下，读写都产生在 Leader 节点。

• 多分片（Region）的数据一致性：波及多个 Region 的操作须要保障同时胜利或者失败，防止一个批改中局部 Region 失败导致的不统一问题，这次要依附联合 RocksDB 单机事务的两阶段提交（Two-phase Commit，即 2PC）实现乐观事务，同时联合 Percolator 的思维，采纳 Primary Region 来充当事务协调者的角色，防止协调者的单点。分布式事务的细节比较复杂，在很多数据库研发公司中都是一个专门的团队在投入，更多细节能够参考 BaikalDB 的分布式事务实现（https://my.oschina.net/Baikal…）。

3.2 计算层的设计

计算层须要关注如何把 SQL 解析成具体的查问打算，或者叫分布式的计算过程，还须要思考如何基于代价进行优化。

BaikalDB 的 SQL 层面是一种分布式的分层设计，整体架构如下：

目前 BaikalDB 还不是齐全的 MPP 架构，跟 OLAP 零碎的设计有较大差别，数据最初的计算汇总只产生在一个 Baikaldb 节点上，同时各种 Filter 条件会尽量下推到 BaikalStore 模块，缩小最初须要汇总的数据，思考到 OLTP 场景为主的状况下返回数据规模无限，所以也足够应用。因而 BaikalDB 存储节点具备肯定的计算能力，能够分布式执行，升高传输压力，所以也不是严格的存储和计算拆散。

在 SQL 引擎的实现层面，咱们采纳了经典的火山模型，所有皆算子，包含 Baikaldb 和 BaikalStore 的交互也是算子，每个算子提供 open、next、close 操作，算子之间能够灵便拼接，具备很好的扩展性。
在查问条件执行过程中，如果数据表有多种索引，为了让查问更优，还须要具备

主动抉择最合适索引的能力，这种查问优化器的支流设计有两种：

基于规定的优化器（RBO，Rule-Based Optimization）：该形式依照硬编码在数据库中的一系列规定来决定 SQL 的执行打算。理论过程中，数据的量级差别会影响雷同 SQL 的性能，这也是 RBO 的缺点所在，规定是不变的，数据是变动的，最初规定决定的不肯定最优。

基于代价的优化器（CBO，Cost-Based Optimization）：该方向通过依据优化规定会生成多个执行打算，而后 CBO 会通过依据统计信息 (Statistics) 和代价模型 (Cost Model) 计算各种执行打算的代价，即 COST，从中选用 COST 最低的执行打算作为理论执行打算。统计信息的精确与否会影响 CBO 做出最优的抉择。

查问优化器也是非常复杂的话题，当初还有基于 AI 技术的查问优化器，也是学术研究的热门，在很多数据库研发公司，这个别也是一个专门的大方向。BaikalDB 采纳了 RBO 和 CBO 联合的形式做查问优化，对于 CBO 的细节能够参考 BaikalDB 的代价模型实现（https://my.oschina.net/Baikal…）。

3.3 调度层的设计

分布式数据系统波及到多个工作节点，每个节点可能有不必的硬件环境和软件负载，为尽可能施展集群的性能，必定心愿每个工作节点存储的数据大小基本一致，数据处理的负载基本一致，但同时还须要思考故障节点的避让和复原，放弃集群的性能安稳。

调度零碎根本都会有一个 Master 角色来综合评估集群所有节点的信息做出调度决策，BaikalDB 的 Master 角色是 BaikalMeta 模块，BaikalStore 定时通过心跳包收集信息上报给 BaikalMeta，BaikalMeta 取得整个集群的具体数据后依据这些信息以及调度策略来生成决策，这些决策会通过心跳包的回复发送给 BaikalStore，BaikalStore 会依据理论状况来灵便执行，这里并不需要保障操作的执行胜利，后续还会通过心跳告知 BaikalMeta 执行状况。

BaikalMeta 每次决策只须要依据本轮收集的所有节点的心跳包的后果来解决，不须要依赖之前的心跳包信息，这样决策逻辑就比拟容易实现。如果 BaikalMeta 故障，BaikalStore 的心跳包没有回应，就会进行全副的调度操作，整个集群处于不调整的状态，同时 Baikaldb 模块会缓存 BaikalMeta 返回的集群信息，能精确晓得每个数据表的全副 Region 信息，并能对失败的节点做剔除或者重试，这样即便 BaikalMeta 故障，也不会影响读写。

另一方面 BaikalMeta 的决策并不需要很高的时效性，所有 BaikalStore 能够距离较长时间发送心跳，无效管制对 BaikalMeta 申请压力，这样一组 BaikalMeta 就能够治理成千上万的 BaikalStore 节点。

在存储节点的调度中次要须要关注 Leader 的平衡和 Peer 的平衡：

Leader 平衡：每个 BaikalStore 节点的 Region Leader 数量应尽量统一，Leader 是次要的读写压力承担者，平衡能够让每个 BaikalStore 节点的 CPU 内存负载靠近。在 BaikalStore 负载较高时（通常容器化环境下会显著变高），如果同机器的其余容器耗费大量的 CPU 和内存，同一个 BaikalStore 的其余 Leader 也可能耗费大量资源，就须要把它下面的 Leader 切换到其余节点，防止热点导致的解决超时。

Peer 平衡：指每个 Raft Group 的正本尽量扩散到每个 BaikalStore 节点，使得每个 BaikalStore 节点的正本数量尽可能统一，每个数据表的所有 Region 大小根本是统一的，因而使得每个 BaikalStore 的存储容量也比拟靠近，防止数据歪斜，这样可能反复利用集群的磁盘资源。此外还心愿每个正本在不同的机器，甚至不同的网段上，防止机器故障和网络故障导致一个 Region 的大部分正本不可用进而导致 Leader 无奈选出不能读写。在 Peer 有节点故障或者被动迁徙时，还须要创立新的 Peer 同步数据达成可用，并删除不可用 Peer，这样来保障 Peer 数量稳固。

Region 作为一个调度单元，它的可分裂性也是调度机制的一个根底，BaikalDB 会在 Region 大小超过设定阈值时，采纳基准 + 增量的形式来拆分 Range 产生新的 Region 及其正本，通过汇报信息进行调度平衡，这样使得在数据增长的时候能够自动化拆分。调度也是一个比较复杂的话题，通过引入很多调度策略可能晋升资源的利用率、容灾、防止热点，保障性能，这块工作也是 BaikalDB 迭代的重点方向。

四、总结

本文从大规模商业系统的需要登程，总结了商业场景对数据存储设施的冀望。通过回顾整个凤巢广告库依赖的数据库系统的倒退过程，来展现了商业平台研发部自研更低成本、更为牢靠、更为弱小的数据存储系统 -BaikalDB 的迭代历程。

通过 4 年的工作，BaikalDB 曾经整合了商业产品零碎历史存在的全副存储系统，实现了大一统。在联合业务需要研发过程中，BaikalDB 也尽可能依附很少的人力投入，疾速构建外围功能集，依据业务需要的紧迫水平逐步迭代，不仅仅满足了广告场景的需要，还满足新的包含落地页和电商的新商业场景的需要，而且仍在不停的丰盛性能、优化性能和降低成本，打磨整个零碎。

最初针对如何研发一个数据库，从存储、计算、调度三个角度总结了 BaikalDB 的一些要害设计思路。数据库和操作系统、编译器并称三大系统软件，能够说是整个计算机软件的基础设施，数据库技术同样是博大精深，本文只是以业务视角管中窥豹，不免有疏漏，心愿大家探讨斧正。

最初心愿大家多多关注 BaikalDB 的开源我的项目 github.com/baidu/BaikalDB。

招聘信息：

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

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

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

举荐浏览：

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

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

|从 Web 图标演进历史看最佳实际 | 文末送书

———- END ———-

百度 Geek 说

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

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

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

欢送各位同学关注