打造一款强大成熟的数据库有多难

作者: 康凯森

日期: 2022-11-17

分类: OLAP

从 2015 年开始，我在美团先后维护和研发过 Apache HBase, Apache Kylin, Apache Druid 和 Apache Doris, 对大数据系统和 OLAP 数据库有了深入理解，2020 年开始，我加入了 StarRocks，我们先后打造了业界领先的向量化执行器，CBO 优化器，Pipeline 并行引擎，支持高效 Update 的存储引擎和极速的数据湖分析，支持存储分离的 Cloud Native 版本也即将面世，一路走来，随着我们攻克一个又一个技术难题，解决一个又一个用户需求和难题，服务着越来越多的客户，我对如何打造一个强大且成熟的数据库有了更深的理解，在前一篇文章 如何快速打造一个高性能数据库原型 中，我们看到利用开源系统打造一个数据库原型是如此的简单，在这篇文章中，我会和大家介绍打造一个强大且成熟的数据库都有哪些难点，之后会再用几篇文章介绍我们如何解决这些难点。

本质矛盾

作为一家创业公司或者一家大公司的数据库部门，打造一款强大且成熟的数据库都会有下面两个本质矛盾：

1 有限人力和无限工作之间的矛盾

各种各样的用户需求，无止境的性能优化，永远也修不完的 Bug，一个又一个 Killer Feature 的打造，时刻不停的代码重构，增加不完的测试 Case，不间断的技术调研和系统设计，这些工作都需要大量人力，但无论哪家公司，人力总是不足的，优秀的数据库人才更是稀缺。

2 飞速增长与成熟稳定的矛盾

如果数据库的代码不大变，面对的应用场景不大变，我们让一个数据库变稳定会容易很多，但是如果一个数据库的代码在飞速变化和增长，应对的应用场景不断丰富和变化，让一个数据库稳定下来就会很难。

1 定位和独特性之难

一款数据库想要在产品和商业上取得成功，想在很多竞品中脱颖而出，就必须有清晰的定位和自己的独特性，一款数据库的独特性就是自己的卖点，比如目前 StarRocks 的卖点就是极速统一。 一旦定位和独特点定义清楚，也便意味着全公司产研资源的重心和方向的倾斜。 而一款数据库想要让自己的独特性成为 Killer Feature，就必须超越所有竞品，这就意味着，这家数据库公司必须有足够强大的创新能力，足够强大的工程能力，才能做到其他数据库公司一定时间内无法做到的。

2 架构之难

一个数据库的架构决定了一个数据库未来的上限，决定了一个数据库未来支持更多用户需求的难易程度，如果架构设计有误，后面的很多功能和优化成本就会很高，甚至无法实现。不过在当下，云时代数据库的架构逐渐趋同，想要有足够的独特性和明显的优势还是比较困难。

3 功能之难

Killer Feature 的创新性和独特性

一般数据库在产品功能上肯定会推出几个 Killer Feature， 作为自己产品的卖点，但是想做作为 Killer Feature，就必须比竞品好很多，这时候就必然需要 Killer Feature 拥有一定的创新性和独特性。

持续不断的用户需求

用户越来越多，用户的需求自然就会越多，有些用户的需求很小众和奇葩，但有时候为了拿下一个用户，我们却不得不做，而且有时候做了还会给系统带来额外的复杂性。

杂七杂八的认证

比如 CMMI 认证，通信认证，信创认证，国产服务器认证等等，这些认证里面的一些功能其实并不是你的数据库产品所必须的，做了不会增加什么产品竞争力，但是我们为了获取客户，我们还是必须投入大量的人力去通过这些认证。

用户迁移时的功能对齐

当一个新系统越来越好，要扩大市场规模，必然要去替换用户已有的旧数据库，但是替换过程中经常会遇到语法，函数，功能不对齐的场景，这时候，如果这个用户很重要，你就不得不去做一些和传统数据库功能对齐的事情。

系统越强大会越复杂

  • 越强大的优化可能跨模块越多：比如 StarRocks 的低基数优化和导入，查询，Delete，Update，Compaction，Schema Change， MVCC 等很多模块都有关系，所以这类功能的测试本身就会很复杂
  • 一个新的功能或者优化可能会打破旧的功能或者优化的假设：比如 Tablet 并行可能和 Local exchange 有冲突，比如 Query Cache 可能和 Shared Scan 有冲突

系统越成熟，新的功能和优化要求越高，大规模使用周期越长

  • 新系统的第一个版本往往会给用户建立一个 Baseline，之后的版本做的功能和优化就必须考虑所有用户的场景，在自己的用户场景下没有或者很少有 Bad Case
  • 用户使用一个系统稳定后，升级的动力会越来越弱，所以越靠后的版本得到用户大规模验证的周期也会更长

