PingCAP 黄东旭万字长文：剖析数据库发展新趋势与应用开发者的关系

本文由 PingCAP 联合创始人兼 CTO 黄东旭撰写，基于亲身经历的数据库行业，深度总结过去一年数据库发展的重要趋势，以及展望 2023 年数据库新方向，希望对更多的行业从业者有所启发在他看来，数据库未来的发展趋势必然是以「省人、省时、省事、省钱」为主要目标，在云原生趋势下，其不单单是作为一种软件，而是一种服务来成为加快科技发展的重要引擎。

2022 年，我们被太多的技术热词所围绕，也让很多企业和开发者对未来的科技世界越来越迷茫 今年我有很长一段时间在北美技术圈，有一些切身感受：一个是大环境下影响下的经济变差经济不好的时候就要去省钱，会采取比如降低 Infra 投入等措施，这多少都会影响公司的决策。

如果你是一个解决方案提供商，要去卖产品时，倘若在产品的价值或者故事中没有体现能帮客户省多少钱，基本上对方可能看都不会看你一眼；第二个是缺人用另外一个说法表达就是“从业者门槛降低”比如说你原来可能是一个 Infra 工程师，现在可能要被迫变成一个全栈工程师，就相当于一专多能，或者说对于开发业务应用的门槛需要被降得更低。

现在大家都希望用更少的人，更快的时间去进入市场 那针对上面痛点，映射到数据库技术上有哪些趋势变化？ 对于新一代的数据库来说，HTAP 是必选的技术路线，我有一个预言：未来的数据库都会是 HTAP 数据库

只有纯 AP 对于业务来说是不完整的，TP 非常重要数据库要用云原生的方式进行架构改造，不仅是存算分离，而是能分离的都分离，因为现在数据库要做的已经不再是一个软件，而是一个服务，用户也不会关心服务背后的东西。

用户希望使用起来越简单越好，最好把所有基础设施的细节都隐藏掉，极低的心智负担带来极低的上手体验和价值确认Serverless 将成为数据库最终的产品形态（注意：Serverless 并不是技术，而是产品形态）。

未来的数据库都会是 HTAP 数据库2022 年，HTAP 一词越来越火虽然从考古上来讲， HTAP 最早是在 2014 年由分析机构 Gartner 提出，但直到现在其实它还是一个很新的概念，不少人还是持有偏怀疑的态度，然而，这个需求又是存在的。

大家未必会去定义它到底是哪个名词，但是大家都会去用很多人现在还不太想说把 HTAP 变成一个专有的类别，而是想先用一些新型的数据库或者新型的产品解决业务问题我认为 HTAP 的普及还需要一定的时间，不过，当前已经能够看到星星之火开始成燎原之势。

2022 年 5 月，Google Cloud 发布了最新的数据库产品 AlloyDB，HTAP 能力便是其中最显著的亮点；6月，当红 Data Cloud 厂商 Snowflake 首次发布了 HTAP 产品 Unistore 。

至此，全球三大云厂商 AWS、微软、GCP 和 Data Cloud 领导者 Snowflake，以及正在加速云转型的数据库巨头 *** （MySQL Heatwave）都已经发布了以 HTAP 为主要架构亮点的数据库产品。

如果细看这些产品，你会发现 MySQL 在 2021 年发布的 Heatwave 虽然在分析能力上是个 MPP 的架构，但 MySQL 本身还是单机版的，Google AlloyDB 参考了 AWS Aurora 的架构，做到了青出于蓝的效果。

NewSQL 的分支鼻祖是 Google Spanner，但同为 NewSQL 架构的 TiDB 持续在 Real Time HTAP 投入巨大，TiDB 早期解决了 MySQL 分库分表的问题，就面临用户的在线分析需求。

在 2018 年 TiSpark 的引入，2020 年 TiFlash 架构完成了 HTAP 架构的闭环，再到 2021 年 TiDB 5.0 版本的 MPP 能力，这个能力也通过 TiDB Cloud 向所有云上用户输出，在 5 年时间 TiDB 完成了 Real Time HTAP 产品能力的四连跳。

