刘奇：经典数据库亟需跃迁，TiDB 不是“平替”

憨包谷 2023-07-18 10:37:37  65447

分类专栏：资讯

导读

在刚刚结束的 PingCAP 用户峰会 2023 上，PingCAP 创始人兼 CEO 刘奇分享了题为“创新涌动于先”的演讲，全面解析了 AI 时代 TiDB 的演进方向，宣布 TiDB Serverless 正式商用，并携手用户代表发布了面向中国企业级用户的平凯数据库。以下是演讲实录全文，阅读需约 8 分钟。

过去一段时间，我拜访了全球各地的客户，聆听他们的挑战和建议，以及 PingCAP 是如何帮助他们解决挑战的。在这个过程中，我们也看到一些新的技术发展趋势。当下，AI 技术非常火，到处都是各种各样的 AI Demo，每家企业都在思考这样一个问题：AI 到底有没有可能重塑软件行业？我的答案是——AI 这次真的要重塑整个软件行业了。

作为一家软件公司，我们思考的问题直接体感通常有两个：一个是代码，一个是数据。

先从代码说起，大家有没有意识到，很多人在过去一段时间不自觉地变成了程序员。今天，我们向 ChatGPT 提问题，它会给我们一个答案；向它提要求，它会给我们一个结果。比如我们可以让 ChatGPT 做总结、写文章，或者让它生成图片。大家可以回忆一下，在 AI 时代到来之前，所有这些工作都需要用程序去完成。我们需要用各种各样的辅助工具，那些东西都需要编程开发。而今天，我们没有写任何一行代码，只是提了个需求，结果就有了。以前，这需要很多程序员很长时间努力才能得到一样的结果。而现在，我们向 AI 发命令、提要求、提问题就能拿到结果，事实上就等于完成了编程工作。现在，自然语言已经成为最热门的编程语言。在过去七个月的时间里，GitHub 上新增代码中已经有超过 46% 是由 AI 生成的。如果从软件开发效率的角度看，AI 实际上已经完成差不多一半的人类工作。

再说数据，我们今年一月份发布了一个 AI 生成 SQL 的产品，叫 Chat2Query（前往 tidbcloud.com 立即注册体验），用户使用 Chat2Query 就不需要再写 SQL 了，只要用自然语言描述一下希望得到什么数据，希望做一个什么分析，SQL 便会自动生成，只要在数据库里运行一下，就能得到想要的结果，并且还能用图表化的形式自动展示出来。

上图右侧是 PingCAP CTO 黄东旭在 GitHub 上的个人数据看板。以前要实现这样一个数据看板，需要一个前端程序员、需要一个数据分析人员写 SQL 来分析数据，还需要一个后端程序员部署服务，甚至还需要知道一点云的知识，理解如何把应用部署在云上。到了今天，这变成一件非常简单的事情，只需十分钟，一行代码都不用写。这是一次巨大的生产力提升，AI 带来的能力让数据消费的门槛变得极低。以前，我们必须是一个 SQL 的专家，才能分析数据。有人曾经写过一万多行的 SQL 来处理一个分析需求，这个东西不是人类能轻易掌握的。如今，这个门槛已经降到人人都有可能做到。这意味着我们只要能够连接上电脑，能和 AI 交互，能接触到数据，就可以消费数据。这个数量级可能达到 10 亿人。在接下来的几年里，由数据消费门槛降低带来的数据消费人数的增加，数据消费频次的增长，将使数据呈 10-100 倍规模的增长，这是一个远超我们预期的增速。

以上改变，将给数据库带来巨大的挑战，数据消费的门槛降到人人可用的程度，需要每个人都有一个数据库可用。早在四五年前，我和 CTO 黄东旭探讨过一个话题——如果 PingCAP 要为全世界所有开发者提供一个免费的数据库，那这个数据库的架构应该是什么样？

我们希望这个数据库能够做到实时在线，随时都可以访问，随时都可以用；我们也希望它是一个开放的生态，因为我们不仅仅有存在数据库里面的数据，还有很多存在其他地方的数据，我们需要有一个生态能够和所有数据消费端做更好的对接。

后来，我们形成了一个结论，起码它应该是个云原生的架构。如果不是云原生的架构，我们就没有办法去应对各种各样弹性的需求；今天，一个用户相对容易预测，那为全球所有开发者都提供一个免费的数据库，就意味着我们会有数千万甚至数亿的用户，这个数据库怎么才能做得到？它需要很强的数据整合能力；其次，因为不同用户的需求是不一样的，数据量也不同，我们需要它有非常强的弹性扩展能力。

过去这两年的变化特别快，大家感知最直观的可能是宏观经济变化很快，其实除此之外，AI 技术的进步速度也非常快。从 ChatGPT 在去年 11 月底推出，到今天才过去短短八个月的时间。这八个月中已经创造了无数新的纪录，包括一个新的项目在 GitHub 上面获得 Star 的数据、ChatGPT 用户增长的速度等等。

