对话巨杉数据库核心研发：分布式数据库修炼之路

分布式数据库是当前数据库发展的主要方向，但是一直以来数据库的核心研发都是十分神秘的团队，作为巨杉数据库幕后的隐士高人，他们对数据库发展以及数据库研发团队的看法是什么呢?本文我们就由一位巨杉数据库的技术“老江湖”向大家分享分布式数据库自研之路。

1、 作为数据库行业的“老江湖”，您能否先介绍一下自己?

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

目前，我这边也是SequoiaDB巨杉数据库，北美研发实验室的成员之一。我们这边实验室的团队成立以来，已经有很多数据库的专家“老炮”加入，很多也是来自DB2 的核心技术团队。

虽然我们团队很多都是来自IBM、华为的“传统企业级IT人”，不太喜欢抛头露面。但是现在是技术圈一个变革的新时代，我们的产品已经开源了，所以我们之后也会让更多我们团队的技术大牛们多多参与社区活动，分享一下我们做数据库核心研发的心得，也和大家一起进步。

2、 作为“老IBM”，您认为像IBM这样历史悠久的IT企业，他们的核心研发团队是怎么样的呢?您对此感受最深的是什么?

IBM是最早提出“关系型数据库”这一概念和理论体系的公司，我在DB2的十几年里，感受最深的就是技术底蕴和沉淀。

从技术上看，传统三大关系型数据库在发展过程中，其实已经具有很深远的技术储备了。

比如说，在Unix真正支持线程机制之前，针对多线程模型，甚至是针对不同的硬件设备，他们早已使用汇编语言实现了逻辑线程的切换和调用，这些机制在当时其实是相当领先的。

而说到研发团队，IBM的实验室也是卧虎藏龙。从最初使用汇编语言开始的技术专家们，一直在参与数据库、操作系统和编译器底层的研发工作，可以说正是他们创造了最早的关系型数据库的概念，也是他们真正把数据库打造成为一个通用的软件平台。

DB2是三大传统关系型数据库中唯一的分布式产品，因此我们团队在分布式技术方面的积累是一脉相承的。

3、 像数据库这样的基础软件，技术上的难度最是什么?

数据库软件，特别是一款真正企业级ready的产品，并没有大家想象的，只是开发一款软件那么简单。

从技术上，数据库既要有历史沿袭和基因又要创新：

数据库技术到现在已经发展了40多年了。在技术的发展中，数据库软件/平台已经成为一个功能复杂，架构庞大，安全要求很高的庞大软件产品体系。因此，技术上既需要沿袭前人的道路，也需要新的创新。

同时，应用端，由于都是银行、政府这些30年前已经使用的用户，因为无法承担全盘迁移的风险，因此在业务技术架构上难免保持了各个时代的遗留(举例子，北美部分银行IT还保留了数据库之前的技术作为核心，至今没有替换)。这也要求企业级ready的数据库基础软件是要有很强的兼容能力的，既保证旧业务运行，又可以有创新。

同时，在应用端这边，由于用户都是银行、政府等这些30年前就开始使用数据库的老客户，他们通常无法承担全盘迁移的风险，因此在业务技术架构上，难免保留了各个时代的历史遗留(举个栗子，北美部分的银行核心IT系统直到目前仍然没有替换掉以前数据库古老的技术)。这也要求企业级ready的数据库基础软件需要有很强的兼容能力，不但可以保证旧业务的运行，还可以不断地推陈出新。

这种“融合式”的创新是必须的，但在技术上却又是最难的。

4、 以您近20年的数据库行业经验，您认为数据库核心团队应该是怎么样的?

我认为数据库核心研发团队的基因很重要，就比如说IBM的DB2团队，就是以多位数据库领域的“老炮儿”为核心，搭配有技术实力的资深工程师，而不像现在很多的开源新产品，他们都是以年轻的创新团队为主。

就像我上面提到的技术复杂度和产品历史跨度的问题，数据库产品如果要在大型企业内使用，技术团队必须要有传统数据库的开发经验，这也就是技术老炮儿存在的作用。

简单说，数据库基础软件就是创新技术和技术经验积累的融合体。

5、 海内外基础软件研发有什么不同?

相对来说，海外拥有技术人才的基础，也有像IBM Oracle这样的体系的沿袭，培养出了一批批技术人才和团队。所以现在北美很多新一代基础软件产品团队其实还是围绕了老一辈的“老司机”构建的。

而国内基础软件的人才积累还不够，因此基础软件领域还没有完全形成基础软件领域的武林门派，这也是近年来基础软件和AI领域国内企业疯狂往外招人的原因。但是数据库由于历史原因，国内无论是互联网还是科研团队想要形成独特的门派，还需要时间。

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

6、 数据库开发和其他软件有什么不同?

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

从计算机的发展来看，C是最面向机器语言(汇编代码)的，原则上每一行C代码都可以很精准地映射到一些汇编指令上，因此从对操作系统底层的操控来看最为精准。

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

而如今新的一些新型开发语言(如 Go语言)则不是面向对象，因此在设计模式上不适合大型复杂系统的开发。同时，这些语言语言简化了很多C/C++里最为重要的指针概念，时其对内存的精准操作变得不可能完成。指针这个概念用好了是神器，用差了是垃圾，大部分能力不高的程序员，或者没有非常完善测试框架的项目很难完美把握指针这类高级特性，使得大型项目开发里面内存泄露和崩溃漏洞遍地都是。

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

7、 分布式数据库方向是什么?

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

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

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

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

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

8、 SequoiaDB自从发布3.0版本以来，在社区和市场得到的反馈都很好，能否透露一下产品的一些新动向?

近期，我们巨杉会发布一个新的版本，其中OLTP场景选性能会有大的提升，巨杉数据库对于SQL处理能力也会有很大提升。在分布式的交易型业务下，新版本巨杉数据库整体性能提升将比现在版本有2~3倍的提升。