导读：目前关系型数据库从上世纪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说

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

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

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

欢送各位同学关注