大家在面对大量新技术的时候，都做出了最直观的选择，那就是拥抱先进性。过去一段时间我在与美国、日本的客户交流时，最直接的感受是每个人都在讨论两个方向，一个是成本，另一个是效率。在当前经济环境下，这几乎成了所有人的共同选择。

如果仔细观察 TiDB 发展的轨迹，你就会发现用户对数据库的关注点，其实和 TiDB 实际解决的问题是高度一致的。TiDB 在稳定性、性能、高可用性、易用性、工具生态的提升等方面付出了巨大努力。但我们认为这件事光努力还不够，我们还需要有一个非常好的演进策略以及分层的架构设计。

在内部，我们有一个说法叫做 API First，各个模块之间优先设计 API（接下来我们也会推出更多基于 Open API 规范的 API 测试），有了 API 之后系统就很容易被其他各种各样的业务系统集成。举个例子，各大型用户基于 TiDB 都有自己公司内部的运维平台，通过我们提供的 API 能更好地融合到客户内部的平台里。在日本我和一个客户交流的时候，对方专门提到过这一点。过去他们需要花几天时间才能完成新版本的集成，但有 API 之后只要花几分钟就能做到。

TiDB 整个系统除了模块化的切分，也做了很好的纵向切割，从上到下分成三层。比如 Chat2Query 在最上面一层，这层会更关注整个系统的交互性、易用性，如何让系统更加自动化、更加智能；在 SQL 层主要关注如何提升它的稳定性，让它变得更加智能。比如 TiDB 的优化器如何更智能地选择，到底使用行存还是列存，还是让行列同时使用；最下面是内核层，所有人对此的关注点都一样，就是高可用、高性能。

在内核层，TiDB 的存储引擎使用了一个持续升级的策略——部署一代、研发一代、预研一代。今天我们听到的所有关于 TiDB 的讨论，其实都是基于部署一代的体感，不少用户还使用着 TiDB 3.0、4.0，而这已经是四五年前的版本了。当然我们也希望用户能更快升级到最新版本，享受到新版本带来的优势，每一个新版本都会带来巨大的性能和稳定性提升。7.0 版本发布的实验特性 Partitioned Raft KV 就带来了巨大的性能提升。前面预测未来几年数据会扩大 10 倍，部分领域会扩大 100 倍，在如此大的数据规模下面我们的数据库能力是不是也能同步扩大 10 倍、100 倍？这是 Partitioned Raft KV 解决的问题。我们预研一代的存储引擎 Cloud Storage Engine 已经在后面要提到的 TiDB Serverless 中应用，我们的 CTO 黄东旭在后面的演讲和 Blog 中都有详细的解读。

如果大家留心就会注意到，过去一年时间里 TiDB 的 Online DDL 的速度提升了 10 倍。设想一下，我们有一个 100TB 的表，加一个索引要多久？对系统资源的消耗又是什么样的？除了 DDL，还有一点是 TiDB 的扩缩容的速度在这个引擎里面提升了 5 倍，这也意味着数据丢失的风险降低 5 倍，业务中断的风险降低 5 倍。

经过多年发展，TiDB 目前已经拥有三大产品家族：一是面向企业级市场的 TiDB 企业版，服务于企业级关键业务场景；二是全托管的 TiDB Cloud，提供云端一栈式 HTAP 数据库服务，已经成为欧洲、北美、日本、亚太地区众多数字原生企业的选择；三是刚刚正式商用的 TiDB Cloud Serverless，一个 AI Ready 的数据库，以极简架构、极致体验和超低门槛为云上开发者、创业公司提供低至零成本的选择，较 TiDB 社区版和 MySQL RDS 更具成本优势。

TiDB 是如何在多个版本间协同演进的？从上图可以看出，最上面有一个 TiDB 的 Open Core，TiDB 的所有这些版本都是基于共同的 Root 生长出来，去适应不同的客户和不同的使用场景。

TiDB 企业版已经拥有很多大行、大型企业的使用经验，他们有些是从数据库一体机迁移过来的，在迁移过程中和 TiDB 一起积累了大量的迁移经验。最近 MySQL 5.7 马上就要结束产品生命周期（End of Life）了，用户应该怎么办？换一个数据库平替一下？我们的思路不一样，我们希望的是用户不仅仅是从 MySQL5.7 迁移到 TiDB，更要关注的是他迁移过来之后的获得的价值到底是什么。

我们希望 TiDB 提供的价值是“可持续、可扩展、可整合”。很多企业都有大量的 MySQL 5.7 ，有成百上千个 instance，管理和维护它们都是非常复杂的事情。TiDB 提供了资源共享的多租户能力，我们可以把更多的 MySQL 实例整合到一个或者多个 TiDB 集群，极大提升资源利用率，从而降低硬件成本，同步降低管理集群的成本。最近我们和一个客户交流，他们有很多 MySQL 实例，有的利用率不高，就直接降级，从原来的 8C 配置，直接降成 4C 或 2C 配置。过了一段时间，业务这边有个流量把系统卡死了，再给升级一下。过一段时间流量又下来了，再降级。这就很头疼，运维和开发的关系就很难处，降本增效的压力很大。这么多的 MySQL instance 一旦迁到 TiDB 上面，基于 TiDB 本身的资源共享能力，流量超了几倍都没问题，这就可以带来非常显著的降本增效。