总体来看，虽然各产品的具体实现有所不同，但新一代 HTAP 架构有一些明显的共性追求：以开源打底，借助了云端扩展性，追求一个入口，一套数据栈，可以将 OLTP 数据和 OLAP 数据实时同步，部分厂商 OLAP 的实现采用了类似 MPP 下推方式，达到 No Application Change、No Schema Change、No ETL，No data move 的四不效果，最大化减少对应用程序的改动。

任何一种数据库潮流都是“需求变化??技术变革??架构创新” 三者融合的产物，HTAP 也不例外 首先，在需求变化侧，推动新一代 HTAP 的数据库厂商在提到 HTAP 的时候都不约而同地用到 Operation

这个词，借助热数据实现运营级别的实时分析，获得实时的洞察以支持运营动作的反馈，这是推动新一代 HTAP 走上舞台中央的最大需求侧变化 其次，在技术变革与架构创新侧，云基础设施的发展带来了存算分离更为彻底的变化，这是技术变革带来的新可能性。

分布式理论与云计算、AI 算法的融合带来了新一代的架构创新，这些都使得 HTAP 在云端可以支持不同的云存储，AI 等新技术，打造更有成本竞争力的创新 我认为真正 HTAP 的形态其实在云上做意义才大，因为 its all about balance，只有在云上才能去打破 AP 跟 TP 之间对于资源的不平衡

比如像 TP，其实要求的是一个稳定、高性能、低延迟的一些硬件资源，但对于 AP，可能是短时间海量的计算资源，因为要做高性能的 AP，你会发现在云下这个东西怎么摆都别扭，我为什么要去买这么高配的服务器，我为什么每天就跑三次大的全表扫描，但是 99% 的时间 CPU 都压不上去。

云原生已经开始进入下一个阶段今年在北美看到的情况是几乎所有公司都在做云 / 云原生方向的转型，这并不是需要讨论的事情，而是已经完备的状态 第三，这一轮 HTAP 的用户群体和上一代内存数据库 HTAP 的小众贵族非常不同，这一代 HTAP 的用户非常大众化，

几乎采用 MySQL 和 PG 开源数据库的所有企业都可以借助新一代 HTAP 架构拓展 OLTP 和 OLAP 的能力范围，都能用上一种不用修改应用，不用增加额外数据系统且拥有强大分析能力的数据库要用云原生的方式进行架构改造

今天做数据库，如果不提供云服务，出门都不太好意思和人打“招呼”（很快就会是 Serverless）有很多人（尤其是数据库内核开发者）会低估做一个云服务的复杂性，经典的论调：“不就是在云上的自动化部署吗？”或者“支持一下 Kubernetes Operator？”。

其实并不是，甚至目标都应该反过来：我们要做的并不是一个数据库软件，而是一个数据库服务，当我们用更长的眼光去看的时候就会发现，后者是包含前者的这个认知的转变是做好数据库云服务第一步，也是最重要的一步 过去我们开发程序，不同的模块看到的环境是同构且确定的，例如：开发一个单机上运行的软件，不同的模块虽然可以有逻辑上的边界，但是链接到一起之后，运行起来看到的还是这台计算机的一亩三分地，「Everything is a trade-off」。

即使近几年分布式系统的兴起，但对于经典的分布式软件而言，大致还是单机软件设计思路的延伸，只是通过 RPC 将多台计算机连接在一起，环境是相对确定的，尽管很多软件对于底层的环境变化做了一些适配：例如分布式数据库的动态扩容，数据重均衡 Re-balance 等，但是本质并未变化，只是能够操控和调度的资源变多了。

然而，在云上，这些假设都发生了变化： 多样且几乎无限的资源通过 Service API 的形式提供，对于资源的调度和分配可以通过代码完成，这是革命性的变革一切资源明码标价，所以程序优化的方向从过去的一维的榨取最好的性能（因为硬件的成本已经事先支付），变成一个动态的问题：尽量花小钱办大事。

假设的变化带来技术上的变化：云上的数据库，首先应该是多个自治的微服务组成的网络这里的微服务并非一定是在不同的机器上，在物理上可能在一台机器上，但是需要能在远程访问，另外这些服务应该是无状态的（无副作用），方便快速的弹性扩展，这个带来对于开发者的转变就是：。