4 性能之难

CBO 优化器 Plan 的稳定性和正确性

  • 统计信息的变化会导致查询 Plan 发生剧变
  • 某些优化就是会导致部分查询变快， 部分查询变慢
  • 选择度估计和基数估计一般都假设了数据的均匀分布，但这和实际情况并不相符
  • 统计信息收集如何做到相对准确又不耗费大量的系统资源

单核性能优化

单核性能优化是一个没有止境的过程，我在 StarRocks 技术内幕：向量化编程精髓 一文中已经解释了单核优化的关键点和方法论，所有算子和函数的深度优化是需要数十人年的事情

多核扩展性优化

单核性能走到世界第一后，我们投入了大量精力在优化多核性能，多核扩展性的瓶颈定位相比单核会更困难些，我们已经做了大量的优化，但还远远不够。不同类型的查询在高并发下会遇到不同的瓶颈：Lock，线程池，RPC，调度问题，NUMA，CPU Cache，内存管理，IO 异步等。

多机扩展性优化

多机的扩展性的常见瓶颈点主要包括：

  • RPC 的扩展性
  • 元数据的扩展性
  • 如何解决数据倾斜
  • 如何通过调度策略解决热点，充分调用整个集群的算力
  • 优化器要确保每个算子，函数都可以生成分布式的执行计划，不会有单点执行的瓶颈

存储引擎的优化

存储引擎需要在导入性能和查询性能之间进行权衡，一般情况下，导入时候做的事情越多，查询时候的代价就更低些：

  • 更新能力的持续优化
  • 导入能力的持续优化
  • 压缩和编码
  • Compaction 策略的持续优化
  • 事务能力的优化
  • 内存使用上的优化
  • 各个级别 Cache 能力的优化

针对特定场景的性能优化一般会增加系统的复杂性

我们数据库一般都是面向通用场景开发，但是在特定场景下，我们可以获取更多信息和上下文，这时候，我们就可以进行更多的针对性优化，但这样带来的问题就是，系统的代码逻辑更加复杂，测试和维护的难度更高。

如何保证性能不退化

当系统复杂之后，多人协作经常会出现的问题是，一个人之前精心写的一段对性能影响很大的代码，被后人不小心改掉了；或者是优化 A 优化了某些场景的性能，但是却导致之前优化 B 的优化失效了。

如何能 Cover 不同的硬件环境

数据库这个复杂的软件是构建在硬件之上的，硬件是决定性能的基础，但是 CPU 有不同的型号，网络带宽有高有低，磁盘的吞吐和 IOPS 也有很大的差别，有可能一些软件层面的优化只对某些硬件环境生效。

5 稳定性之难

一款数据库的成熟，主要体现在稳定性上，而打造一个稳定的数据库有哪些难点呢：

SQL 是声明式的

  • 机器可以生成成千上万行的 SQL，SQL 各种算子和函数的组合是无法穷尽的，要保证任何一条 SQL 没有 bug，是极其困难的
  • SQL 里面的 Null 和 Nullable 是比较恶心的，不仅对性能有很大影响，对正确性也有比较大的影响

成百上千的用户场景

每个用户的硬件配置，环境信息，应用特点不一样，都可能引发不同的问题。

各种各样的集群规模

很多时候，一些稳定性，扩展性问题只有当集群规模达到一定程度，当数据量大到一定程度，当并发高到一定程度，才会暴露出来，而如何在产品发布之前在有限的资源下，通过测试暴露这些问题，也是一个难点。

功能的组合

很多时候，一个功能单独 Work 没有问题，但是多个功能相互影响时，一些 Bug 才会暴露出来，比如节点下线，触发数据的均衡和复制，又会触发数据版本的问题，进而触发查询的问题；比如导入，查询，Compaction，系统任务对 IO 资源的共同影响，这些复杂功能组合时的测试难度会更大。

函数的预期行为没有标准

比如 Date 类型和数字的比较，字符串和数字的比较，应该是直接报错，还是隐式转换，隐式转换的公共类型转成啥。 这些其实都没有统一的标准，每家数据库都有自己的实现。关键问题是即使我们改成最合理的表现，一些用户可能会因为习惯自己熟悉的数据库的表现，觉得最合理的表现是不合理的。

还有聚合函数溢出后行为，Decimal 运算精度的确定，函数一些异常行为是抛异常还是转 Null， 我们不仅要兼容用户期望的行为和正确性，还要兼顾正确性和性能。