接下来是 TiDB Cloud，它在过去几年里得到了全球客户的认可，包括欧洲最大的移动出行公司 Bolt，北美新锐的 SaaS 公司 Catalyst，印度最大的电商 Flipkart，日本著名的游戏公司 CAPCOM 等等。

最后是 TiDB Serverless。四年前，我亲手写下第一行源代码，探索新一代云上 Serverless 架构，这是预研一代的成果。非常幸运，预研一代的速度远远超出我们的预期，它现在已经正式商用了。过去几个月的时间里，TiDB Serverless beta 版已经拥有超过 1 万个活跃的集群。

Serverless 带来了什么样的价值和能力呢？第一，低成本零元起步。TiDB Serverless 完成了 PingCAP 的一个梦想，我们有能力为全球每一个开发者提供一个免费的数据库。

我想稍微分享一个内部的小故事，最早 TiDB Cloud 的 free tier 成本是现在的 100 多倍。我们内部有个笑话，自己总是调侃说我们是“贵司”。“贵司”是什么意思呢？TiDB “贵”。因为比较的对象是 MySQL，作为一个分布式系统，TiDB 跟一般的系统比成本肯定高，起步就三个副本，还有计算层、调度层，跟单机比肯定是贵了。很幸运的是， TiDB Serverless 出来之后“贵司”终于不“贵”了。得益于 TiDB Serverless 采用的完全分离式的架构，不仅仅做到了存算分离，我们还做到了算算分离、存存分离，整个系统的弹性非常强，同时它的使用异常简单，用户体验非常好。我们收到大量用户的赞誉，超出了自己的预期。

大家都希望把自己的时间精力投资在自己的创新上面，投资在自己的业务上面，尽量不想再花时间在数据库上面，将所有复杂的事情都交给系统，交给 PingCAP 完全自动化处理。过去，大家可能会很好奇，这听起来好得有点过了，能做到吗？凭什么？

今天我们在云上面使用数据库或者使用传统的 RDS，不管是什么数据库，本质上都是买一个虚拟机，按照最高的峰值要求配置，不管你的业务现在跑的是什么量，哪怕 CPU 利用率是 1%，你也必须为它的 100% 利用率付费。这就是一个传统的计费模式，永远为最高的峰值付费。

TiDB Serverless 的创新在于，你永远只为你正在使用的资源付费。举个例子，你现在假设有 10 TB 的数据跑在 TiDB Serverless 上面，你没有任何访问，那所有的计算节点全部会被自动 shutdown，但你可以在百毫秒的时间内就马上让它启动提供服务。这是一个巨大的进步，用户仅仅为使用付费，使用曲线长什么样，TiDB 的计费就会长什么样。这就是为什么 TiDB Serverless 能够做到比现在的 RDS，比云上面部署社区版还要便宜，只要这个 CPU 的利用率低于 20%，全自动的弹性就会带来巨大的成本优势。

今天，不管你使用的是经典的单机数据库、开源数据库还是云端的数据库，TiDB 都提供了成本更低，扩展性更强，更加省心的选择。

TiDB 源于中国，很多关键特性也来自于中国复杂的用户场景，毫无疑问中国市场就是 TiDB 的根据地和大本营。最近我们和很多中国用户沟通交流，他们给了我们非常多的反馈，很多反馈都非常有价值，特别是对于 TiDB 未来发展的预期和展望。我们发现，TiDB 企业版经过五年的打磨，更多是面向全球用户提供通用性的功能，但是这些功能对于中国企业级用户来说还远远不够。

当下，随着 TiDB 逐步进入中国用户的核心场景以及 TiDB 规模化进入国产化生态，面向中国企业级用户的“平凯数据库”正式发布了。

简单来说，平凯数据库主要包含 TiDB Open Core 的稳定内核以及满足中国企业用户的增强级企业功能。第一，提供国产化需求的企业级功能，包括图形化管控平台、全链路数据迁移平台、安全特性等等；第二，提供更完善的国产化生态系统的接入功能，包括国产软硬件的适配，比如操作系统、服务器等等；第三，提供更完善的国产化企业级服务支持能力。

未来，我们希望平凯数据库站在 TiDB LTS（长期支持版）的基础上能为中国的客户带来更好的价值，我们希望这个过程是开放的，会定期在国内各个区域组织用户讨论交流的活动，我们希望大家能一起参与到未来平凯数据库的建设中

网站声明：如果转载，请联系本站管理员。否则一切后果自行承担。

本文链接：https://www.xckfsq.com/news/show.html?id=26572

赞同 0

评论 0 条

刘奇：经典数据库亟需跃迁，TiDB 不是“平替”

相关文章

关注我们