放弃对于同步语义的坚持，这个世界是异步化且不可靠的我很高兴我的偶像 Amazon 的 CTO Werner Vogels 在 2022 年 ReInvent Keynote 上也强调了这一点 放弃掉对于同步和单机的幻想，得到了什么？我们看一些例子： 。

第一，最近几年被“聊烂”的存算分离在云上，计算的单位价格比存储要高得多，如果计算和存储绑定，那么就没有办法利用存储的价格优势，另外对于一些特定的请求，如对计算的需求很可能与存储节点的物理资源是完全不对等的（想象一下重型的 OLAP 请求的 Resuffle 和分布式聚合）。

另外，对于分布式数据库来说，扩容速度是一个重要的用户体验指标，当存算分离后，原则上扩容速度是能做到极快的，因为扩容变成了：一是启动新的计算节点，二是缓存预热；反之亦然 第二，对于数据库来说，一些内部组件的微服务化

，例如：DDL-as-a-Service传统数据库的 DDL 对于在线业务是有影响的（即使用了 Online DDL），例如添加索引时候，不可避免的需要进行数据回填，这对于正在服务 OLTP 负载存储节点来说会引起抖动。

如果我们仔细思考一下 DDL 就会发现它是一个：全局的、偶发的、重计算、可离线进行，可重入的模块，如果有一个共享的存储层（例如 S3），这类模块非常适合剥离出来变成一个 Serverless 的服务，通过 S3 与 OLTP 的存储引擎共享数据。

带来的好处毋庸置疑： 对在线业务也是几乎没有性能影响因为按需运行，带来成本下降类似的例子还有很多：日志（CPU 使用少，但是对于存储要求高）、LSM-Tree 存储引擎的 Compaction、数据压缩、元信息服务、连接池、CDC等等，都是可以且很适合被剥离的对象。

在新的 Cloud-native 版本的 TiDB 中，我们使用了 Spot Instances 进行存储引擎的 Remote Compaction，带来的成本下降是惊人的 在设计云数据库的时候，另一个重要的要思考的问题是：QoS(Quality of service)，具体到细节大概是：

需要定义 WCU 和 RCU，作为控制的单位，如果没有办法定义它，你将没办法进行资源的分配和调度，乃至定价多租户是必选项，租户之间一定要可以共享硬件甚至集群资源，大租户也可以独占资源（单租户模式是多租户的一种特化），带来的问题：如何避免 Noisy Neiberhood 问题？如何设计 Throttling 策略？如何避免共享的元信息服务 Overwhelm？如何应对极端的热点？。

挑战还有很多，我就不一一列举了另一个很重要的话题是：云上哪些服务可以依赖？这是因为对于一个第三方厂商来说，跨云（甚至是跨云下，类似混合云）的产品体验是天然的优势，如果对于特定的云服务依赖得太深太紧，将会让你丧失这份灵活性。

所以选择依赖的时候需要非常小心，下面是一些原则： 依赖接口和协议 ，而不是具体实现，服务内部可以随便自己搞，但是给其他服务暴露的接口要通用且不要做过多假设，简单来说，就是被调用者心智负担最小化（UNIX 时代留存下来的古老智慧）。

一个很好的例子是：VPC Peering 和 PrivateLink，如果按照这个原则，肯定选择 PrivateLink，因为 VPC Peering 倾向于暴露更多的细节给被使用者有行业标准就 Follow 行业标准

（S3，POSIX 文件系统），每个云上都有对象存储，而且每个云的对象存储 API 大概都会兼容 S3 协议，这就是好的唯一的例外是安全如果没办法做到跨云的抽象，也别自己强行造轮子，云有什么就用什么，例如密钥管理、IAM 等，千万不要自己发明。

下面举几个例子说明一下，对于 Cloud-Native TiDB 来说，在选择依赖的时候做出如下选择： 存储S3，就像上面提到的，每个云都会有 S3 协议的对象存储服务在数据库中使用类似 LSM-Tree 的分层存储，带来的好处是能够通过一套 API 来利用不同层次的存储介质，例如上层的热数据可以使用本地磁盘，下层的数据在 S3 上，通过异步的 Compaction 来将上层的数据交换到 S3 上。