多版本维护

由于快速迭代和发展，我们必然要维护很多版本，这给稳定性提出了更大的挑战：

  1. 用户升级到最新版本会越来越慢
  2. 定位，复现问题成本会更高，比如研发得用指定版本的代码部署环境，复现问题
  3. 解决问题后，也必须给所有版本 Cherry-pick，这时候很容易遗漏某个版本
  4. 要确定某个 Bug 到底在哪些版本修复了，成本也比较高
  5. 一个某个版本发生大的改动或者重构，之后的 Bug Fix PR Cherry-pick 就无法自动化，人工操作的成本会很高

兼容性问题

当我们维护很多个版本后，有时候不得不做一些不兼容的改动：

  1. 之前的行为本身是错误的或者不合理的
  2. 想完全删除某些旧代码

查询层是无状态的，所以不兼容的改动一般可以绕过或者改 SQL 解决，但是存储层和元数据层因为是有状态的，一旦有不兼容的问题会很麻烦。

不同语言的行为不一致

对于类似 StarRocks 这种多进程，多语言的数据库，在稳定性问题上还有一个额外的挑战是：

  • 不同语言的一些标准库行为会不一样，这会导致在不同模块计算相同函数的结果不一致
  • 之前遇到不同语言 Java 和 C++ 取余的结果不一致

这几年来，我遇到过挺多这样的 Case。

编译器的 Bug

一般编译器被各种项目大量使用，我们开发者遇到 Bug 的机会比较少，不过在开发 StarRocks 向量化的过程中，我就遇到了一个编译器的 Bug: 编译器进行向量化优化后，把 Boolean 值转成了 255，https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97255。 还有最近我们同学遇到的一个 C++ 正则标准库的 Bug: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86164#c8

分布式相关的问题

现在的数据库几乎都是分布式数据库，所以分布式系统遇到的问题，一般数据库都会遇到，比如分布式系统的常见挑战：单点故障，部分失败，不可靠的网络，不可靠的时钟。

硬件故障

数据库的存储引擎必须保证数据能被正确的存储和读取，但是我们在实际环境中不可避免的会遇到各种硬件故障：磁盘坏掉，磁盘数据错误，服务器宕机，机房断电，网络异常等。

6 生态之难

数据导入

  • 数据格式的多样性：CSV，JSON，Parquet，ORC, ARROW 等
  • 数据源的多样性：Local File, Kafka，Hive，数据湖，传统数据库等
  • 导入时支持 Transform （表达式计算）

数据导出

  • 导出格式的多样性
  • 导出位置的多样性：客户端，本地，分布式存储等
  • 全量导出和部分导出

BI 工具：数据可视化

市面上流行的 BI 工具多达几十种，每种 BI 工具深入使用后都或多或少会有些兼容性问题：Session 变量的兼容性；数据类型的兼容性；函数的兼容性等，要都完美兼容，必然有大量的人力投入。

数据迁移

要支持用户从传统数据库和各种竞品数据库顺滑迁移，我们就必须和各种数据库进行对接，这里面有大量琐碎的工作。

比如我们想将 Presto 的用户迁移到 StarRocks 上，我们就需要在 SQL 语法层进行兼容。

比如单机数据库上的一些很容易实现的功能，在分布式数据库上就会相对比较困难，这时候如果为了功能对齐，就需要不少的工作。

7 安全之难

安全包括：认证，鉴权，审计，加密，脱敏等，这里面每一项都有着大量的工作，对于金融，政府客户，安全体系要求很高；在公有云上，安全要求会更高。

8 易用性之难

在未来，毋容置疑，易用性会越来越重要，将会是一款数据库的核心竞争力，数据库分析师需要知道的数据库知识会越来越少，需要进行的操作会越来越少。 易用性主要体现在 3 个层次：

  1. 架构层面的易用性：比如 自适应执行，Automatic Clustering, Automatic Index, Automatic Scale 等。
  2. 产品层面的易用性：比如接口定义和功能上是不是足够简洁清晰，一个命令可以导入各种数据源，各种数据格式的文件，一个命令可以查询可以数据源，文件等。
  3. 细节层面的易用性：文档是否完善，报错信息是否清晰易懂，可观测性是否足够好。

难点如何解决

当你将这些点一个一个深入思考下去，你肯定会理解打造一个强大且成熟的数据库是多么困难，那么这些难题如何解呢？我之后会用几篇文章讲讲我的一些思考，欢迎关注我的微信公众号，第一时间获取文章推送。

《OLAP 性能优化指南》欢迎 Star&共建

《OLAP 性能优化指南》

欢迎关注微信公众号

康凯森