TiDB Serverless 和技术生态全景

数据库不是单一软件，而是一个生态体系。成为一款好用的数据库，除了产品自身的能力外，繁荣的技术生态体系也至关重要，既可以提升使用体验，又可以降低使用门槛。
PingCAP 在 2022 年 11 月 1 日正式发布了 TiDB Cloud Serverless Tier，本次分享在介绍 Serverless Tier 的技术细节之余，全面解析 TiDB 的技术生态全景和在生态构建中所做的努力。阅读本文，了解有关 Serverless 的更多信息，以及 PingCAP 在技术领域的最新进展。

云时代开发者面临的机遇和挑战

现在云已经不再是一个新鲜的事物，我们已经处在云的时代，与之前相比，云时代的开发者面临着与之前不同的机遇和挑战。在云时代，我们有着新的技术设施，我这里举几个例子，每个云厂商都会提供块存储服务、对象存储服务和弹性计算服务。块存储服务有高吞吐、低时延和高持久的特性。对象存储服务，比如 AWS 的 S3、国内阿里云的 OSS，提供了低成本的海量存储空间，并且这些存储还有着超高的可用性，甚至可以跨地域复制来进行容灾。而弹性计算服务，可以给我们提供多种规格的计算实力，而且还提供了不同的计费模式，当然，根据用户的诉求进行弹性伸缩，也是一个基本的能力。

有了新的基础设施，当然也有新的挑战。云厂商给我们提供了许多的云服务，并且云的初衷之一，就是让使用者可以减少很多的运维工作。但是如果你现在深度地使用云，仍然需要运维大量的云上基础设施。这些运维工作使得我们开发者的精力被分散，没法完全专注于业务本身。除了运维工作之外，如何使用好云也是一门学问，前不久我刚刚参加了 AWS 的架构师培训，其实如何多快好省地用好云，不是一件简单的事儿。云服务的使用者，很容易就会造成云上资源的浪费，产生不必要的高额费用，特别是在现在许多的云服务，仍然是按时间来收费的情况下。对于有多套环境需求的场景，比如说公司内部有多个团队，不同的业务有各自的环境诉求，或者在 CICD 的场景下，我们可能会有 preview、stage、product 的多套环境需求，购买多套的云服务会产生高额的费用，但是共享一套云服务则可能会产生资源的竞争，甚至出现测试环境影响生产业务的情况。云上的服务，比如说云上的数据库服务，现在的使用方式仍然是提前规划容量，然后始终按照购买的时候的容量进行工作和计费，如果后期需要调整，仍然需要人工介入，手动去进行扩缩容。

这个是我们目前在使用云的时候，遇到的一些挑战。那么为了解决这些挑战，PingCAP 推出了 TiDB Cloud Serverless Tier。Serverless Tier 是世界上首款的 Serverless HTAP 数据库，PingCAP 推出它，希望能够帮助开发者解决刚才所说的那些挑战，成为云时代的新的 HTAP 数据库解决方案。TiDB Cloud Serverless Tier 目前是一个 Beta 的状态。下面，我就给大家介绍一下 TiDB Cloud Serverless Tier。

TiDB Cloud Serverless Tier(Beta)：世界上首款 Serverless HTAP 数据库

当然在之前，我们还是先来看一下传统的TiDB集群。这是一个经典的 TiDB 集群架构，可以看到这是一个非常典型的分层架构，计算层是 TiDB Server，每个 TiDB Server 都是一个无状态的计算节点，可以非常容易的进行横向扩容，存储层是 TiKV 和 TiFlash。TiKV 是我们的分布式行存储引擎，TiFlash 是列存储引擎，整个存储层通过分布式协议实现了一致分布式存储。在计算层和存储层之外，我们还有一个调度单元 PD，这里存储了整个 TiDB 集群的元信息。在这样的一个架构下面， TiDB 已经有了很好的表现。比如 TiDB 有着非常好的扩展性，无论是计算还是存储，能力都可以随节点数线性扩展。

TiDB 已经在生产场景经历了数百 TB 规模的数据和百万级 QPS 的流量的考验。TiDB 还有着非常好的弹性，系统规模可以随着业务的需求进行伸缩。而且伸缩是完全在线进行的，不会影响已有的数据和请求。同时，对于系统中的热点，TiDB 也有能力自动发现，自动调度。TiDB 也有着非常好的容灾和高可用的能力，如果节点出现故障，上面的数据可以自动的进行转移，并且配合 PingCAP 推出的 TiCDC 工具，还能够做到实时的 CDC 同步，实现异地容灾。

但是这样的一个经典架构在云的时代，面对着完全不同的基础设施，存在一些问题。第一，share-nothing，刚才我们提到云厂商提供的基础设施，无论是块存储，还是对象存储，天然就有着高可用，高持久的特性，云厂商已经帮我们做了数据复制，但是 TiKV，TiDB 的存储层