分布式数据库在抖音春晚活动中的应用

作者｜马浩翔，火山引擎系统开发工程师

• 最上一层是应用，今日头条，抖音，西瓜视频等都是应用。
• 中间层是数据库中间件层。
• 底层是数据库层以及数据库下面的单机存储。

• Shared-Nothing 架构：最早使用 Shared-Nothing 架构的一些产品我们称之为 MPP 数据库。如果用户选择使用 MPP 架构的数据库，那他们可能更关心的是整个系统的吞吐量，对查询时延并不会特别敏感。MPP 数据库主要对接的是报表或者分析类的应用，可能经常会使用列式存储。但是，列存还是行存并不是绝对的，这只是对现有产品特点的总结。
• Shared-Storage 架构：目前一些主流的基于 Shared-Storage 架构的产品都是用来处理实时的在线事务。使用这种架构的数据库产品，用户可能会更关心在线事务的处理时延，可能是毫秒级甚至是微秒级别的需求。这种产品主要对接在线的事务应用。在这种场景下，可能常常会使用行式存储而非列式存储，因为它没有分析和报表类的需求。

• 最上面是代理层；
• 中间是计算层；
• 最底层是分布式存储层。

• 灵活性强：因为是基于 Shared-Storage 架构实现的计算存储分离的数据库产品，当需要扩缩容的时候，计算层和存储层互相耦合度非常低，可以独立进行扩缩容，非常灵活。
• 兼容性好：DB Instance可以100% 兼容 MySQL 和 PostgreSQL 内核。
• 高可用：在存储层的分布式存储池里实现了数据多副本，并且可以跨多个机房部署，以提高系统的可用性。
• 高性能：可以部署为集群模式，在集群模式下集群性能肯定是远超单机的。
• 成本低：由于计算节点和存储节点可以独立扩缩容，互相不影响，不需要扩计算的时候同时扩存储的盘，然后扩盘的时候也不需要同时扩 CPU，因此成本比较低。同时我们在存储层做了很多高压缩比的技术方案，后面会详细介绍。
• 超大容量：支持 TB 甚至 PB 级别的超大容量数据表。

• 接入层
• Query Engine
• Buffer Pool
• 日志子系统
• 事务子系统
• 锁子系统

• 先把 SQL 裸的字符串分切割成多个有效的 token。在这个例子里，可能是 SELECT 、T1 、 WHERE 等，这些都是有效的 token。
• 根据一定的语法规则把这些 token 组织成一棵抽象语法树，也就是 AST。组织成抽象语法树之后，要遍历这个树状结构。
• 根据这个树状结构和一些语法规则，可以把它组织成一个查询计划（目前我们还称之为逻辑计划）。然后对逻辑计划进行优化，提高它的查询性能。最后基于逻辑计划生成物理计划，物理计划描述的是我们怎么实际跟存储打交道，拉取哪些数据，需要做哪些具体的运算。
• 接下来执行引擎就出场了（目前比较主流的是 volcano 模型），执行引擎把已经生成好的物理计划执行一遍。执行过程中会与存储层交互获取数据，然后执行每个算子里面的计算逻辑，最终把计算后的结果批量返回给用户，用户就能得到查询的结果。

• 首先是对日志子系统做了非常深入的优化，甚至说是改造。我们废除了一些原生的刷盘机制，再结合新硬件做了高效的 append only 模型，并且丰富了 redo log 的类型和语义来支撑整个系统的运转。
• 实现了 Extent Data Cache。它是基于共享内存实现的。当数据库进程意外宕机时，重启后内存中肯定没有热数据，这个时候 Extent Data Cache 可以保存宕机前的热数据，避免冷启动的问题。
• DDL 优化。结合分布式存储层提供的能力，我们做了比较深入的 DDL 优化，提高了 DDL 的效率和性能。
• 算子下推。结合分布式存储层的能力，我们把一些简单的算子下推到存储层，利用存储节点空余的 CPU 去做计算，借此提高复杂查询的性能。
• 实现了一个 lock-free 的 ReadView。可化解多事务并发时候的 global lock 瓶颈，提高了多事务并发能力。
• 融合了 redo log 和 Binlog。目的是消除原生的 binlog 和 redolog XA 机制带来的一些问题，同时融合成单流之后也能提高写入性能。

