数据库是三大根底软件之一。近年来，腾讯也在不断加强各类数据库产品的研发投入。企业级分布式数据库 TDSQL 是腾讯云数据库的代表性产品，同时具备 OLTP、OLAP，以及混合 OLTP 和 OLAP 的 HTAP 能力。它包含以下几个系列的产品：

1. 企业级 MySQL 即腾讯云数据库 RDS 零碎(CDB)，绝对原生 MySQL 进行了大量内核级补丁修复、个性优化和企业级性能，包含 SQL 审计，数据库加密和防火墙等。

2. 云原生数据库 TDSQL-C，采纳计算与存储拆散架构的共享存储产品。蕴含两大兼容版本：即 MySQL 版与 PostgreSQL 版。

3. 兼容 MySQL 的金融级分布式数据库 TDSQL-D。其基于零共享架构，适宜具备海量数据和事务交易场景应用。

4. 剖析型分布式数据库 TDSQL-A。基于 MPP 架构，具备杰出的 HTAP 能力，和自主研发的列存引擎，它还与 Oracle 高度兼容。

5.TDSQL 产品广泛应用于不同畛域，涵盖电子商务、政务、金融、社交网络、娱乐、视频等，在腾讯公司内则包含家喻户晓的王者光荣、微笑领取等。目前，腾讯云数据库实例部署规模超过一百万个 CPU 内核，领有超过 100PB 级存储规模。

因为明天工夫无限，不能涵盖每一种产品。以下次要介绍云原生数据库 TDSQL-C。

TDSQL- C 架构体系优化

首先介绍 TDSQL- C 的体系架构。家喻户晓，云原生实质上是一套利用云基础设施来为客户提供具备老本效益和高度可用性的解决方案的技术体系和理念。云原生数据库也是如此。

首先，咱们来看以后 MySQL 数据库架构存在哪些问题，以及为了构建云原生数据库咱们必须解决哪些挑战。

第一，假如在传统的 MySQL 集群中，每当一个节点退出集群时，它就必须创立完全相同数据的正本。一般来说，在本地存储中，部署隶属实例时，数据库越大，启动实例所需的工夫就越长。而且它减少了冗余存储耗费。这是没必要的，并且在某种程度上是节约。举个例子，“一主三从”集群的 1TB 容量数据库，将齐全占据约 4TB 的存储空间。

第二，当单机磁盘存储容量达到下限时，就必须将数据库实例迁徙到更大的节点，这个过程非常复杂也十分耗时。从可靠性和可用性方面来说，异步复制中可能产生数据失落。同步复制安全性更高，但提早也更高。此外，从 HA 切换复原可能须要更长的工夫，从 DBA 的角度来看，灾备产生 HA 的时候，这个工夫点是不可控的。

第三，计算与存储紧耦合可能导致硬件资源利用率不现实。例如能够设想如下场景，当磁盘行将打满时，但 CPU 使用率非常低。出于存储目标，必须迁徙到更大容量的机器。更大的机器通常配有高端 CPU 资源。这意味着客户在大多数时候必须为 CPU 领取更多费用，这对于云的客户而言没有老本劣势。

为了解决前述问题，咱们要对数据库架构进行一些根本性革新，即具备全新架构的云原生数据库 TDSQL-C (原 CynosDB)。雷同的中央是，它依然是“一主多从”架构，反对一个读写节点、多个备库节点，备库节点最多能够扩大到 15 个读节点。但最大的变动是其实现了计算与存储拆散，主节点和备节点共享一份存储。TDSQL- C 主备之间和原生 MySQL 不同的是它应用 Redo log 进行主备数据同步——Redo log 发送到备库之后只负责同步备库的 Buffer Pool，其性能比原始计划有极大的晋升。TDSQL- C 同时实现了新的数据库概念，如日志即数据库。

这使得计算层得以轻量化，对于实例启动和敞开以及集群扩容和缩容十分不便。

