{
"componentChunkName": "component---src-templates-blog-blog-detail-tsx",
"path": "/blog/tidb-serverless-is-ga",
"result": {"pageContext":{"blog":{"id":"Blogs_501","title":"TiDB Serverless 正式商用，全托管的云服务带来数据管理和应用程序开发的全新体验","tags":["TiDB Serverless"],"category":{"name":"公司动态"},"summary":"TiDB Serverless 已经正式商用。作为一款完全托管的 DBaaS 服务，TiDB Serverless 提供了一种功能强大、高性价比的数据管理方案，它可以根据你的需求自动扩展，消除了预设集群规模、资源负载平衡和资源闲置造成的麻烦和浪费，赋能全球企业和开发者。","body":"\n\n八年前，我们构建了 TiDB，一个开源分布式关系型数据库。我们的目标是重新定义开发者和企业处理数据的方式，满足不断增长的可扩展性、灵活性和性能需求。从那时起，PingCAP 便致力于为开发者和企业提供快速、灵活和规模化的数据库服务，并提供最优秀的用户体验。\n\n去年 11 月，TiDB Serverless beta 版发布，也标志着我们达到了旅程中的一个重要的里程碑。之后的数月里，我们吸引了数以万计的用户，收集到了宝贵的意见和建议，并不断迭代、优化我们的产品。\n\n今天，我们非常高兴地宣布 TiDB Serverless 已经正式商用。作为一款完全托管的 DBaaS 服务，TiDB Serverless 提供了一种功能强大、高性价比的数据管理方案，它可以根据你的需求自动扩展，消除了预设集群规模、资源负载平衡和资源闲置造成的麻烦和浪费，赋能全球企业和开发者。\n\n## 极大简化数据库操作\n\nTiDB Serverless 重新定义了数据库的操作，使其比以往更简单。通过 TiDB Serverless： \n\n- 例行任务（如配置、管理和维护）将成为过去。\n- 复杂任务（如高可用性配置和扩展）将实现无缝自动化处理。\n- 无停机的自动升级和每日备份，支持基于时间点的恢复（Point-in-Time Recovery, PiTR）。\n- 基于 OpenAI 技术的 TiDB Bot 提供最佳实践建议。\n\n## 自动化弹性伸缩，极低成本\n\nTiDB Serverless 的按需付费机制，保障您只为自己正在使用的资源付费： \n\n- 轻松应对需求峰值，自动进行扩展，同时在闲置时自动缩减资源到零。\n- 不再需要选择服务器大小，无需过度配置和为未使用的资源付费。\n- 设置每月资源限制，避免计划外的费用。\n- 透明的定价模型，详细了解每月账单情况。\n\n## 最大化开发效率\n\n无论是原型设计还是生产阶段，TiDB Serverless 的以下特性都可以帮你提高开发效率： \n\n- 与 MySQL 兼容，无需对代码进行调整。\n- 能够与 MySQL 丰富的工具、ORM 和驱动程序生态系统集成。\n- 同时满足交易和分析的需求（HTAP），实现实时洞察。\n- 利用 AI 增强功能，如 Chat2Query，通过自然语言生成和运行 SQL 查询。\n- 借助 TiDB Cloud Admin API、TiCloud CLI 或 Terraform 等工具实现自动化运维管控。\n\n## 安全合规保障\n\n- TiDB Serverless 将数据安全、隐私和合规性作为首要任务：\n- TiDB Serverless 获得了 SOC 2 Type II 认证，满足安全性、可用性、数据处理完整性和保密性等行业标准。\n- 默认满足 GDPR、HIPAA、PCI DSS 等隐私和合规标准。\n- 访问 Serverless 集群时始终需要 TLS 连接。\n- 基于角色的访问控制保证对数据访问的精确管控。\n- 多因素身份验证增加了额外的安全防护。\n- 全面的日志记录和监控系统，确保系统的可观测性。\n\n## TiDB Serverless 的实际应用\n\n[Chaintool](https://chaintool.ai/) 是一家 Web3 技术公司，构建基础设施以支持区块链交易数据，并利用这些数据开发链上风险管理解决方案。他们在 TiDB Serverless 上部署了他们的链下 API，摆脱了传统数据库解决方案所带来的人工运维挑战，TiDB Serverless 让他们能够专注于构建 Web3 开发者和分析师的数据平台。 \n\n在过去的六个月里，TiDB Serverless 为 Chaintool 提供了许多便利，显著改善了他们的业务运营。这些便利包括： \n\n- 低门槛项目上手和协作：TiDB Serverless 的易用性能让更多合作伙伴快速参与到项目中，极大降低了协作和沟通成本，并确保了敏捷的项目开发。\n- 优化成本：随着公司项目的扩大和业务需求的演变，TiDB Serverless 的按使用量计费显著降低了成本，同时能够根据项目进展，适应敏捷和波动的需求。\n- 面向未来可扩展的数据库：TiDB Serverless 提供了弹性和混合工作负载的处理能力，能够支持 Chaintool 不断增长的数据存储需求，同时也为未来的业务发展做好了准备。\n\nChaintool 的创始人、CEO、CTO Zhang Yi 表示：“在竞争激烈的 Web3 世界中，TiDB Serverless 显著提升了我们产品上市的速度，并降低了成本。它不仅易于使用，而且其内置的行存和列存引擎使我们能够在单个数据库中处理事务和分析工作负载。” \n\nChaintool 计划在不久的将来探索更多 TiDB Serverless 的用例，下一步也有计划使用 TiFlash 的能力。\n\n## 立即体验 TiDB Serverless\n\nPingCAP 始终致力于探索数据管理和应用程序开发的可能性，希望帮助开发者和企业管理者轻松自信地应对不断演变的数字化环境。TiDB Serverless 正式发布是一个重要的里程碑，也是一个全新的开始。您的反馈是我们改进和也创新的动力来源，我们也希望在未来的旅程里与您携手通行，共同打造产品。\n\n[立即体验](https://tidbcloud.com/free-trial?utm_source=website-zh&utm_medium=referral&utm_campaign=blog-tidb-serverless-ga) TiDB Serverless，零成本起步，开启数据管理和应用程序开发的全新体验！","date":"2023-07-27","author":"PingCAP","fillInMethod":"writeDirectly","customUrl":"tidb-serverless-is-ga","file":null,"relatedBlogs":[{"relatedBlog":{"body":"12 月 1 日，以\"去发现，去挑战\"为主题的 PingCAP DevCon 2022 主论坛在线上成功举办，为数万观众带来一场技术盛宴。PingCAP 联合创始人兼 CTO 黄东旭，在大会上分享了 “The Future of Database” 的主题演讲，分享了他对云原生、开发者生产力的理解，介绍了 Serverless HTAP 的意义以及未来的“技术无感化”发展方向。以下为演讲实录，全文约 7000 字。\n\n首先感谢所有用户，用户的使用是支撑 PingCAP 一直进步的最重要动力，每年看到 TiDB 越来越普及，用户越来越多，就感觉肩上的担子又重了。\n\n\n\n在过去一年中，TiDB 有一个最重要的变化——发版节奏和模型发生了变化。今年，TiDB 第一次引入了 LTS 版本，以及形成了以两个月为周期的迭代发版节奏。此外，特别值得一提的是，今年 5 月 TiDB Cloud 正式 GA，去年我提到云的意义在于加速软件的迭代速度，短短大半年时间 **TiDB Cloud 已经进行了超过 34 次迭代，增加了上百个功能特性和改进**。这个迭代速度比 TiDB 内核本身的迭代速度更快，这也印证了之前我对于云的判断。\n\n## 数据库的“第一性原理”\n\n埃隆·马斯克有一个很有名的“第一性原理”，这些年我一直也在思考这个问题，对于一个数据库厂商或者数据库产品经理来说，数据库软件的第一性原理是什么？**对于数据库来说，一个很本质的问题是 developer 到底需要什么样的数据库**。这里说的 developer 并不是指数据库开发者，而是那些真正开发应用的开发者。为什么这么说呢？其实数字化转型也好，各种应用创新也好，其背后的驱动力到最后都是一行一行代码，而这些代码都是开发者写的。对于数据库软件来说，真正的用户其实就是开发者。\n\n\n\n上图是一项关于“在你的组织内部到底是谁在选择 Database”的调查，可以看到排名第一的是架构师、第二是开发者、第三是 DBA，三者加起来达到了超过 80% 的占比。这些人都是广义上的开发者，对于数据库软件来说真正的用户其实就是这些人。\n\n\n\n数据库里另外一个大的趋势是 Cloud。我觉得今年已经不用再强调 Cloud is the future，从 Gartner 的报告可以看出，今年全球企业在 Cloud 上的投入已经超过了私有化数据中心的投入，并且每年的增速都非常快。\n\n\n\n在数据库领域中也有着同样的趋势，上图是云数据库和私有化部署的数据库软件的占比趋势。大家可以看到，2019年时，云上的数据库服务（Database as a Service）还不到传统数据库的一半，但今年几乎接近一样，可以预见明年一定会超过。所以，云是毋庸置疑的趋势，**在未来的数据库产品中，Cloud 一定会变成数据库服务的承载平台**。\n\n## 如何解放开发者的生产力？\n\n这次分享的主题依然是“The Future of Database”，要讲的是数据库的未来会是什么产品形态。谈到这个话题，我的思考习惯是先关注现在数据库到底有哪些痛点，开发者到底在为什么烦恼。\n\n\n\n从这张图可以看出，开发者、程序员、DBA 日常的时间都花在了什么地方。你会发现他们 39% 的时间在做业务创新、在 Coding，41% 的时间在做基础设施维护，如买服务器、部署服务器、运维等等。这其实非常符合一个开发者的日常体感。有时候作为一个程序员，我想要雄心勃勃地做一个新的东西、新的应用时，会发现真正开发那个应用的时间可能只占整个时间的 10%-20% 左右，**大量时间都花费在买服务器、部署数据库、数据的备份恢复、CI/CD 搭建上，而不是在开发应用上面**。\n\n\n\n这张图来自 a16z（美国一个特别著名的投资机构）在 2020 年底出的一份报告，他们提出了一套包治百病的数据架构“Unified Data Infrastructure”。当时看到这个架构的时候，我觉得它确实包含了我们遇到的各种各样的问题，这个架构确实能解决问题。**但另一方面，图中每个框其实都是一套非常复杂的软件**，这个架构的问题是框特别多、特别复杂，而且这些框之间互相的连接会把事情变得更加复杂。想象一下刚才提到的小例子，我在开发一个应用时要花很多时间去处理这些基础设施的问题，在这张图里，刚才这些不爽的体验要再乘十或二十倍，因为这些组件之间的连接会带来更多的复杂性。所以这个架构看起来很美，但实际上我们会花更多的时间去保障系统稳定运行。\n\n综上所述，**当今把开发者拖慢的最核心原因是开发者的生产力**，如果开发者的生产力提高了，业务创新、应用创新的速度就会变得更快。\n\n\n\nOSS Insight 是 PingCAP 自己开发的一个很好玩的 GitHub 数据分析工具，它抓取了 GitHub 上所有的信息和实时的数据，提供一些数据的洞察服务。这样一个看起来很简单、很有意思的小应用，**如果用传统的思路去构建系统，你就会发现要用一大堆不同的技术栈串联在一起才能实现，并且每一个技术栈还有着自身复杂的运维成本**。\n\n过去 20 年我们发明了太多的技术，太多不同的 Database，每一种 Database 都有着自己复杂的概念与运维。作为一个开发者，要想把它用好，就需要把这些东西都学习一遍。业界有一句特别真实的笑话：别发布了，别做新的东西了，我真的学不动了……**这些复杂的概念现在都没有被隐藏起来，反而全都透传给了开发者**。举一个简单的例子，如果你想在云上选择机型，就会发现不同的公有云厂商会有好多机型推荐给你，如 i3.xlarge、i3.2xlarge、i3.4xlarge 等等，这些机型代号背后到底意味着什么？这都是系统架构的复杂性。\n\n更不要说背后的成本，**如果你在云上选错了机型或者选错了服务，就会发现最后的账单和你选了正确的机型或者服务有着天壤之别**。最近很火的 FinOps，说白了就是如何科学地利用云去省钱。这意味着什么呢？意味着就连计费方式以及筛选的策略对于用户来说都是非常复杂的事情，复杂到需要用另外一套工具来去做优化，以帮助用户作出正确的决策。\n\n\n\n**我们再往前看一下，今天的开发者到底是怎么去思考开发应用的？**这里我想分享一个最近特别喜欢的公司——Vercel，是一个非常偏向于开发者开发流程和体验的平台，在它的首页有三个英文单词：Develop（开发）、Preview（预览）和 Ship（上线），这其实就是一个开发者的视角。用过的同学就会知道，在 Vercel 这个平台上，一个应用开发者只需要关注网站怎么做，只需要去写 code。其他的事情，包括发布、部署、CDN、流量全都由 Vercel 帮忙封装好了，开发者只需要将 100% 的时间都放在业务逻辑开发上就可以了。这是一个很好的方向，这意味着应用的开发门槛在降低。**未来，应用开发者对数据库的关注点会从数据库变成 API，甚至在更长远的的未来只需要关注 web 前端开发就好了**。\n\n## 用“抽象”解决复杂性\n\n综上所述，从开发者的角度，或者新一代开发框架的角度来说，开发门槛正在变得越来越低，应用开发者变得越来越多，那数据库、数据技术、数据处理技术栈，怎么解决复杂性带来的矛盾呢？\n\n我觉得解决这个问题的思路可以用一个词来描述——**Abstraction（抽象）**。为什么抽象如此重要？抽象怎么帮我们解决问题？\n\n对于基础软件或者软件开发来说，概念的抽象程度提高，会带来什么样的结果？**第一，架构的复杂性会变得越来越低**。我们想象一下云，原来没有云的情况下你可能还要去考虑一下硬件、网络、磁盘、存储、数据中心的租赁，但有云了之后架构本身的复杂性是降低的，你不需要了解这么多东西，因为云底下的东西已经被隐藏掉了。这意味着作为一个开发者来说，他的心智负担在降低。就像用 Vercel 开发应用的时候你不需要关注 CDN，Vercel 已经解决了 CDN 的问题。心智负担降低意味着开发者能更快地开发出应用，能花更多的时间专注于业务创新，这就是商业的迭代速度。所以为了解决刚才说的矛盾，我们在数据技术上应该进一步去做抽象。\n\n\n\n在聊数据库的 Abstraction 前，我们可以看另外一个例子——**计算能力的抽象**。上面这个二维图示中，竖轴是技术的抽象程度，横轴是商业创新的迭代速度（Go-to-Market Speed），我们用它来看一下刚刚这个理论是不是成立。\n\n图中左下角是 On-Prem，意味着 20 年前要做一个网站，还要关心买服务器、租机房、网络租用等，抽象程度很低，**开发者要花大量时间在这些与业务无关的事情上，这也就意味着迭代速度是慢的**。\n\n后来人们是怎么解决的？**公有云的概念出现了，把刚才那些复杂的硬件、部署、网络等数据中心的复杂性抽象掉了**。你拿到就是一台机器，它到底是不是真实的机器你不用关心。这时，你要再开发一个应用，只需要在公有云上开个账号，把应用部署上去，按月给钱就行了。这比起自己去折腾数据中心来说，迭代速度又快了一步。\n\n**再往上看，云原生的概念出现了**。云原生的核心计算单元是 Container，Container 是更高层次的抽象。在虚拟机时代，你依然要去考虑 VM 挂了怎么办，但是在 Container 世界里，Container 以及底下云的调度器都不用你管，意味着迭代速度更快。\n\n\n\n在数据库的世界里“抽象”是如何去体现的？**抽象程度最低的是云本身的基础设施**，比如你要在云上私有化部署一个数据库，你需要自己去维护 MySQL 或者 VM。这时候你看到的是云的基础设施，它的抽象程度很低。**再往上一层，比如 PingCAP 几年前要基于云提供的基础设施如虚拟机、S3、容器，去开发出一个叫 TiDB 的数据库**。TiDB 提供了 SQL 能力，Scalability 能力，以及低延迟、高可用、分布式事务、HTAP、Geo-partition 等等一大堆数据库内核层面的能力。在这个阶段已经有很多用户说，“哇，TiDB 挺好用的”。\n\n**过去一年中，PingCAP 一直在把这个数据库技术变成一个数据库的云服务，也就是我们在做的 TiDB Cloud**。技术和服务的区别是什么呢？TiDB 技术本身就像一辆车里的发动机，或者一个火箭里的引擎。但是一个发动机跟一辆车肯定不一样，尤其在云上。对于一个在云上想要使用数据库服务的用户来说，他需要数据的导入、数据的导出、备份、智能诊断、多租户各种各样周边的东西，**把它们拼装在一起才是一个服务，而不是给用户一个发动机让你自己拼出一辆车**。\n\n这张图里有一条虚线，虚线之下作为一个数据库开发者或者一个数据库厂商来说，关注点其实是能力或者 feature ，就好比说发动机是不是稳定、是不是快、是不是省油，这些是能力驱动为主的一个抓手，但是在这条虚线之上整个驱动力会变成怎么去提升用户体验。你想要提供服务，就要从用户使用服务的全生命周期去考虑。比如他刚进来注册的环节、绑定信用卡的环节、数据导入的环节、使用、调优、备份的环节，同步到其他数据源的环节，每一个环节都要去考虑，这里面考虑的点就是用户体验，**用户体验是指引这个产品做得更好用的方向**。\n\n## 下一级别的“抽象”是什么？\n\n**“抽象”再往前一步是什么？我们给出的答案是“Serverless”**。一个月前 PingCAP 已经发布了 TiDB 的 Serverless 云服务。如果刚才那个理论是 OK 的，“抽象程度越高，开发的效率越高”，**Serverless 就会变成在云原生之后新的“抽象”**。对于数据库来说 Serverless HTAP 是一个更高级别的“抽象”，它意味着更高的开发效率。\n\n可能大家第一次听到 Serverless HTAP ，这到底是什么东西？意味着什么？\n\n\n\n第一，想象一下如果有这么一个数据库，它的**启动或者创建，你不需要关心任何部署细节**，也不用管有几个节点，而且它是召之即来，挥之即去的，几十秒之内就能准备好，一键就能创建出来；\n\n第二，这个系统虽然看不见底下的基础设施，但是它会**跟着业务的负载变化而自动匹配**。比如说你的吞吐大到一定程度，不用再停下来加服务器，系统会自动进行扩展。当你的业务峰值降下来了，比如说双十一过后业务流量下来了，这个系统还能够自动地缩回来，甚至缩到 0。能缩到 0 其实很重要，在没有业务负载的情况下，系统能变成 0 意味着系统不再收钱，而且当有业务流量再过来的时候它也能在很短的时间内又恢复提供服务；\n\n第三，**HTAP Database**。提供了一栈式的 SQL 能力，这是 HTAP 本身的能力；\n\n第四，**Pay-as-you-go**。有的人可能会说公有云不是也是 Pay-as-you-go 吗？Serverless 跟云有什么区别？我觉得二者当然都是 Pay-as-you-go，但是能不能以一个更细的粒度去提供 Pay-as-you-go 的能力？过去我们其实还是按照服务器、虚拟机这样的资源来去看待一个月多少钱，这个服务能不能粒度更细一些，只收业务流量的钱？尤其是对于偏分析的场景来说，有很多时候我们做大数据分析，比如每天半夜要去跑个报表，可能需要一千个虚拟机算，20 秒钟算完，然后再缩回来。每天可能就凌晨需要这么多 OLAP 的服务器，但是我不可能白天也买这么多服务器，就为了晚上算那一下，能不能更细粒度的 Pay-as-you-go，只算 20 秒的钱非常重要。\n\n第五，也是长期以来被各种硬核数据库开发商忽略的一点，但未来会越来越重要，**一个 Serverless 的 HTAP Database 一定要跟现代的开发者开发应用的过程体验深度整合**。举个例子，比如我们在笔记本上开发应用，现在如果有一个召之即来、挥之即去的数据库，我的开发体验其实是贯穿于整个开发流程里的。所以，过去我们其实一直在把数据库与开发者分开来看。数据库关注性能、稳定性，各种各样特别硬核的跑分，但是未来将是从开发者的角度考虑如何去使用数据库，让这个数据库帮助开发者更快、更流畅地构建应用。我觉得对于 Serverless 数据库来说，很重要的一个课题是从用户角度看，它应该融入到每天的、现代的开发体验中。\n\n## TiDB Serverless Tier\n\n\n\n听起来很美好，Does it even possible？**经过大半年的时间，我们终于把这个东西的第一个原型做出来了，并在 11 月 1 号上线公测，这就是刚才说的 [TiDB Serverless Tier](https://tidbcloud.com/free-trial)**。\n\n我自己写了一个小程序，在一个全新的环境下，通过代码启动一个 TiDB 的 Serverless Tier 实例。在这个过程里，我只是告诉这个程序，要启动一个集群，这个集群叫什么名字，然后把密码一输，20 秒之后可以直接拿一个 MySQL 客户端连上去了，这个时间未来会进一步缩短。想象一下，如果缩短到三五秒钟，这会极大地改变开发应用的使用流程和体验。而且你不用关心它的扩展性，即使上线以后，业务流量变得巨大无比的时候，它也能够很好地扩容上去，没有流量的时候，它还能缩回来。\n\n\n\n当然它背后其实有很多很多的技术细节，本文我们就不一一细说了。其中我们有一个原则，就是怎么利用好云提供的不同的服务，比如 Spot Instances、S3、EBS、弹性的 Load Balancer。TiDB 的 Serverless Tier 背后对于云上所有的弹性资源都进行了很好的整合，以及巧妙的调度，提供了一个极致弹性的用户体验。这个用户体验比原来的云原生数据库更往前跨越了一步，细节更少，抽象程度更高。\n\n\n\n这是系统的设计图，就不展开太多了，给大家展示一下这个东西还是挺厉害的。\n\n\n\n所以，**TL;DR 是存在的，也是有可能被做出来的**。当 TiDB Serverless Tier 上线以后，我们发现它一上线就把整个 TiDB 在云上的 cost 降低了。拿最小集群来说，现在对比今年年初，成本降低到 1/5。而且在可见的未来，这个成本会变得更低；第二就是启动的时间，在今年 3 月份的时候，在云上启动一个新的 TiDB 集群需要 15 分钟，如果自己部署时间可能更长。现在只要 20 秒钟，不远的未来这个时间会缩短到更短。\n\n## 云端 Serverless HTAP 数据库服务，意味着什么？\n\n\n\n第一，**我们一开始花了很长时间去构建了一个稳定的数据库内核**，可以弹性扩展、自动 Failover、ACID Transaction 等非常硬核的基础能力。但这些都是基础能力，这些东西应该隐藏在发动机里。作为一个开车的人，不用关心变速箱里有哪些特性；\n\n第二，**HTAP 能够提供实时的一栈式数据服务**。用户不需要关心什么是 OLAP，什么是 OLTP。一套系统可以支撑所有负载，也不用担心 OLAP 负载影响 OLTP 的正常服务；\n\n第三，基础设施层面，**Serverless 部署的成本变得极低，极致的 Serverless 不用关心任何运维的细节**。你可以通过代码和 open API 控制这些集群的起停。在拥有更大规模的基础设施时，这点是非常重要的。Serverless 在处理更复杂或更大系统的时候，能显著减低复杂性；\n\n第四，**真正的按需计费**。Serverless 能够真正按照资源的消耗量来去计费。对于开发者来说，想用数据库的时候，只要招手它就来，不用的时候，也不用给钱，任何时候去访问它，数据都在那儿，也能对外提供服务。\n\n\n\n**在这样的 Serverless 架构下，我们其实还能解锁更多的能力、更多的可能性**。\n\n举个例子，S3 是 TiDB Serverless Tier 底下重度依赖的云对象存储服务。用过 S3 的肯定都知道它便宜，可用性很高。更重要的一点是数据共享，比如大家都在用 AWS，A 用户用 S3，B 用户部分数据也在 S3 上，比如说我想把我的数据共享给另外一个用户的时候，既然都在 S3 上，那共享就变得很简单。以前在私有环境下，你还需要把数据下载出来拷给他，再上传进去，然后才能做分析。如果是在数据量比较大的情况下，这几乎是不可想象的。这种新架构的**一种可能性就是真正能够做到 Data Sharing**，当然这里面肯定还涉及到包括隐私计算，各种各样的安全性问题。但从技术底层来说，这种产品形态并非不可能了。\n\n另一种场景，比如说我想做一个区块链的数据分析应用，但做这样的应用，第一步你得把数据准备好。区块链的数据其实也不小，经常是大几百 GB 或几个 TB 的数据。但如果在 S3 上有一个公共的数据集已经准备好了，那**在云上 Serverless 用户只需要在启动的时候，加载这部分数据就好了**。这些能力在云下是根本不可能完成的任务。\n\n\n\n这些能力具备后，数据库的商业模式会变成什么样子？在去年的 DevCon 上，我提出了一个猜想，“数据库作为一个软件形态本身会消亡，而数据库的平台化、微服务化会取代原来的数据库软件形式”。这个理论正在变成现实，今天，我们可以看到几乎所有的数据库厂商，都在云上提供服务。\n\n## 更进一步\n\n未来再往前一步，会发展成什么样子？\n\n**Serverless 其实是云上 Database Service 更进一步产品形态的体现**。现在我可能还需要去关注买多少个数据库节点，买多少个集群，但是在未来，真正从开发者的角度来说，他所关心的应该只有数据操作的 API ，这一层才是离业务更近的东西。另一方面，**当 Serverless 在云上被提供后，数据共享、交换就变成了一个很自然或者很简单的事情，那时候我觉得会出现一个叫做 Data market 的新商业模式**。\n\n记得我在上大学学数据库课程的时候，我的老师告诉我，这个东西很简单，你只要会写 SQL 就 OK 了。但我工作以后，发现还有 OLTP、OLAP、时序数据库、图数据库，以及各种各样稀奇古怪的数据库，你得学习一大堆东西，这些东西里面有无数的细节。\n\n**我们想把它做得很简单，把开发者的体验带回从前**。数据库本来就应该是很简单的东西，我们应该花更多的时间关注于业务的创新、关注于真正重要的事情，这些复杂的东西，就让它简单起来好了。\n\n未来真正重要的东西是什么？**是流畅的开发体验。这就是我们终极的前进方向**，也是作为一个基础软件提供商的担当。虽然前面说了这么多很技术的东西，但其实 Serverless 很简单，现在它已经变得触手可及，大家可以通过 TiDB Cloud 就可以立刻体验它。","author":"黄东旭","category":2,"customUrl":"frictionless-developer-experience-with-the-serverless-htap-database","fillInMethod":"writeDirectly","id":440,"summary":"12 月 1 日，以\"去发现，去挑战\"为主题的 PingCAP DevCon 2022 主论坛在线上成功举办，为数万观众带来一场技术盛宴。PingCAP 联合创始人兼 CTO 黄东旭，在大会上分享了 “The Future of Database”的主题演讲，分享了他对云原生、开发者生产力的理解，介绍了 Serverless HTAP 的意义以及未来的”技术无感化“发展方向。","tags":["HTAP","Serverless"],"title":"黄东旭：开发者的“技术无感化”时代，从 Serverless HTAP 数据库开始 | PingCAP DevCon 2022"}},{"relatedBlog":{"body":"> 本文基于 TiDB Cloud 生态服务团队负责人张翔在 PingCAP DevCon 2022 的演讲内容整理而成。\n\n\n数据库不是单一软件，而是一个生态体系。成为一款好用的数据库，除了产品自身的能力外，繁荣的技术生态体系也至关重要，既可以提升使用体验，又可以降低使用门槛。\n\nPingCAP 在 2022 年 11 月 1 日正式发布了 TiDB Cloud Serverless Tier，本次分享在介绍 Serverless Tier 的技术细节之余，全面解析 TiDB 的技术生态全景和在生态构建中所做的努力。阅读本文，了解有关 Serverless 的更多信息，以及 PingCAP 在技术领域的最新进展。 \n\n## 云时代开发者面临的机遇和挑战\n\n现在云已经不再是一个新鲜的事物，我们已经处在云的时代，与之前相比，云时代的开发者面临着与之前不同的机遇和挑战。在云时代，我们有着新的技术设施，我这里举几个例子，每个云厂商都会提供块存储服务、对象存储服务和弹性计算服务。块存储服务有高吞吐、低时延和高持久的特性。对象存储服务，比如 AWS 的 S3、国内阿里云的 OSS，提供了低成本的海量存储空间，并且这些存储还有着超高的可用性，甚至可以跨地域复制来进行容灾。而弹性计算服务，可以给我们提供多种规格的计算实力，而且还提供了不同的计费模式，当然，根据用户的诉求进行弹性伸缩，也是一个基本的能力。\n\n\n\n有了新的基础设施，当然也有新的挑战。云厂商给我们提供了许多的云服务，并且云的初衷之一，就是让使用者可以减少很多的运维工作。但是如果你现在深度地使用云，仍然需要运维大量的云上基础设施。这些运维工作使得我们开发者的精力被分散，没法完全专注于业务本身。除了运维工作之外，如何使用好云也是一门学问，前不久我刚刚参加了 AWS 的架构师培训，其实如何多快好省地用好云，不是一件简单的事儿。云服务的使用者，很容易就会造成云上资源的浪费，产生不必要的高额费用，特别是在现在许多的云服务，仍然是按时间来收费的情况下。对于有多套环境需求的场景，比如说公司内部有多个团队，不同的业务有各自的环境诉求，或者在 CICD 的场景下，我们可能会有 preview、stage、product 的多套环境需求，购买多套的云服务会产生高额的费用，但是共享一套云服务则可能会产生资源的竞争，甚至出现测试环境影响生产业务的情况。云上的服务，比如说云上的数据库服务，现在的使用方式仍然是提前规划容量，然后始终按照购买的时候的容量进行工作和计费，如果后期需要调整，仍然需要人工介入，手动去进行扩缩容。\n\n\n\n这个是我们目前在使用云的时候，遇到的一些挑战。那么为了解决这些挑战，PingCAP 推出了 TiDB Cloud Serverless Tier。Serverless Tier 是世界上首款的 Serverless HTAP 数据库，PingCAP 推出它，希望能够帮助开发者解决刚才所说的那些挑战，成为云时代的新的 HTAP 数据库解决方案。TiDB Cloud Serverless Tier 目前是一个 Beta 的状态。下面，我就给大家介绍一下 TiDB Cloud Serverless Tier。\n\n## TiDB Cloud Serverless Tier(Beta) 世界上首款 Serverless HTAP 数据库\n\n当然在之前，我们还是先来看一下传统的TiDB集群。这是一个经典的 TiDB 集群架构，可以看到这是一个非常典型的分层架构，计算层是 TiDB Server，每个 TiDB Server 都是一个无状态的计算节点，可以非常容易的进行横向扩容，存储层是 TiKV 和 TiFlash。TiKV 是我们的分布式行存储引擎，TiFlash 是列存储引擎，整个存储层通过分布式协议实现了一致分布式存储。在计算层和存储层之外，我们还有一个调度单元 PD，这里存储了整个 TiDB 集群的元信息。在这样的一个架构下面， TiDB 已经有了很好的表现。比如 TiDB 有着非常好的扩展性，无论是计算还是存储，能力都可以随节点数线性扩展。\n\n\n\nTiDB 已经在生产场景经历了数百 TB 规模的数据和百万级 QPS 的流量的考验。TiDB 还有着非常好的弹性，系统规模可以随着业务的需求进行伸缩。而且伸缩是完全在线进行的，不会影响已有的数据和请求。同时，对于系统中的热点，TiDB 也有能力自动发现，自动调度。TiDB 也有着非常好的容灾和高可用的能力，如果节点出现故障，上面的数据可以自动的进行转移，并且配合 PingCAP 推出的 TiCDC 工具，还能够做到实时的 CDC 同步，实现异地容灾。\n\n\n\n但是这样的一个经典架构在云的时代，面对着完全不同的基础设施，存在一些问题。第一，share-nothing，刚才我们提到云厂商提供的基础设施，无论是块存储，还是对象存储，天然就有着高可用，高持久的特性，云厂商已经帮我们做了数据复制，但是 TiKV，TiDB 的存储层，仍然做的自己的数据复制。这在云上其实是多余的，数据的复制不仅仅是存储资源的浪费，同时还需要消耗大量的带宽，在云上，网络也是会造成非常高额的费用。第二，存储层状态重。这是因为每个存储节点，其实都存储着一些数据的副本，扩容转移一个故障节点都需要对这些副本进行同步，导致横向扩展的速度仍然不够快，也进一步导致难以利用云厂商提供的竞价实例，从而能够进一步的去降低成本。第三，TiDB 之前是一个非常经典的计算、存储、调度分离的架构。但是在云时代，这样划分的颗粒度仍然过大，每一个节点承担的责任过多，导致 TiDB 整体的弹性仍然不够，其实我们可以在云上，将更多的功能拆分出来形成单独的微服务，这些微服务可以独立的去进行扩容和部署，甚至这些微服务可以被多个集群去共享。如果拆分出更多的微服务，TiDB 集群整体的弹性会进一步上升。\n\n\n\n基于这些问题，其实 PingCAP 做了很多的努力，也都做了相应的改进，大家可以看到这是现在 TiDB Cloud Serverless Tier 的一个新架构。首先在存储层开发了 Cloud Storage Engine 一个新的存储引擎，图中 Shared Storage Layer 和 Shared Storage Pool 这两层组合起来就是新的 Cloud Storage Engine。现在新的存储引擎融合使用了云上的块存储和对象存储，并且消除了原来存储层冗余的数据复制，彻底的解决了之前所说的 share-nothing 和状态重的问题。这样的改造使得存储层的节点扩展非常容易，而且非常迅速，而且大幅度地降低了成本。\n\n\n\n在计算层我们进一步地拆分了 TiFlash，TiFlash 现在它的计算存储已经可以去分离，TiFlash 的计算部分可以像 TiDB Server 一样，作为一个独立的组件去进行管理，去扩容。第二，我们引入了新的一层，叫做 Gateway。Gateway 代替了 TiDB Server 与用户去进行交互，它负责诸如连接管理、唤醒节点，这样的功能。它的出现使得我们所说的多租户成为一个可能。第三，我们池化了计算节点，在图上右边的部分，有多个 TiDB 和 TiFlash。我们将计算节点进行了池化，这样的设计进一步降低了计算层的成本，以及提升了计算节点唤醒的速度。计算层和存储层的改动，使得 TiDB Cloud Serverless Tier 支持了多租户。现在一套 TiDB Cloud Serverless Tier 集群，可以支持多个租户，每个租户都是完全隔离的。在用户看来，他们拥有的就是一套独立的 TiDB 集群。\n\n最后，我们还拆分了一些相对独立的功能，做成微服务，比如数据压缩服务，降低了计算节点以及存储节点的复杂性，提升了 TiDB Cloud Serverless Tier 的整体的弹性，后续我们还会继续对更多的微服务进行拆分。\n\n\n\n做完相应的改进，新的架构解决了之前所说的传统架构在云上的问题，更好地适应了云上的基础设施。这边总结一下，一是推出了 Cloud Storage Engine，可以融合地使用块存储和对象存储，并且消除了多余的复制，解决了两类问题，一是冗余的复制，二是高额的网络费用。第二，拆分出了更多的微服务，更好地使用了云上的弹性算力。整体的改动使得 TiDB Cloud 可以支持多租户。\n\n技术上的努力使得 TiDB Cloud Serverless Tier 拥有了非常新颖的能力。TiDB Cloud Serverless Tier 拥有全部的 TiDB 的 HTAP 能力，是世界上第一款 Serverless HTAP 数据库。我们优化了 TiFlash 的架构，使其更好地适应了云上多租户的场景。从刚才介绍的 TiDB Cloud Serverless Tier 的架构上可以看到，我们对计算节点进行了池化，多租户也共享了存储。所以，TiDB Cloud Serverless Tier 目前可以做到秒级创建一个 TiDB 集群，并且如果你长时间不使用，再次连接的时候也仅需数百毫秒的时间就可以恢复完整的集群。这个操作对于用户来说，是完全透明的，用户甚至感知不到。未来，我们会进一步优化这个时间，集群创建时间会持续缩短，唤醒时间也会从数百毫秒缩短到数十毫秒。\n\n作为一款真正的 Serverless 云数据库，当然，TiDB Cloud Serverless Tier 是完全无需用户去运维的。在使用方式上，不需要像传统的云数据库那样，提前去规划容量，在需要的时候进行扩缩容，TiDB Cloud Serverless Tier 会根据流量自动地进行伸缩，无需任何手动的操作。具备了这么强大的能力，TiDB Cloud Serverless Tier 的计费方式也是真正的按使用量付费，用户只需要为自己真正使用的资源进行付费，不使用，即使这些集群仍然在运行当中，你也无需支付任何的费用，这也是 TiDB Cloud Serverless Tier 区别于传统云数据库甚至于其他 Serverless 数据库的不同之处，这些数据库即使你不使用，但只要集群被创建出来，仍然会按照创建时的规格进行收费，这其实会造成极大的资源浪费。\n\n同时 TiDB Cloud 是支持多云厂商的，Serverless Tier 也将会继承这一点。目前 TiDB Cloud Serverless Tier 仅支持在 AWS 上创建，但未来一定会支持更多的云厂商，同时 Serverless Tier 还支持多个区域，满足用户时延和数据存储区域选择的诉求。\n\n\n\n讲了这么多，接下来我们来展示一个 Demo，这个 Demo 就是我们从无到有来创建一个 TiDB Cloud Serverless Tier 集群，这个其实也是基本上是所有用户唯一需要与 TiDB Cloud Serverless Tier 打交道的一个动作，因为刚才我们说了，一旦创建之后其实你不需要去运维，你也不需要去进行手动扩缩容，TiDB Cloud Serverless Tier 会根据你的流量自动进行扩缩容，我们开始看一下集群创建的过程。\n\n\nDemo 视频\n\n我们只需要点击创建，如果你需要可以选择名字以及供应商以及 region，这里我们都是使用默认的。然后就进入了创建的一个过程，可以看到大概在 20 秒的时候整个集群其实就已经从 creating 的状态变成了 avaliable 的状态，TiDB Cloud Serverless Tier 现在整个创建时间大概就是在 20 秒左右，可能会上下有一定波动，基本是在这样一个量级。只需要 20 秒你就可以拥有一个完全工作的 HTAP 云数据库，并且后续不需要你进行任何操作以及与它有任何运维上的交互。\n\n\n\n希望经过我们的努力，TiDB Cloud Serverless Tier 可以成为一个服务于每个人的 HTAP 数据库，TiDB Cloud Serverless Tier 现在拥有了完整的 HTAP 能力，可以处理复杂的工作负载，并且真正地按使用量付费，对于任何人都只需要为自己使用的计算资源和存储资源付费，不存在资源浪费的情况，具有非常高的性价比。对于个人开发者，TiDB Cloud Serverless Tier 每个月其实都提供了一定量免费的 Quota，只要不超过这个 Quota，对于个人开发者而言，TiDB Cloud Serverless Tier 就是一个完全免费的触手可及的 HTAP 数据库，对于 Startup 来说，TiDB Cloud Serverless Tier 可以跟随业务增长自动进行扩容，而且这个扩容完全是自动的，不需要手动介入。Startup 可以专注于他的业务本身去发展自己的业务，不需要为数据基础设施去操心。对于大公司而言，因为 TiDB Cloud Serverless Tier 超高的性价比以及非常迅速的创建恢复时间，使得云上资源不再成为一个限制，每个部门、每个环境都可以拥有自己独立的数据库，未来我们还会推出 data branching 更好地帮助企业客户，当然如果公司有跨云部署的诉求，TiDB Cloud Serverless Tier 也是一个非常完美的选择。\n\n## 数据库不是单一软件，而是一个生态体系，除了产品自身的能力，繁荣的技术生态体系也至关重要\n\n当然，对于任何一个数据库的使用者不可能仅仅与数据库软件本身打交道，同时需要使用大量的数据库生态软件，TiDB Cloud Serverless Tier 拥有非常丰富的生态，接下来我们就来看一下 TiDB 的生态。数据库不是单一软件，而是一个生态体系，除了产品自身的能力，繁荣的技术生态体系也至关重要。TiDB 从出生起就非常重视生态，所以选择了与 MySQL 兼容，并且在这个上面做了许多努力。\n\n因为 TiDB 是 100% 兼容 MySQL 协议的，所以 TiDB 与所有的主流语言都是兼容的，比如 Go、Ruby、Java 、Python、JavaScript 等等，还有更多。TiDB 兼容的远远不只这些语言，这里列了一些比较流行的语言，只要一个语言拥有 MySQL driver，它就可以使用 TiDB，使用 TiDB Cloud Serverless Tier，不管这个语言多么小众。\n\n\n\n在语言之上，TiDB 还与基本上所有的流行的 ORM 框架兼容，与语言的 driver 不同，除了协议层的兼容之外，ORM 往往在功能上对 MySQL 的兼容性有着更高的要求，TiDB 的一些扩展能力也需要去进行补齐。TiDB 在这个方面做了很多努力，首先针对一些 ORM 开发了自己的插件，比如对于 django 和HIBERNATE，我们开发了django-tidb 和 hibernate-tidb 插件。TiDB 也在产品本身的 MySQL 兼容性的能力上做了很多增强，比如，可能在应用中我们可以不用，但是对于许多 ORM 框架都非常重要的两个功能 savepoint 和外键。这两个功能对于很多的 ORM 框架来说都非常重要，很多 ORM 框架对他的依赖都非常重。在最近两个 TiDB 的版本中发布了savepoint 功能和实验版本的外键功能，这使得 TiDB 进一步提升了与许多 ORM 框架的兼容性。\n\n\n\n除了语言的 driver 和 ORM 框架之外，TiDB 以及 TiDB Cloud 还可以集成许多流行的平台，我们这里罗列了一些主要的，比如在数据处理领域，TiDB 可以与 Spark、Flink、Databricks 这些流行的大数据处理框架以及平台结合使用，来构建企业的 ETL pipeline，形成统一的数据处理平台。同时除了传统的 ELT 平台，TiDB 还可以与海外非常流行的 modern data stack 体系进行集成，我们给 Airbyte 贡献了 tidb-source-connector 和 tidb-destination-connector，开发了 dbt-tidb adapter，使得 TiDB、TiDB cloud 可以完美地与 Airbyte、dbt 进行集成。\n\n当然 TiDB 还支持类似于 Metabase 这样的 BI 平台，分析 TiDB 中存储的数据。在 CDC 的领域 TiCDC 支持了 avro 格式以及 kafka sink，使得 TiCDC 可以支持将数据导出到 confluent 平台，同时我们还测试了与 arcion 平台的兼容性，可以使用 arcion 平台来做 TiDB 或者 TiDB Cloud 的 CDC。\n\n\n\nTiDB 和 TiDB Cloud 很早就支持了使用 prometheus 和 grafana 作为监控平台，我们还支持将监控的 metrics 导出到 datadog 平台，还可以实现与 Serverless 部署平台 Vercel、Netlify 的集成，以及与 no-code workflow automation 平台，像 zapier、n8n 的集成，以及与 IaC 工具 Terraform 的集成等等。接下来深入到一些领域来仔细看下。\n\n首先来看 modern data stack 领域也就是我们所说的 ELT pipeline，注意，这里不是传统的 ETL pipeline，是 ELT pipeline。首先介绍一下 Airbyte 和 dbt，Airbyte 是一个 data pipeline 平台，它可以连接数百种数据源和数据汇，将数据源中的数据导出到数据汇中，然后在数据汇中对数据进行整理。基于此，用户可以通过 Airbyte 实现任意的数据迁移，它的口号就是 data from any source to any destination。dbt 是一个 data transformation 工具，借助 dbt 用户可以非常灵活地在数据库或者数据仓库中操作数据，进行数据变换。结合使用 Airbyte、dbt 和 TiDB Cloud，用户可以将任意数据源中的数据，比如在 salesforce 中的 CRM 数据，google sheets 中的表格数据，甚至是像 Instagram 这样 2C 应用中的企业运营数据导入到 TiDB Cloud 中。有了数据，我们可以利用 BI 工具进行数据分析，因为 TiDB 以及 TiDB Cloud Serverless Tier 是一个 HTAP 数据库，在面对分析型负载的时候，有着更好的表现。甚至，如果说用户有数据归档的诉求，可以继续将 TiDB 作为 Airbyte 的数据源，将数据导入到像 Snowflake、Databricks、Google Big Query 这样的数据仓库或者说数据湖中去。\n\n\n\n总的来说，用户如果结合使用 TiDB Cloud、Airbyte 和 dbt 建立一条 ELT data pipeline，一是可以使自己的数据设施 all in Cloud，整条流水线都可以拥有非常好的弹性，可以满足业务增长的诉求。同时云上的基础设施拥有很高的性价比，可以降低数据基础设施的成本，而且因为 all in Cloud，你无需运维，降低了数据集成的技术、费用门槛。二是可以加速企业内业务数据的流动，Airbyte 拥有上百种的数据连接器，用户可以直接去使用，无需自己设计、开发，从而企业内的数据分析师可以更快地进行数据分析，帮助企业发现新的商业机会，而不是把精力浪费在基础设施的重复建设当中。\n\n接下来看 Vercel，Vercel 是海外领先的前端部署平台。使用 Vercel 开发者可以非常迅速地将自己的 web 应用进行部署、分发给全球的访问者，在这个过程当中 Vercel 还可以加入到开发者的 CICD 流程当中，使开发者可以轻松地预览效果。同时借助 Vercel 遍布全球的边端网络，访问者可以以极低的时延访问 web 应用，获得极佳的用户体验。\n\n\n\nVercel 本身作为一个 Serverless Frontend Infrastructure，它不具备持久化数据存储的能力，这也就意味着如果仅仅使用 Vercel 的能力，没办法去开发一个复杂的 web 应用。所以我们可以结合 Vercel 和TiDB Cloud Serverless Tier，从而获得一套完整的 web 开发的 Fullstack Serverless Infrastructure，和前面的 all in Cloud 的 data pipeline 一样，这套 Web App Develop Infrastructure 也是 all in Cloud，用户无需运维，基础设施可以自动扩展，并且具有很高的性价比。\n\n为了让用户更好地使用 Vercel 和 TiDB Cloud Serverless Tier，我们开发了 TiDB Cloud Vercel Integration ，你可以在 Vercel 的 Integration 市场中找到它，通过这个 integration，只需要简单的几次点击就可以连接 TiDB Cloud Serverless Tier 集群和 Vercel 项目。同时我们还开发了 TiDB Cloud Starter 模板，这个模板可以让用户通过几次点击和几分钟的等待，就从无到有地构建一个全球可访问的 web 应用。以下是一个简单的 demo 让大家来体验这套 Fullstack Serverless Infrastructure。\n\n\nVercel Demo 视频\n\n> 这是 Vercel 的 template 列表，先找到我们的 TiDB Cloud Starter 模板，进入模板的详情页，点击 deploy 进到一个流程页。首先因为这是一个模板，所以我们要基于这个模板来创建一个我们自己应用的代码仓库，这里选择 starter，你只要简单的一次点击就可以。 \n> 在这个过程当中集成了 TiDB Cloud Vercel Integration，这个页面就是 integration 的页面。这里选择我们想要的 Vercel 项目以及想要的 TiDB Cloud Serverless Tier 的集群，选择之后点击 integrate，这个 integrate 的过程就结束了。到这里我们需要操作的过程已经完全结束了，现在处在等待 Vercel 帮你构建项目以及部署项目的一个阶段。大家可以看到，创建我们自己的代码仓库点击了一次，进行 integrate 点击了大概一到两次，我们就完成了所有的操作。 \n> 接下来稍微等待一下，大家可以看到现在大概过了两分钟，整个部署和构建过程就完成了。我们到 Vercel 项目的详情页去点击 visit，可以看到这时候这里展示的页面就是通过模板构建出来的一个项目的主页，大家可以看到这上面的 URL 是一个所有人都可以访问的 URL，现在这个项目已经对全球可以访问了。任何人在地球上的任何角落现在都可以来访问 bookstore 这个项目，整个的耗时也就大概两三分钟。这个项目前端整个的代码应用逻辑是部署在 Vercel 的 Serverless 的架构上面，后端数据存储是存储在 TiDB Cloud Serverless Tier 集群中。 \n\n我们进入下一个生态 Terraform，Terraform 是业界默认的跨云 IaC 工具，使用 Terraform 可以使用代码来管理云基础设施，将它集成到我们的 CICD 流程当中，我们在前不久开发了 TiDB Cloud Terraform Provider，使得用户可以通过 Terraform 来管理 TiDB Cloud 的资源。像图上展示的，我们可以通过这样的一个 Terraform 文件来创建一个 TiDB Cloud Serverless Tier 集群。Terraform Core 会解析这个文件，将 TiDB Cloud 资源的相关定义都发给我们开发的 TiDB Cloud Terraform Provider，TiDB Cloud Provider 会调用 TiDB Cloud Go SDK 来操作 TiDB Cloud 的资源。PingCAP 已经和 HashiCorp 成为了技术合作伙伴，TiDB Cloud Terraform Provider 也已经是 HashiCorp 认证的 Partner Provider，欢迎大家使用 Terraform 来操作 TiDB Cloud 的资源。\n\n\n\n## 展望未来\n\n最后，我们一起展望一下未来，TiDB Cloud Serverless Tier 才刚刚发布，我们仍然有很长的路要走。\n\n目前因为刚刚推出，Serverless Tier 还没有向用户开放诸如像备份、恢复、监控、报警这样的能力，我们很快就会添加这些能力并对用户进行开放。我们还会开发 PiTR 和 Branching 这些功能，方便用户进行数据共享，将数据库纳入CICD。我们还会进一步地去降低创建时间和成本，期望 Serverless Tier 集群的创建时间能从现在的 20 秒降低到 5 秒，唤醒时间从数百毫秒降低到数十毫秒。后续会推出 Data API，Data API 是通过 RESTful API 的形式提供数据库的 CRUD 能力，未来除了 RESTful 之外还可能推出 GraphQL API。通过 Data API 希望 Serverless Tier 可以更好地与 Serverless 生态结合，服务边缘请求。现在很多的 Serverless 的部署平台加速从中心化的托管能力向边缘进行扩张。当我们使用边缘的一些托管 runtime 是根本无法发出像传统的 TCP 请求的，所以 Data API 的推出可以让 Serverless Tier 更好地与这些平台进行结合。\n\n\n\n在生态方面，我们会进一步提升 MySQL 兼容性，对接更多平台，给用户提供更多选择。PingCAP 始终坚持开源开放的路线，TiDB 社区从诞生开始就开放并包，我们期望大家加入，共建 TiDB 的繁荣生态。","author":"张翔","category":1,"customUrl":"tidb-serverless-and-technology-ecology-overview","fillInMethod":"writeDirectly","id":466,"summary":"本次分享在介绍 Serverless Tier 的技术细节之余，全面解析了 TiDB 的技术生态全景和在生态构建中所做的努力。阅读本文，了解有关 Serverless 的更多信息，以及 PingCAP 在技术领域的最新进展。","tags":["TiDB","Serverless"],"title":"TiDB Serverless 和技术生态全景"}},{"relatedBlog":{"body":"## 导读\n\n在 PingCAP 用户峰会 2023 上，PingCAP 联合创始人兼 CTO 黄东旭分享了“The Future of Database”为主题的演讲，介绍了 TiDB Serverless 作为未来一代数据库的核心设计理念。黄东旭通过分享个人经历和示例，强调了数据库的服务化而非服务化数据库的重要性，并展示了 TiDB Serverless 架构的创新之处，同时探讨了 TiDB Serverless 对于中国用户的价值。以下为分享实录。\n\n作为今天上午的最后一个话题，相信大家已经感受到今天我们分享的最核心逻辑，跟刚才刘奇分享的我们部署一代、研发一代相承接，到我这部分就是未来的一代：预研一代。 \n\n因为今天会场有很多熟悉的老朋友，看到我这个标题肯定会心一笑，我每次在大会上的演讲都是这个题目：The Future of Database。选择这个主题一是我发现每次讲未来的东西都有东西可以讲；另外一点，很多老朋友发现我去年总是不时消失一段时间，怀疑我去闭关修炼了，我也跟大家汇报一下东旭去哪儿了。 \n\n**Demo：我花了多长时间构建我自己的 OSSInsight Lite**\n\n\n\n分享之前给大家看看，刘奇的分享里面的这一页，把我 GitHub 个人数据分析的服务截图放上去了，这个小 demo 是我个人的挑战，我能不能完全做到不写代码，不去买服务器，完全用现代化的在线的云上的应用做一个我自己的数据服务。\n\n\n\n在这个小的视频里边，我几乎全程只用了鼠标来操作，我想分享的点并不是让大家去学习这些技术，而是想让大家稍微体验一下现代的开发者构建应用的方式已经完全不同——门槛越来越低。 \n\n我经常会有一些天马行空的想法，比如我会想如果要给全世界的开发者都提供免费的数据库，这个成本得有多大？以现在的技术肯定支撑不了。那如果要做这么个东西的话，我们可能需要重新去思考数据库本身的一些最基础的东西。 \n\n## 一个人人可用的数据库服务有怎样的技术架构？\n\n\n\n这是一些数据库厂商会说的老生常谈：扩展性、稳定性、用户线性的扩缩容、节省成本、多租户、云原生。 \n\n但是刚才我说的那些新的需求或者面向未来的数据库，可能对每一项都会有更高的要求。比如你的系统已经具备了一定的扩展性和稳定性，但更重要的是你能不能给用户一个稳定的性能的预期，我经常说一句话，稳定的慢比不稳定的快其实更好，可预测性对系统和底层的架构提出了更高的要求；第二就是现在几乎每个分布式数据库都支持弹性扩容，而更高的要求可能是，在做这些扩缩容的复杂操作的时候，开发者、DBA 都不需要去费心，数据库的扩缩容对业务来讲是完全无感的，体验非常顺滑；成本层面，我们再把成本压缩到极限——我能不能，不用的时候就不花钱？开源软件的分发上、下载不要钱，但是运行软件的服务器要花钱，现在我们再往前想一步，——数据库、服务器零成本的起步能不能支持；多租户上，我们过去要去强调互相的隔离，但是如果为了实现大规模的海量的免费的用户、中小型的敏捷的业务，不仅要强调隔离，还得强调资源的高效利用和共享；云原生是老生常谈，做到云中立就是进一步的目标。 \n\n\n\n我这边挑一个简单的例子，就从最近发布的多租户能力说起。如果把租户的规模从私有化部署的几十几百个，扩大到十万个、一百万个、一千万个甚至一亿个，平台如何去支撑这么大的租户数量，它需要哪些基础的能力，我们是怎么思考的？第一老生常谈，多租户一定要隔离；第二是刚才唐刘稍微讲了一下我们现在在研发的东西：资源管控，我们必须得实现一套很好的机制能够让海量用户更高效地利用和共享底层系统的资源，才能达到很低的成本；第三就是能区分，每一个用户在使用的体验上都必须能够感受到自己是在拥有整个数据库的。 \n\n\n\n之前有人问我 TiDB 支持多租户、多应用这种模式吗，我当时一直都是比较保守，通过几个大版本的迭代，我现在可以负责任的说，TiDB 要去实现现代的多租户，基础的能力都已经满足了。 \n\n## TiDB Serverless：未来数据库理念的“概念车” \n\n我们回到最开始的话题：如果我们要给全世界的开发者提供数据库该咋做？今天我就给大家说一下背后的概念车，把 TiDB Serverless 引擎盖掀起来大家看一看。 \n\n\n\n今天无数次讲到了 TiDB 的经典架构，然而如果把 TiDB 这个经典架构搬到云上，想实现“人人可用”这个目标，仅从成本上考虑，PingCAP 就得赔死了。 \n\n\n\n所以重新设计 TiDB Serverless 的时候，我当时定下了几个规范或者开发的哲学，其中最重要的一条就是我们应该做的是数据库的服务化，而不是服务化的数据库。 \n\n传统意义上来说我们要做云数据库，大家第一直观感觉，底下做个云管平台，每个租户部署一套 TiDB，把自动化的管控做完，这不就可以了吗？但是 TiDB Serverless 在这个方面，我们选择重新去思考一些非常基础的东西，刚才做云上运维 TiDB 的思路是行不通的，如果要做这么大规模这么新的东西的话，而且应该当做一个完整的服务去设计，而不是把它当做一个数据库去设计。 \n\n八年前一开始设计 TiDB 的时候，我看到的东西就是一台台具体的服务器，我看到的是 CPU、内存、磁盘，基于这些东西我们构造了 TiDB。但是如果我们现在在云上构建 Serverless 这个系统，拿到的是一张白纸，我今天重新再开始去设计这个系统的时候，我看到的已经不是 CPU、磁盘机器这样的东西了，我看到的东西是云上给我的服务，EC2、虚拟机，我看到的是对象存储，我甚至可以看到云厂商的 RDS，我能不能拿 RDS 作为系统的一部分，所以在新的云原生的工程哲学里边必须有一条能够充分利用云的基础设施，这也是我们能把成本推到如此极限的一个核心的思想。 \n\n\n\n掀开 TiDB Serverless 的引擎盖，大概有三个新的东西，第一个换了新的云原生的引擎 CSE（Cloud-native Storage Engine），非常朴素的名字。第二是终于在 TiDB 引入了逻辑上的 Key Space，第三就是 Resource Control 以及 RU 的概念，从上到下做全局流控。 \n\n\n\n这是 CSE 整体的架构，核心就一点，它是一个极致的成本考虑下，极致的多租户背景下的新一代云上 OLTP 存储引擎。本质来说即使在之前的存储层，TiKV 这一层也开始做了存算分离，这就带来一个好处，比如有一些用户的数据是冷数据，因为我们在云上发现大多数的用户的业务和数据满足 82 法则，20%的热数据，80%可能是冷数据，但这些冷数据你在它不用的时候就可以按照流量的需求，直接 compact 到 AWS S3 这样云上更便宜的存储上面。AWS S3 存储的价格每 TB 每个月大概 20 美金，喝两杯咖啡就有一个月一个 TB 的存储空间了，这还是没有任何优惠的情况，实际上还可以更便宜。 \n\n\n\n所以基于新的存储引擎，我们可以发现本身 TiDB 之上所有的组件一下子就变成了无状态的。当一个组件变成无状态了以后，怎么去降低成本？池化。 \n\n图中 TiDB 右边现在已经把所有的包括计算节点存储节点全都变成了池化的设计，最上面加入了一层 Gateway，用户直接连接到 Gateway，Gateway 负责对现在用户的请求从资源池中捞出一个活跃的节点，它不用的时候连接断开再放回去。 \n\n大家看这个图尤其是做系统架构多年的朋友会有个感觉，这个东西感觉不像一个数据库，反而像大型互联网公司后台的服务——有这个感觉就对了，因为我们在设计这个系统的时候就不是把它当做一个数据库在设计，而是把它当做一个真正的云服务在设计，所以才能达到极致的性能和成本的压缩。 \n\n\n\nTiKV 是 TiDB 的存储引擎，所有的数据都是通过 key-value 来编码的，Key Space 本质上，就是在编码前面加上一个用户 ID 的前缀，将 tenant ID 作为 group keys 的前缀。 \n\n\n\n这张图解释了零成本起步，业务没有流量的时候就不收钱，本质上还是依靠池化来实现的。刚才我提到用户的连接都是连接到一层可以水平扩展的 Cluster Gateway 上，Gateway 来控制计算节点是否启用。如果这个客户的数据特别冷，十天半个月都不访问一下，这个数据完全存储在对象存储上，在对象存储上的成本是极其低的，在用户请求的时候再快速加载回来。这样一个架构保证了 TiDB Serverless 基础设施的成本会被均摊到所有用户身上，用户越多，数据量越大的时候，成本也就会越来越低。 \n\n\n\n我最后分享一个小小的例子。我们公司内部也有自己用自己产品的习惯，这是我们自己的一些服务 demo，全部用 TiDB 自己构建。我们做了一个很有趣的工具叫 OSS Insight，把 GitHub 上的数据抓下来做分析的一个在线应用，这个在以前传统的 TiDB Cloud，也就是经典 TiDB 云上部署架构下，一个月的成本在一万美金左右，上图就是我们付给自己的账单。 \n\n\n\n同样这个业务今天已经接近 12 个 TB 了，这样一个巨型的数据库前一段把它迁移到 Serverless 以后，总体成本下降了 70%，而业务在使用层面上也完全没有任何的感知。 \n\n\n\n这里有一个很有趣的真实例子，刚才我们看到整体的 TiDB Serverless 的设计是面向弹性去做设计的，但是这种东西总是希望能有一个实际的例子去验证一下这东西是不是真的在现实生活中比较好用，我们也真的有了这样的机会。今年 4 月初 OSS Insight 成功登上了 HackerNews 的首页，流量一下暴增到原来的 7 倍，这个事情还发生在中国时间的深夜，我们的工程师都还在睡梦中，TiDB Serverless 自动发现了流量的突变把集群扩容，承担起 7 倍流量的业务负载以后，又自动缩回来，前端业务的各项指标都还是非常稳定的，也没有额外的收费。这是一个特别好的例子，我们也特别欣慰。 \n\n\n\n我今天分享了一些我们未来对数据库的看法，关于 TiDB Serverless，我还有三个点想强调。第一，虽然看到现在它是一个在纯云端的服务，但是我们有计划将更先进的架构服务于中国的客户，甚至你可以未来在私有化环境里面部署 TiDB 的 Serverless。因为我们设计这个系统内核的时候非常仔细的考虑了这个系统本身的可移植性，刚才这些东西未来大家会在自己的数据中心或者自己的云上去使用；第二，我个人认为这也是代表着数据库最前沿的发展的方向，就是云原生加上极致的弹性，我们在思考数据库本身的一些架构或者最底层的想法的变革都会遵循这个方向；第三点我个人觉得Serverless 是我们很好的练兵场，包括中国企业级客户我们预研出来的版本我们新的一些特性，最早会在 Serverless 上应用，比如刚才我说的 Key Space 这个功能，目前已经在 Serverless Tier 上实现了上万个用户的部署，经过上万个集群的打磨，很快也会在企业版和云上托管版本里边落地。 \n\n最后我想小小的总结一下今天我的分享以及我的一些感受。我也代表着 PingCAP，纵使大的经济环境充满各种不确定性，我们永远相信技术创新能够真正给业务带来价值，我也相信技术真正能够改变世界，所以我们相信未来永远是一个更好的世界。","author":"黄东旭","category":5,"customUrl":"the-future-of-database-2023","fillInMethod":"writeDirectly","id":500,"summary":"PingCAP 联合创始人兼 CTO 黄东旭分介绍了 TiDB Serverless 作为未来一代数据库的核心设计理念，同时探讨了 TiDB Serverless 对于中国用户的价值。","tags":["PingCAP 用户峰会","Serverless"],"title":"黄东旭：The Future of Database，掀开 TiDB Serverless 的引擎盖"}}]}}},
"staticQueryHashes": ["1327623483","1820662718","3081853212","3430003955","3649515864","4265596160","63159454"]}