• 首先高可用高可靠，多副本可以跨机房存储。
• 其次是能提供比较好的计算性能，因为我们可以在多个副本上进行并行计算。举个简单的例子，假设我们要从头到尾把所有 Page 都 scan一遍，最简单的做法可能是从零开始串行线性地 scan，但这样效率会很低。基于我们这个数据模型可以把这个 scan 同时下发到多个 Segment 上，因为本来 Page 就基于 Segment 打散了，所以我们可以同时在多个 Segment 上进行 scan。多个 Segment 又有可能被复制到不同的物理节点上，所以能充分地利用多个物理节点上的计算资源来进行计算操作，scan 就会很快。

• 数据在存储层是 tiering 存储，可以利用多种不同的存储介质，例如用 persistent memory 存最热的数据，用高性能的 SSD 存温的数据，HDD 存归档的冷数据。利用不同价格的不同介质来进行存储，可以从物理硬件的角度解决或缓和成本问题。
• 单机存储引擎跑在存储节点上，在单机存储引擎内部，我们实现了一个高效的压缩算法进行数据压缩，同时可保证不会损耗太多性能。这是从软件层面来缓和成本问题。
• 智能副本策略：我们的存储系统是多副本存储的，但在一些场景下可以不使用真正意义上完整的多副本，例如可以使用 EC、lazy replica 等策略来帮助缓和成本。

• Query Pattern 分析：一般情况下，一个成熟业务不会出现没建索引或者索引质量不好等低级错误，所以我们首先做的就是直接去分析 Query Pattern ，看看从哪里可以改善事务的性能。在分析过程中发现业务特点主要以 update 为主，事务的大小可能不太合适。所以我们做了一些事务拆分，降低 IO size，去除 global lock 以及 update 性能的优化，帮助事务跑得更快。
• 计算/存储性能摸底：先对虚拟机和物理机设置一个最小的规格，基于这个最小规格得到一个  benchmark 结果，在此基础上慢慢增加规格，看计算和存储性能是否能够相对线性地扩展。经过五六轮的摸底测试之后，最终能在满足业务 SLA 的情况下达到 QPS 要求。
• 性能压测：业务方要求 600W+ 的读 QPS 和 360W+ 的写 QPS，我们的性能压测要做到比这个值更高一点，才能保证活动当天不出事故。所以我们在摸底测试的基础上，又进行了多轮性能压测。在性能压测中发现了一些缓存策略不对或者效果不好的问题，就针对性地做了存储层的 Page IO 的缓存优化来提高读写性能。
• 故障演练：性能压测完之后，最关键的就是故障演练和容灾方案。在春晚当天，相比业务不可用，宁愿性能差。所以我们在故障演练方面做了非常多的预案和 test case，包括：
• 针对网络故障的 test case：例如用 iptables 模拟网络全丢包的场景，甚至还会直接随机 kill 一些存储节点来看它们宕机之后会不会引发连锁反应。
• 磁盘故障演练：注入一些单机磁盘故障，去 kill 一些存储节点、元数据节点和单机磁盘，通过这样的演练来模拟存储磁盘故障。

• 利用新硬件加速：新硬件包括不仅限于 RDMA 网络，Persistent Memory，还有可计算存储硬件等等。
• 多模计算引擎：除了关系型数据库之外，我们可能还有其他比较流行的一些数据模型或者数据库，例如文档数据库、图数据库等等。可以畅想一下在未来实现一个支持 all in one 的计算引擎，通过一条 SQL 或者其他查询语句直接执行跨多个计算引擎的事务。
• 持续对关系型数据库内核做深入的优化，甚至是改造或者推倒重来：
• 首先是现在的 B+ 树，都是单点的在一个单机存储引擎内部的 B+ 树，未来可能会尝试做分布式的 B+ 树以及相对应的一些分布式算法。
• 除了悲观事务，还可以探索一下乐观事务，验证能否将乐观事务和悲观事务进行混合使用。
• 现在在锁上面做的文章虽然比较少，但是它可做的东西其实很多，例如可以尝试更多样的锁调度算法，还可以引入谓词锁来丰富锁系统。
• 最后一点，AI 技术已经成为热门方向，但 AI 技术和数据库的结合还是相对冷门和小众的。我们可以畅想一下，在未来是否做到 AI for DB 或者 DB for AI，用 AI 进行自动调参和自动索引质量诊断，甚至可以把 AI 带到存储层，在存储层实现在线格式诊断，进行行列存格式转换。