计算存储拆散的架构，其益处是不言而喻的：计算节点和存储节点能够独自扩容。在计算节点上，TDSQL- C 能够反对灵便的资源配置，从低端的 1 / 4 核和 0.5GB 内存始终到 96 核和 768GB 内存。与其余优化一起，读写性能失去显著进步——TDSQL- C 单体实例可撑持上 P 数据百万 QPS。此外，对于备份的故障转移和快照，操作能够秒级实现，同时回档速度也是 GB 级的。

TDSQL- C 的外围技术创新

以下介绍 TDSQL- C 关键技术冲破。分为两局部，一部分是 Serverless 性能，另一部分是性能优化。

2.1 Serverless

第一个性能是计算存储拆散。实际上，将存储层与计算层拆散是弹性扩大和 Serverless 的第一步。

TDSQL- C 计算和存储拆散，然而计算节点的主备节点会共享存储，即 Histor。和传统 MySQL 架构不同，它是一个可计算存储，体现在两点：主节点的计算节点会把产生的 Redo 日志下发到存储层，存储层会依赖于它的 Base page 以及所产生的 Redo log 来负责数据的长久化操作，存储层在收到 Redo log 后才会向计算层反馈信息，阐明 Redo log 曾经长久化，证实当初的事务曾经完结，能够让业务逻辑持续进行。业务逻辑在进行的同时，存储层会异步解决 Redo log。和传统的 MySQL 架构相比，不会有刷脏页带来的一些性能抖动问题。

在 Histor 把数据长久化之后，会把之前 Redo log 所占的空间回收。而咱们的存储也有以下个性：咱们在把本地磁盘映射到网络盘时，是依据它的物理地址映射到底下存储空间的某一个 cell 中，所以它的日志是依照页面来进行散发，每一个 cell 里都有相应的数据页和 Redo log。主节点和备节点共享存储数据，反对多数据版本。数据多版本是由 Base page 加上从计算层传递下来的 Redo log 生成的一个具备指定版本的数据来实现的。

第二个性能是通过细粒度的资源统计，实现客户只需按理论应用计费，不应用不免费。过来，随着数据规模一直减少，即便之后删除数据，数据理论规模已大大放大，然而已用空间不会减小，客户仍须要为未应用空间资源买单。为了精确计算空间使用量，咱们利用三个链表别离治理不同应用状态的 extent: 齐全占用，局部占用和未占用。只有齐全占用和局部占用的 extent 才会被增加到空间应用计算规定中，从而帮忙客户节省成本。此外，TDSQL- C 在调配空间的时候以 1 兆为单位进行调配，依据是否占用决定理论的计费存储量。当资源无需被应用时，咱们会将其回收到资源池，以便用于其它目标。所以从用户的角度登程，升高了用户的计费存储量。后续咱们还会持续优化，真正做到页级别的应用计费。

2.2 TDSQL- C 的性能优化

二级缓存
咱们在存储架构中引入了一个十分重要的性能，称为二级缓存。此前，咱们做了很多致力来优化读取性能和写入性能，但实际上，由计算和存储拆散带来的近程 I / O 不容忽视。最后，存储层次结构中只有两层，其中内存始终是缓存频繁拜访数据的第一优先级。当缓存未命中时，咱们必须依附近程 I / O 来读取数据并缓存到 buffer pool 中。如果 buffer pool 已满，则从中抉择记录淘汰并退出新读取数据。

在 TDSQL- C 中，咱们在近程存储和 Buffer Pool 之间实现了二级缓存层，它应用本地存储介质。为了晋升性能，能够应用 SSD 或 NVM 存储设备作为二级缓存的介质。从 Buffer Pool 中淘汰的页面缓存在该层——实际上并不是淘汰，而是把从 Buffer Pool 移出的数据缓存到本地的 SSD 存储或者 AEP 存储。下次访问该数据时，满足肯定的条件下，能够间接从本地读取，这样就能够最大限度升高网络 I / O 的耗费。