这是 TiDB 存算分离的基础，只有数据在 S3 之后，才能解锁 Remote Compaction 等操作但是带来的问题是：S3 的高延迟注定了它不能出现在主要的读写链路上（上层缓存失效，会带来极高的长尾延迟）。

对于这个问题，我是比较乐观的： 如果我们考虑 100% 本地缓存的场景，就退化成经典的 Shared-Nothing 的设计，用于支撑最极端的 OLTP 场景我认为是没问题的（参考现在的 TiKV），额外付出代价只是 S3 上的存储成本哪一个是很低。

如果分片做得足够细，缓存和热点问题是好解决的分层存储中还可以加入 EBS（分布式块存储）来作为二级缓存，进一步削峰（削弱本地缓存失效带来的延迟突变）我在 2020 年的一次分享中提到，对于云原生的数据库而言，如何能利用好 S3 会是关键。

这个观点到现在还没有变化 计算容器 + Kubernetes，和 S3 一样，每个云都有 K8s 的服务，就像 Linux 一样，K8s 是云的操作系统，虽然存算分离做完后，计算相对好管理一点，但是像一些计算资源池的管理，例如 Serverless 集群需要的快速启动（冬眠唤醒），从 0 开始启动建新 Pod 肯定来不及，需要有一些预留的资源，又例如使用 Spot Instance 来处理 Compaction 任务，万一某个 Spot Instance 被回收，能否再快速找个机器继续工作，又例如负载均衡和 Service Mesh… 。

虽然 S3 帮你把最难搞的状态问题解决了，但是这些纯计算节点的调度问题是很琐碎的，如果你选择自己造轮子，那么大概率最后你会重新发明一个 K8s，所以不如直接拥抱 在云上，还有一个很大的设计问题：文件系统是一个好抽象吗。

？这个问题来自于在哪层抽象之下屏蔽云的基础设施在 S3 普及之前，各个大型的分布式系统存储系统，尤其是 Google 的 BigTable、Spanner 等都选择了一个分布式文件系统作为底座（我认为这里面有很深的 Plan9 的痕迹，毕竟 Google 内部这些 Infra 大神很多都是从贝尔实验室来的）。

那么问题来了，如果有了 S3，我们还需不需要一层文件系统的抽象？我目前还没有想清楚，我倾向于有，理由仍然是存储的缓存，如果有一层文件系统，在文件系统层能够根据文件的访问热度做进行一层缓存，提升扩容时候的预热速度；另一个好处是基于文件系统，生态工具兼容性会更好，很多 UNIX 的工具能直接复用，运维复杂度降低。

我在 2022 年的 PingCAP DevCon 的 Keynote 中提到了一点：云上的数据库如何与现代的开发者体验融合？这个是一个很有意思的话题，因为数据库那么多年了，几乎还是这个样子，SQL is still the king

但是另一方面现在开发者开发的应用以及使用的工具已经和几十年前大不一样了，作为一个从 UNIX 时代过来的老程序员，看到现在年轻一代的开发者使用的眼花缭乱的先进开发工具和理念，只能感叹一代比一代强，虽然操作数据 SQL 仍然是标准，但是数据库软件能否做更多，去融入这些现代的应用开发体验中？。

Serverless 将成为数据库最终的产品形态我认为云原生的下一个阶段，其本身会越来越自洽，并会逐渐形成全栈的云原生，这种全栈的云原生将会催生 Serverless 的发展Serverless 的本质其实很简单，依旧是帮助开发者更进一步地隐藏基础设施的复杂性。

总结来看，未来几乎所有在云上的软件都会形成一个自洽的 Serverless 生态 Serverless ，很多人认为的 Serverless 是一个技术名词我认为不是，Serverless 更重要的是从用户体验角度定义了什么是更好的云上软件的产品形态。

