传承or创新 ？解密分布式数据库自研修炼之路

一直以来，数据库的核心研发团队都十分神秘，作为隐藏在幕后的隐士高人，他们对数据库研发的心得是什么？他们又对数据库的未来发展有什么看法呢？本文就由巨杉数据库核心技术研发团队的“老司机”，分享分布式数据库的自研修炼之路。

数据库软件，特别是一款真正企业级的产品，并不是大家想象中仅开发一款软件那样简单。

追溯数据库技术的发展历程，数据库（database）一词最早流行于系统研发公司的技术备忘录中，到目前已有 40 多年的历史。在这期间，数据库软件 / 平台逐渐成为一个功能复杂、架构庞大、安全要求很高的庞大软件产品体系。因此，在此发展基础之上，技术基因传承和技术创新成为数据库技术的最关键两个点，但这两项关键点恰恰是数据库研发的最难点，为什么这么说呢？

从应用层面上讲，大部分用户是从 30 年前就开始使用数据库的老客户，例如银行、政府等。他们通常无法承担全盘迁移的风险，因此在业务技术架构上，难免保留了各个时代的历史遗留。比如，北美一些银行的核心 IT 系统，直到目前仍然运行在 40 年前的技术平台之上。所以，这也要求企业级的数据库需要具备很强的兼容能力，不但可以保证旧业务的运行，还可以持续进行技术创新。

同时，基础软件特别是数据库的研发，和其他应用软件有很大的不同。其中最大的一个不同点就是开发语言和开发模式。

从计算机的发展来看，C 语言是最面向机器语言（汇编代码）的，原则上每一行 C 代码都可以很精准地映射到一些汇编指令上。因此，C 语言对操作系统底层的操控最为精准。而 C++ 则是在 C 语言之上发展起来的面向对象语言，虽然在底层编程中 C++ 的高级特性被使用得非常少，但是其设计模式对于模块化开发很有帮助。因此，使用 C++ 既可以兼顾对操作系统底层最精准的把控，也可以将一些面向对象的理念融入代码中，在复杂系统构建时起到重要作用。

而如今，一些新型开发语言则不是面向对象的，所以在设计模式上不适合大型复杂系统的开发。同时，这些语言简化了很多 C/C++ 里最为重要的指针概念。而对于大部分能力不高的程序员或者没有非常完善测试框架的项目，不能完美把握指针这类高级特性，则会在大型项目开发中经常造成内存泄露和崩溃漏洞等问题。

但是，对于有着 DB2 数据库内核研发经验的巨杉数据库而言，从人员能力，到代码质量管理，到测试框架的完善都能够完美驾驭这类高级特性，能够最大程度挖掘出操作系统和数据库底层的性能与处理能力。

IBM 是最早提出“关系型数据库”这一概念和理论体系的公司。从技术上看，传统三大关系型数据库已经具有很深远的技术储备，而 DB2 是三大传统关系型数据库中唯一的分布式产品。

在 DB2 工作的十几年里，给我感受最深的就是其技术底蕴和沉淀。比如，在 Unix 真正支持线程机制之前，针对多线程模型，甚至是针对不同的硬件设备，DB2 早已使用汇编语言实现了逻辑线程的切换和调用，这些机制在当时其实是相当领先的。另外在研发团队上，IBM 的实验室也是卧虎藏龙。那些最初使用汇编语言开始的技术专家们，也一直参与数据库、操作系统和编译器底层的研发工作，可以说正是他们创造了最早的关系型数据库的概念，也是他们真正把数据库打造成为一个通用的软件平台。

因此，数据库核心研发团队的基因很重要。就像上面提到的技术复杂度和产品历史跨度问题，新一代基础软件产品团队要围绕老一辈的“老司机”构建。而 DB2 团队就是依靠多位具有传统数据库开发经验的“老炮儿”，实现了 IBM 数据库产品技术经验和基因的沿袭。

然而，国内基础软件的人才积累还不够，目前还没有完全形成基础软件领域的武林门派，这也是近年来基础软件和 AI 领域国内企业疯狂往外招人的原因。

而巨杉数据库团队拥有以王涛为代表的很多 DB2 团队的核心技术专家，以及来自华为的技术核心团队成员，是技术基因和技术创新很好的结合。

对于大部分应用程序来说，账户信息、配置信息、维度表这类数据量相对比较可控，真正爆炸性增长的是流水类数据。一个应用程序里面绝大部分表不会太大，真正特别大使得传统关系型数据库存不下的表相对来讲数量都是可控的，因此有很多 workaround 都可以搞定这个问题，这也是为什么传统以来大家用分库分表虽然麻烦，但也不是解决不了应用问题。

所以，数据库真正面临的痛点是“微服务”下，数据服务的资源池化。

应用程序在从传统烟囱式构建，向微服务转型的过程中，在每一个微服务都放上一个独立的数据库已经是不可能的事情了。这种情况下，数据服务资源池需要直接面向上层成百上千个，来自不同开发商、不同团队的开发能力不一、应用类型不同、SLA 安全级别不同等等的各类需求。

因此，资源池必须拥有弹性扩张、资源隔离、多租户、可配置一致性、多模式（支持各类 SQL 协议）、集群内可配置容灾策略等一系列功能，同时每个数据库实例的计算和存储能力需要满足能够无限扩张的条件，毕竟有些微服务可能会涉及到极多的流水数据，不能限定每个数据库实例使用的资源仅局限于一台物理设备。

所以说，单纯为了分布式的 OLTP 只是解决了不构成刚需的问题（分库分表早可以解决），但是在微服务应用开发的环境下，数据库更是要从资源池化的角度对上层提供服务，同时资源池中的每个数据库实例内部也要支持分布式交易等一系列特性，做到与传统数据库的全兼容。

近期，巨杉数据库会发布一个新的版本，不仅在 OLTP 场景选性能会有大的提升，同时也对于 SQL 处理能力上有很大提升。

另外在分布式的交易型业务下，整体性能提升将比现在版本有 2~3 倍的提升，对比同类产品性能将高出 5~6 倍，也请期待巨杉数据库接下来的系列技术专题和技术活动。

虽然巨杉数据库团队很多都是来自 IBM、华为的“传统企业级 IT 人”，大家都习惯低调地隐藏在幕后，但是现在是技术圈一个变革的新时代，SequoiaDB 巨杉数据库已经开源了，所以今后也会让巨杉数据库团队的技术大牛们多多参与社区活动，分享我们做数据库核心研发的心得，也和大家一起进步。

作者简介：

巨杉数据库核心研发成员，资深数据库架构师，Danny Chen

超过 20 年的数据库核心研发经验，是一名数据库资深工程师和架构师，曾经作为 IBM DB2 内核研发团队成员参与了 DB2 ，DPF 等产品的架构设计和研发工作。