TDSQL | 云原生时代的数据库技术革命

大家好！我是腾讯数据库工程师程彬，非常荣幸能够代表团队在这里和大家一起交流一数据库领域一些技术思考和技术实践。

**今天和大家分享的主要包含三部分：**第一部分，在最新的云原生时代，数据库技术该何去何从，将怎么进一步演进？第二部分，基于 TDSQL-C 这样一个数据库的产品，怎样去构建一个新时代的数据库的产品？最后是用户的实践。

**当云计算这个词还在热度的时候，其实云原生的时代就已经悄然而来。**在云原生时代里面最大的改变是什么呢？在云原生时代里面，我们的感觉是用户使用云的方式发生了极大变化，在过去用户可能会把自己 IT 架构或是业务系统从自建的 IDC 或传统的 IDC 搬迁到云上面来。但是最近几年客户上云有一个很大的变化，不在是直接搬迁上来，而是根据云上基础设施、IaaS 或者 PaaS 的一些特点，进行自己 IT 架构的升级或业务系统的升级。

**用户使用云的方式的改变，会对云上的云数据库有哪些挑战呢？**这里面的挑战非常大，举一个例子，比如用户在云上面自己去购买虚拟机，部署自己数据库，而现在虚拟机提供了很可靠的存储副本数本身就是三份，如果你在数据库上层再做架构的冗余，整个数据库存储副本数就会放大很多。

那么这个问题应该怎么解决呢？先简单回顾一下数据库技术演进的历程，从技术的角度来讲，数据库是利用计算、存储、网络的能力对用户数据进行存储和加工，数据库技术的演进也离不开基础设施和数据特征变化。

在上世纪七十年代，以大型机和专用网络为主，这种情况下使用计算机的场景或者用户数是不多的，主要是国防或科研单位，或是一些大型的商业公司来使用数据库，他们的数据量规模不是很大，但是数据价值非常之高，就催生出了以 Oracle 和 IBM 为代表的商业级数据库。

商业级数据库给人最大的印象就是贵，但是它贵是有理由的，首先是软件贵，它有三件了不起的事情，第一件是实现了二维标为代表的数据模型，这种模型最大的好处是把客观世界数据能在数据库系统里面完好的保存下来。另外一个很了不起的事情，到现在为止也影响着数据库，很多时候大家拿 SQL 代表数据库，SQL 是非常了不起的语言，有了 SQL 之后才有了数据库广泛的被适用。最后就是事务处理的能力，让数据库能真正用到一些关键的业务场景里面去，实现数据库的存储。

随着计算机和因特尔技术进一步发展，我们发现使用计算机的用户变得越来越多，催生出了以谷歌为代表的互联网企业。而在互联网时代数据库又遇到一个新的挑战，那就是用户的数据急剧增长而带来成本挑战。

**怎么去解决成本问题？**之前的数据库为什么贵重首先是软件贵，通过开源共建的方式来去降低整个软件的成本。第二个是硬件问题，传统数据库依赖于一个很昂贵专有的硬件设备，怎么去解决这个问题？方法也很简单，可以通过普通 PC 服务器来去承载，普通服务器带来一个问题，是它的可用性，包括性能相比于专有的设备是有一定下降的，这时很自然会想到通过集群、分布式的方式来去解决这个问题，开源和分布式为基础的互联网技术体系就应运而生，同样，互联网的数据库也是基于这个体系来去构建的。

云计算时代又有什么变化呢？以前一家公司只需要管理自己数据库，而现在变成一家公司要管理数以万计数据库，管理规模增大带来了两大问题。第一个问题，怎么让数以万家技术不同的公司能很好使用到云上面的数据库。第二个问题，大规模管理下怎么去提高管理效率，数据库即服务就应运而生了，大家都会想尽办法通过服务的方式来规避在使用上瓶颈，想办法提升整体资源的利用率。

随着数字经济普及，这里面又遇到一个全新问题，比如说腾讯云数据库上发现用户数整体增长还是按照很高增长在往上增长，客户结构跟之前也发生了变化，有更多的创业用户上云，成本变得更加敏感。第二个，我们发现在云上面跟着腾讯云一起成长用户，从创业公司到独角兽到上市公司，他们对数据库弹性要求随着他们自己公司价值变得越来越高。另外，传统线下，包括银行、政务逐渐上云，对稳定性要求更高。

再说一下之前基础架构上的天花板，基于分布式和开源的架构下解决了很多问题，但它还是有一些先天的不足，并没有解决得很好。第一个，对计算、存储这种资源的耦合度非常强，导致整个资源利用率是偏低的，反过来说，这块的成本就偏高。第二个，弹性能力上面，因为受限于资源的紧耦合，在弹性上面做不到极致。

**基础设施又有什么新的变化？**我们发现在云上面的 IaaS、PaaS 它的承受度会变得越来越高，那么是不是可以换一个思路来看这个东西？数据库本身包含计算、存储、加速，是不是有可能基于云上面的基础设施打造全新数据库来提供极致弹性呢？答案是肯定的，所以我们就会去尝试去研发出一款全新的数据库。

**首先从架构上来看，可以把单体架构升级为更可控的弹性架构。**设计理念很简单，第一，如果要去提供弹性，首先要去把解耦，各种资源做分层设计，把数据库当成一个计算机来看待，把计算、存储进行分层来处理。分层过后，我们通过池化让每一层的能力，让计算、存储的能力变得无限之大。但是数据库还要解决一个很大的问题，就是稳定性的问题，一个好的数据库稳定性怎么去打造？我们基于云上的 IaaS 跟 PaaS 来进行重新设计数据库，会复用到之前数据库的内核和已有的非常成熟的计算技术，去复用 EV 级规模存储的平台。基于这样的平台，去打造六大核心能力。

