由 dawei 数据库不是单一软件，而是一个生态体系。成为一款好用的数据库，除了产品自身的能力外，繁荣的技术生态体系也至关重要，既可以提升使用体验，又可以降低使用门槛。
这才有了数字化的新的基础设施，当然也注定有各式各样的数字化的挑战。云厂商给我们提供了许多的云服务，并且云的初衷之一，就是让使用者可以减少很多的运维工作。但是如果你现在深度地使用云，仍然需要运维大量的云上基础设施。这些运维工作使得我们开发者的精力被分散，没法完全专注于业务本身。除了运维工作之外，如何使用好云也是一门学问，前不久我刚刚参加了 AWS 的架构师培训，其实如何多快好省地用好云，不是一件简单的事儿。云服务的使用者，很容易就会造成云上资源的浪费，产生不必要的高额费用，特别是在现在许多的云服务，仍然是按时间来收费的情况下。对于有多套环境需求的场景，比如说公司内部有多个团队，不同的业务有各自的环境诉求，或者在 CICD 的场景下，我们可能会有 preview、stage、product 的多套环境需求，购买多套云服务会产生高额的费用，但是共享一套云服务则可能会产生资源的竞争，甚至出现测试环境影响生产业务的情况。云上的服务，比如说云上的数据库服务，现在的使用方式仍然是提前规划容量，然后始终按照购买的时候的容量进行工作和计费，如果后期需要调整，仍然需要人工介入，手动去进行扩缩容。
基于这些问题，其实 PingCAP 做了很多的努力，也都做了相应的改进，大家可以看到这是现在 TiDB Cloud Serverless Tier 的一个新架构。首先在存储层开发了 Cloud Storage Engine 一个新的存储引擎，图中 Shared Storage Layer 和 Shared Storage Pool 这两层组合起来就是新的 Cloud Storage Engine。现在新的存储引擎融合使用了云上的块存储和对象存储，并且消除了原来存储层冗余的数据复制，彻底的解决了之前所说的 share-nothing 和状态重复的问题。这样的做法可以极大地减少在存储层内进行节点扩充的费用,并且可以快速地实现。
在计算层我们进一步地拆分了 TiFlash[，TiFlash 现在它的计算存储已经可以去分离，TiFlash 的计算部分可以像 TiDB Server 一样，作为一个独立的组件去进行管理，去扩容。第二，我们引入了新的一层，叫做 Gateway。Gateway 代替了 TiDB Server 与用户进行交互，它负责诸如连接管理、唤醒节点，这样的功能。它的出现使得我们所说的多租户成为一个可能。第三，我们优化了计算节点，在图上右边的部分，有多个 TiDB 和 TiFlash。我们将计算节点进行了优化，这样的设计进一步降低了计算层的成本，以及提升了计算节点唤醒的速度。计算层和存储层的改动，使得 TiDB Cloud Serverless Tier 支持了多租户。现在一套 TiDB Cloud Serverless Tier 集群，可以支持多个租户，每个租户都是完全隔离的。在用户看来，他们拥有的就是一套独立的 TiDB 集群。
我们只需要点击创建，如果你需要可以选择名字以及供应商以及 region，这里我们都是使用默认的。然后就进入了创建的一个过程，可以看到大概在 20 秒的时候整个集群其实就已经从 creating 的状态变成了 avaliable 的状态，TiDB Cloud Serverless Tier 现在整个创建时间大概就是在 20 秒左右，可能会上下有一定波动，基本是在这样一个量级。只需要 20 秒你就可以拥有一个完全工作的 HTAP 云数据库，并且后续不需要你进行任何操作以及与它有任何运维上的交互。在HTAP上，你可以轻松实现数据库的备份、恢复、还原、查询等功能，同时还可以通过自定义脚本来实现各种复杂的应用程序。