或者这本来就应该是理所应当的：为什么作为用户需要关心你有几个节点？为什么需要关心内部的参数和配置？为什么我点了启动，你要让我再等半小时？ 这些在我们行业里面过去看起来似乎理所应当的事情，其实仔细想想都觉得挺可笑的，举个例子：假设你去买个车，卖车的先送给你一本发动机维修指南，告诉你读完才能上路，车跑得不快，然后告诉你某个发动机参数需要你调一下，每次启动汽车都要等半小时…这是不是很奇怪？

对于 Serverless 的产品来说，从用户体验来说，最大的意义在于三件事情： 屏蔽掉配置，降低了使用者的心智负担；极其快速的启动时间，这点扩展了使用场景和易用性；Scale-to-Zero，在多数场景中降低了使用的成本（当有明显波峰波谷，且你没法预测的场景），在小规模时甚至可以免费。

有了以上三点，才能很好地将数据库嵌入到其他的应用开发框架中，这是构建更大的生态的基础 除了 Serverless 之外，现代的开发者体验（DX）中还包含很多其他的关键要素，例如： Modern CLI。

：对于开发者来说，CLI 的效率比图形界面高得多，而且更容易通过 Shell 脚本组合其他工具实现自动化云端 - 本地统一的开发 / 调试 / 部署体验：没有人想天天碰服务器，本地能搞定的事情，就不要让人 SSH。

尤其对于云服务来说，如何在云下开发和调试，目前是一个有很多痛点的市场Example Code / Demo / 脚手架：新一代的偏向 PLG 的服务提供商例如：Vercel、Supabase 这一套玩的很溜，想想这也是合理的，对于普通的 CRUD 应用来说，基本的代码框架都是相似的，提供一些快速上手的例子，能够让开发者更快的体会到你的产品价值，也帮助开发者更快的构建他们的应用。

因此，通常而言 Serverless 数据库应该具备如下四点关键特性：按量计费且费用透明在 Serverless 数据库服务形态下，用户仅需为每次事务处理或查询分析所消耗的 CPU、存储、网络带宽、磁盘 I/O 等资源使用量而付费，不用则不产生费用。

这为用户节约了大量成本，尤其是在运行负载不稳定或不可预测的应用程序时此外， Serverless 数据库的计费方式完全透明，用户可以清晰了解资源消耗量，并计算准确的投入产出比，即 ROI极致弹性Serverless 数据库可以跟随业务复杂变化自动匹配所需资源，在很短的时间内大幅扩展应对流量和负载高峰，也可以在没有需求时缩到 0。

从而帮助用户的应用程序总是能拥有合适的资源以保持最佳运行状态，而不用过度配置使用简单Serverless 数据库屏蔽了基础设施的复杂性，用户使用时不用做资源选型和容量预估，也不用再去关心底层的基础设施的管理维护。

用户因此可以从繁琐的资源管理工作中彻底解放出来高可用Serverless 数据库能够在任何计算实例、网络，或者硬件发生故障时，通过多副本以及自动故障切换能力，保障用户的的数据始终可用，并且数据总是正确无误。

听起来很美好，Does it even possible？经过大半年的时间，我们终于把首个原型做出来了，并在 11 月 1 号上线公测，它就是 TiDB Serverless Tier 我自己写了一个小程序，在一个全新的环境下，通过代码启动一个 TiDB 的 Serverless Tier 实例。

在整个过程里，我只是告诉这个程序，要启动一个集群，这个集群叫什么名字，然后把密码一输，20 秒之后可以直接拿一个 MySQL 客户端连上去了，这个时间未来会进一步缩短想象一下，如果缩短到三五秒钟，这会极大地改变开发应用的使用流程和体验。

而且不用关心它的扩展性，即使上线以后，业务流量变得巨大无比的时候，它也能够很好地扩容上去，没有流量的时候，它还能缩回来 它背后其实有很多很多的技术细节，本文就不一一细说了其中我们有一个原则，就是怎么利用好云提供的不同的服务，比如 Spot Instances、S3、EBS、弹性的 Load Balancer。

TiDB 的 Serverless Tier 背后对于云上所有的弹性资源都进行了很好的整合，以及巧妙的调度，提供了一个极致弹性的用户体验这个用户体验比原来的云原生数据库更往前跨越了一步，细节更少，抽象程度更高。