第一个就是可计算存储能力，我们践行 log is database 设计理念，把计算节点做到无状态。第二个是超大计算/存储力，单个实例可以做到千核级别的计算能力，达到 PB 级的存储能力。第三个是弹性，我们希望做到秒级扩展，再进一步让这个事情变成自动伸缩的能力。在成本上，我们会通过 Serverless，包括一些多级的存储，来把整个成本降到极致。另外就是简化用户开发门槛，通过一体化服务，尽量让用户架构变得简单，在一个数据库里面尽量去处理多种场景。

在计算存储解耦过后，这里面其实是有很多问题的，第一个问题就是当计算存储分离后，之前数据库内部很多 IO 操作会变成一个网络的操作，怎么去解这个东西？大家可能很容易想到，后端拿了一个类似于云硬盘产品，直接在数据库上面一跑就 OK 了。这里面有很大的问题，首先是网络上的放大，有可能你修改一个字段，修改一行，但是会一个 pag 的放大，这个放大效应在 10 倍、20 倍之上，网络放大过后就会影响到实地吞吐能力。第二，这种简单计算存储解耦过后，并没有解决数据库计算层很复杂问题，大家都知道对于 DBA 来说很痛苦的事情就是数据库的刷章，数据库刷章很有可能导致无法处理。还有一个问题，计算层还是要去处理存储的逻辑，这时是要把计算层的资源额外放到它不应该做的事情上面去。

基于这个，我们实现了一种 log is database 的方案，我们不再按照传统的方式去做，而是把一部分数据库计算逻辑下沉到存储层进行完成。简单来说，要去改变一个字段时，只需要把改变这个字段事务日志通过这样一个操作传达到后端存储，由后端存储来就近去处理帮日志转化成它最终需要行的数据。这样一个改变能够极大减少网络带宽；同时，因为把数据库计算能力下放到存储上面来，计算本身 CPU 资源可以更好地去服务数据库的逻辑处理。

同时另外一点，我们把日志和存储做了分布式后，在数据库里传统的问题就是怎么去做式 crash recover，我们通过把之前集中式故障恢复的机制变成分布式，整个时间也会大大缩短。

**另外一个能力，做到千核计算力和 PB 存储力。**依托于下面一个分布式存储系统，而这个分布式存储系统是腾讯，包括腾讯内部业务在上面去运行超过 1B 级规模的存储，通过修改数据库本身的核心逻辑，来把数据进行分布式的打散，实现单个实例可以支持 PB 级存储规模。

可用性上，云数据库要解决一个很重要的问题，因为我们的规模非常之大，在做版本升级时候，要改革传统方式，去通知用户，希望用户去配合，我们通过 Zero-Downtime Patching 的能力，希望把这个做到数据库内核里面，让它的升级可以做到秒级。

当我们做到很好的计算扩展时，又遇到一些挑战，不同用户对数据的一致性要求是不同的，我们重点实现了包括会话一致性、全局一致性在里面。

云上面有很多中仓尾的用户，这些用户一天可能就访问几个小时，那么怎么进一步降低这一部分开发者成本呢？我们通过 Serverless 去解决，通过智能监控，发现这个实例计算资源已经持续多长时间没有进行任何处理，我们会把它的计算资源进行释放，在他们使用计算资源的时候，不是传统分配给你一个核，就收一个核的钱，而是通过采集它实际 CPU 使用率，通过它使用了多少来进行计费。要做到这种能力，技术上挑战也是非常之大的，无论是数据库计算层还是存储层，都要通过一系列技术联合才能做到这一点，这是计算上面的优化。

说完计算极致成本之外，我们在存储上也有一个极致成本，数据库里面并不是所有的数据库它的热度、访问都是那么高的，很多数据可能随着时间变化，数据被访问的频度会降低。针对这个情况，我们做了一个存储的分层，存储分层除了通常做的热数据、温数据、冷数据之外，在这里有一个不一样的地方，我们在温数据里面通过了一个新技术，打破了在数据库存储里面通过副本的方式来保证可靠性，可以用更小的数据冗余度、更少的副本提供同样可靠性来满足用户的要求。

同时现在越来越多的用户，特别是一些新型应用，比如说直播带货，它有一些新变化，在生产订单的同时他还需要依据订单情况来及时调整线上的折扣策略，需要对海量订单进行实时数据分析。通过这个我们提出了叫做 HTAP 一体的解决方案。我们是怎么做到 HTAP 解决方案呢？主要是四个方面。

**第一个，我们在存储引擎上面做到行列混存，通过列存来加速查询能力。**在优化器上面，我们把以前面向行的优化器进行优化，让它自适应能去进行分析场景算法调整。在执行引擎上，把单一串行的执行引擎调成分布式执行引擎，加大数据查询能力。最后在计算上面做了优化，把多个节点技术联合起来做协同，通过 NVM 拓展内存，相比之前提高了 50 倍的性能。

这个产品在最近的 18 个月里面实现了 24 倍的规模增长，除了我们自己工程师努力之外，也要感谢用户，正是由于用户们的参与，我们数据库才会有信心做得更好，谢谢大家！