这项工作是往年 SIGMOD 收录论文《Spitfire:A Three-Tier Buffer Manager for Volatile and Non-Volatile Memory》思维的工程实际。

主动的无感知备份以及秒级回档
备份和复原对于确保数据安全十分重要。因为架构劣势，咱们还能够在存储层十分疾速地进行备份和复原。在备份中 TDSQL- C 实现了两个冲破：一个是无感知备份，计算层没有觉察。备份和复原能够在每个单元并行实现。咱们有一种机制来确保能够为备份制作全局快照。第二是极速回档。在咱们的试验中，备份只需几秒钟即可实现，数据能够以 GB 级别的速度回档，速度十分快。

通过这些架构降级和优化，咱们能够看到 TDSQL- C 自公布以来经验了快速增长。过来十二个月的实例数量减少近 34 倍。TDSQL- C 实用于来自不同畛域的许多客户，包含电子商务，金融，视频等。所以目前的后果十分喜人。当然，咱们还有很多事件要做，还有很长的路要走，未来必定会遇到很多挑战。

TDSQL- C 将来摸索布局

展望未来，数据库技术的倒退方向将持续由业务驱动的需要来定义。

例如，电子商务和游戏行业须要极其的性能。为了满足这个要求，兴许咱们能够依附一些技术，如多重写入来实现高可用性吞吐量，并且还能够在存储层思考硬件加速来让 I / O 得以减速。

对于更关注高可用性和安全性的金融和政府利用，咱们将开发 SQL 审计，数据库加密和寰球数据同步、就近拜访等性能。在 Ads 和 SaaS 畛域，它波及大量的混合架构能力要求。为了解决此问题，咱们或将引入 HTAP 和执行打算缓存等。咱们可能也要采纳内部生态系统来反对不同的工作流。咱们也能够思考冷热数据拆散等技术摸索。

上面大抵介绍一些咱们将来将摸索的技术。

第一个是多点写入。到目前为止，咱们在扩大读取吞吐量方面做了很多致力。然而单点写入的问题依然存在，这在某些状况下可能会成为零碎瓶颈。

咱们有一些正在摸索的想法。例如，用于全局解决日志相干逻辑（如数据一致性）的专用日志服务器，从而不须要在主节点和从节点之间传输日志。同时，咱们能够依附逻辑分区的概念来进行无抵触的多点写入。存储层中的数据能够被物理分区，也能够不被物理分区。

第二是 HTAP。传统的 T + 1 解决方案是通过 ETL 通道连贯 TP 零碎和 AP 零碎，对于某些实时利用来说可能不是一个很好的解决方案。许多产品正在构建 HTAP 性能。咱们还创立了一个基于列式存储引擎来减速剖析查问。

屏幕左侧是传统的解决方案，其中零碎以单个 R / O 节点部署。查问基于行存或列存引擎中执行，齐全由 Proxy 通过手动指定的连贯字符串或一些非常简单的启发式规定来确定，在许多状况下可能会导致一些不正确的查问路线抉择。该解决方案的另一个问题是整个查问必须齐全在基于行或列的引擎上解决，它不能联合两种引擎的长处。

因而，为了反对精密的执行打算管制，咱们须要在 MySQL 实例中构建一个列存引擎，作为对查问打算树中物理操作的加强。优化器将决定执行打算的哪一部分应该下发到列存引擎执行，并将执行的两头后果转换为行存格局返回给行存引擎。

第三个，可计算存储性能扩大。最后，咱们在存储层实现了 redo log 回放的数据库逻辑，但咱们能够做更多的扩大。比方通过将局部 SQL 计算下推到存储层，咱们能够提前将一些不合乎谓词条件的数据在存储层过滤掉，缩小网络传输和数据格式转换的开销，缩小计算层 CPU 的应用，相似的性能还包含聚合操作下推。为了做到这一点，咱们须要定义外部协定将 SQL 计算操作下发到存储层，存储层将两头后果（intermediate result）传回到计算层。这个我的项目也还有很多工作要去发展。