我几乎可以很肯定的说，对于新创的所有数据库公司，如果说前两年你的门票是云原生的话，你今年的门票就变成 Serverless，没有 Serverless 基本上不了牌桌现在，Serverless 数据库也成了国内外各家公有云厂商，以及独立数据库厂商开始争相布局的领域。

如 AWS、Azure、GCP、***、***云，以及 ***、PingCAP、CockroachDB、Snowflake，最近一年来都在加速投入 Serverless 数据库服务2023 年展望：新产品形态、商业模式、研发组织、AI 体验

未来，数据库技术还是有很多事情可以做不过，我个人觉得有一条主线，这条主线就是贴着应用开发者，最后不管是企业级应用还是其他各种应用，这些应用都是程序员写出来的，都是代码开发者开发出来的 在 ChatGPT 出来之前，我一直认为 AI 存在过度炒作的成分，但 ChatGPT 真的让我感到惊喜，让我体会到 AI 的价值，它并非直接取代工程师，而是提升工程师的生产效率。

这类工具与企业内部现有业务的结合将会是接下来非常值得关注的趋势 本质上，行业如何提升应用开发者的效率，这可能是一个大的发展方向，有可能这个主线发展到未来，会发现数据库技术在做很多事情上都不是数据库技术了，比如一个更好用的 Serveless 数据库怎么做？我用一大堆负载均衡或者弹性计算的技术，甚至接下来我在想是不是 SQL 对于应用开发者来说还是太复杂了，有没有更好的离用户更近的数据产品表现形态？TiDB Cloud Serverless Tier 最近推出了一个 AI 工具 Chat2 Query beta 版，它可以让用户用自然语言生成 SQL 去做相应的数据查询，从而让每一个用户都可以以非常容易的方式从数据中获取洞察。

我觉得接下来未来的数据库技术，技术本身不重要，最后的方向是提升每一个应用开发者的幸福指数数据库技术一定会往更简单、更加好用、更加方便地让大家写出新的应用，向加速进入市场的方向去努力 以下面一段作为结尾，列一部分有意思的挑战，虽然肯定不完备，希望能对你有所启发： 。

新的产品形态当不同租户的存储引擎上的数据都在 S3 之后，理论上可以解锁一个更大的基于数据共享和交换的市场（想象一下 Google Docs），又或者在 S3 上 + MVCC 理论上可以实现类似 Git 似的对于数据的版本控制，想象一下 git checkout 的顺滑体验，只是不同的是，你切换的是你的数据库镜像（我知道已经有云上的数据库产品开始探索该种产品形态），这会带来很多新的应用场景和独特的价值。

新的商业模式云是新的计算机，但世界上应该不会只有几台计算机，除了标准的 SaaS 模式外，还有没有可能将 DBaaS 作为一个整体进行输出，这可能又是一种全新的商业模式（尤其是在和一些二线或者私有云合作的时候），此时数据库厂商会变成输出数据库服务产品的厂商（有点绕）。

新的研发组织对于一个数据库厂商来说，过去研发和产品的需求几乎只限于内核开发，但是在做云服务的过程中，你不仅是开发者，还会是运维和运营者，而且开发云服务对于研发人员的技术栈的要求和数据库内核是完全不一样的，其中里面必然涉及巨大的组织变革和人事调整。

数据库的交互体验会被 AI 完全重塑当我们把 Serverless、HTAP、AI 结合在一起时，它们会完全改变我们与数据库互动方式的可能性现在我们已经可以利用 AI 的能力将自然语言转化为标准的 SQL 代码，任何人，即使他不怎么懂 SQL 也可以轻松实现复杂的数据查询分析，让人人都有机会成为数据分析师，这就是未来数据库的样子，而这一天即将到来。

最后，过去一年，我们已经看到中国的很多技术、项目、开发者在全球产生了一定影响力，我也看到了广阔的全球市场在向中国企业招手未来，越来越多来自中国的技术会逐渐走向全球，构建属于自己的全球影响力HTAPServerless

TiDB

版权声明：本文内容由网络用户投稿，版权归原作者所有，本站不拥有其著作权，亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容，请联系我们jiasou666@gmail.com 处理，核实后本网站将在24小时内删除侵权内容。