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

[导读]导读：目前关系型数据库从上世纪70年代诞生以来得到了广泛应用，各种数字化的信息系统都能见到关系型数据库的身影。在真实的场景里面，业务系统对关系型数据库这种基础软件的要求非常简单，那就是高可靠和高性能，同时希望尽可能借助复杂的SQL语义来简化业务层功能的实现。传统数据库产品例如Or...

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