本文由 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，以及正在减速云转型的数据库巨头 Oracle（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 的状态其实在云上做意义才大，因为 it’s 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、阿里云、腾讯云，以及 MongoDB、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 也能够轻松实现简单的数据查问剖析，让人人都有机会成为数据分析师，这就是将来数据库的样子，而这一天行将到来。
最初，过来一年，咱们曾经看到中国的很多技术、我的项目、开发者在寰球产生了肯定影响力，我也看到了广大的寰球市场在向中国企业招手。将来，越来越多来自中国的技术会逐步走向寰球，构建属于本人的寰球影响力。