圆桌实录:技术无感化成为 2023 年最值得开发者和企业用户关注的技术趋势丨PingCAP DevCon 2022

在 2022 年中,HTAP、Serverless、云原生、智能化成为全球数据技术的热门趋势。在刚刚结束的 PingCAP DevCon 2022 上,PingCAP 联合创始人兼 CTO 黄东旭、中国信息通信研究院云计算与大数据研究所副所长魏凯、云和恩墨创始人& CTO 盖国强、联易融副总裁沈旸、云启资本合伙人陈昱等嘉宾,与主持人 PingCAP 副总裁刘松进行了圆桌讨论。分别从产业、资本、技术、媒体等视角出发,共同探讨了 2023 年最值得开发者和企业用户关注的技术趋势,开源、云架构、平台化成为他们对中国数据库的三大共识。未来,技术无感化将成为基础软件的终极目标,让应用开发者提升开发幸福指数。

以下为圆桌实录。

全球数据技术和创新产品的前沿趋势

刘松:2022 年,数据库领域或者整个 Infra 领域最重要的技术趋势或应用趋势有哪些?

陈昱:我这次刚去了美国,有几个感受。一个就是美国特别缺人,缺人到什么程度呢?我去到咖啡馆,下午三四点钟就打烊了,因为根本就没有人来上班。第二个就是经济不好。经济不好的时候就要去省钱,会采取比如裁员、降低 Infra 投入等措施,这多多少少都会影响公司的决策。

但是在数据库层面上,如果性价比足够高,那在现在的阶段就更可能会被采用。所以 PingCAP 现在去做的 HTAP 或者 Serverless,是处在这个正确的大方向上。

黄东旭:我非常认同陈昱总刚才抓的重点,一个是省钱。因为现在包括各个企业,包括你是一个解决方案提供商,你要去卖你的产品的时候,如果你的 value 或者说你的 story 里面没有说我能帮你省多少钱,其实基本上大家可能都不会看你一眼。第二个我觉得是缺人,其实用另外一个说法大概就是从业者门槛的降低。相当于你原来可能是一个 Infra Engineer,现在没办法了,你可能被迫自己要变成一个 Full Stack,所以就相当于一专多能,或者说对于开发业务应用的门槛需要被降的更低。现在大家都希望用更少的人,更快的时间去 go to market,我举几个例子吧。

第一,有几个我特别感兴趣的,或者说很有代表性的公司,一个是 Retool,最近其实可能大家也都听说过它的融资故事。Retool 其实是一个有点像低代码的平台,但是他专门 focus 给一些企业内部去构建 dashboard 或者说内部的一些工具。它的特点就是很简单,拖拖拽拽就能把这个活给干了。这个切入点非常巧妙,因为原来可能对于一个企业来说,开发内部工具可能都要一个团队,现在可能用这个工具很快就能省掉一个团队的事情,而且很简单就能够做出来。

第二个我觉得很有意思的公司是 Vercel,它其实是一个前端的或者说网站托管平台。你可以认为它是一个更易用,更简单版本的 AWS。它的理念就是相当于帮你从应用开发、测试、发布以及到最后的运营,全都帮你一站式地去托管。它的整体模式也是走边缘 + Serverless 的模式。你会看到它的增长非常非常快,而且真正的使用起来,非常简单。

所以我觉得刚才举到的两个例子,都是印证了那一点,就是省人,省时间,简单。我觉得这是可能整个行业,或者说在北美这边技术圈在发生的最新的一些事情。

刘松:像 HTAP、Serverless,在北美目前的被谈论的程度和接受度,现在大概是怎么样的?还有 Serverless 是不是在硅谷已经变成了一个门票,做数据库、应用架构时已经变成了必选项?

黄东旭:第一个问题,关于 HTAP。我觉得 HTAP 现在还是一个很新的概念,大家还是持一个偏怀疑的态度,但是这个需求又是存在的。大家不一定会去定义它到底是哪个名词,但是大家都会去用。大家现在还不太想说把 HTAP 变成一个专有的 category,而是说我先用一些新型的数据库或者新型的产品解决业务问题。我觉得 HTAP 的普及还需要一定的时间。但是,已经能够看到星星之火开始在燎原的状态。

第二个关于 Serverless 是不是门票,我几乎可以很肯定的说,对于新创的所有数据库公司,如果说前两年你的门票是云原生的话,你今年的门票就变成 Serverless,没有 Serverless 你基本上不了牌桌。

数据库技术有哪些关注点?(HTAP/Severless/“DBless”/智能化)

刘松:视野回到国内,数据库技术在国内的发展,这一年有什么变化和关注点?HTAP、Serverless 等技术今年在国内市场上有哪些发生了一些变化?或者还有哪类的技术特别值得关注?

魏凯:我刚才听了陈昱和东旭两位专家关于硅谷的分享,我也非常认同,国内同样也有省成本,节流的动力。客户肯定希望以更低的成本,更高的效率来管理他日益增长的数据资产。而且现在上云是一个大趋势,云已经普及到一个阶段了,下一步是更好地用云。其实企业在用云上的数据库,发现成本还是要更精细地去管理。我们所里最近也在盘点 2022 年云和大数据这个行业的主题词。一个共同的主题词就是怎么去更精细的使用云上的基础设施服务,更好地使用软件。一个主题是从上云变成高质量的用云。那么这个趋势就很明显的提示出,包括数据库在内的云上的软件,都需要满足用户的精细用云的需求,Serverless 就是这个方向。我觉得这个是一个趋势,总的来说是更好地使用基础设施,让用户更省钱,同时支持业务正常的运转,应对突发的流量。

还有一个我看到的数据基础设施的需求就是怎么更好地支持数据资产化,怎么更好地支持数据的保护,内生的保护、权力的确定、后续的内部数据和外部数据的融合。所以我们看到了全密态、隐私计算、机器学习等这些技术怎么跟基础设施去结合。国内现在不仅在节流,而且在开源。怎么让数据变成一种生产要素,在社会上去广泛地跟别人的数据去连接,去碰撞,从而发挥更大的价值,就是往外扩,也是一个数据技术的发展方向。那么我们的基础设施可能也需要思考,怎么去更好地支持这个方向,而不只是节流。

沈旸:从用户角度来讲,首先是要把价值描述得清楚。但是价值是很难通过技术本身来体现出来的,价值一定要通过场景来体现出来。不同的技术亮点在不同的场景下,节省的成本或者带来的效益是不一样的。

比如说做基础架构的,或者说做应用开发的,首先还是得了解客户的业务和真正的使用场景,然后再把这个场景拆分成每个技术的组件,甚至拆分成技术里面的一个细分的技术点,从这个角度上去打动客户。我们讲的很多东西,为什么说有的时候要降本增效?使用一个技术、买一个产品是不是有价值,本质上还是要看客户使用这个东西能不能赚到钱,或者说给客户产生更多的价值。

盖国强:我也一直在思考,未来的数据库,终极的数据库应该是什么样?大家都提到了 Serverless,其实我们是希望我们的数据库能够更弹性的,甚至是无感的伸缩,这个是在架构层面来解决问题。

在数据库的内涵上,我们是不是也能实现优化?在今年大规模的国内的核酸检测上,我们曾经帮几个省去优化数据库,当面临这种并发负载的时候,我们发现,这个问题还远远没到我们现在所谈论的 Serverless 等等这样的话题上。往往这些数据库,通过简单的 SQL 的优化,数据库内部的热点表的拆分拆解,就能够解决问题。

所以我认为未来我们所谈论的 Serverless,还应该极大地包含数据库内涵上的智能化。数据库可以在内部通过智能的、自动的热点拆解去解决这样的问题。所以在 Serverless上,我们可能还要讨论“DBless”,我以前讨论过“DBAless”。我们以前搞 Oracle 的时代,其实大家面临着一个很大的,很多年的一个困扰,就是一个 DBA,他要花费很多力气,才能把一个 Oracle 的集群安装起来。我们今天在使用分布式数据库的时候,很多 DBA 面临的挑战是我怎么样把一个分布式数据库,十个节点,一百个节点,把他部署运行起来。随着云原生或者 Serverless 技术的演进,我觉得它越来越简化了,理想状态未来可能不需要 DBA 去介入这样的场景了,当然,这包括的是说在 server 端做了很多的工作。我认为在应用端,我们要在 DB 内部,要去做很多很多的智能化的探索,去消解内涵上存在的一些问题。

所以,我觉得在中国今天的这种大规模的数据应用场景下,可能会促使一些根本性的创新涌现出来。我是 DBA 出身,从 DBA 的视角来看,我认为 20 年前我入行的时候,我们所处置的那些问题跟今天我们使用一个数据库处置的问题没有两样。所以这是一个最大的痛点。我们可能在架构上投出了特别大的关注,但是在 DB 内部所做的事情不足够。

20 年来数据库内涵的变化

刘松:我觉得盖总提了一个很重要的新的关键词是“智能化”。东旭能不能简单地给听众讲讲,从分布式到云原生,再到现在的所谓的 Serverless,还有智能化,里面用了一些 AI、Machine Learning 这一条线,为什么走到今天还没有达到盖总说的“有那么明显的区别”?

黄东旭:我现在最大的感受就是 Oracle 可能花了很长时间,很多很多年把用户积累下来的经验,全都弄到产品里边了,这是一条路。但是对于新一代的这些在云上的数据库,我觉得几个东西发生变化了。

第一个,就是 workload 发生变化了。以前可能传统的单机型的数据库,他没有这么大的数据量的要求。当时设计出这个关系模型的时候,可能根本没想过,居然有一个数据库能有几百亿条数据,这个可能没想过这些。但现在运营商,或者说在分布式系统的加持之下,我觉得关系型数据库理论可能会有些修订。所以这个里边,包括到现在我们优化的方向是什么样子,可能跟前辈,像 Oracle 这样可能不太一样。盖总说到的一个优化的方案就是我怎么去确定好分区,或者分片,或者选择怎么去做 partition。一看就感觉这个东西是面向分布式或者大的数据量去做的优化,像这种优化,其实我觉得未来可能是应该做在数据库里面,其实是更好的。

第二个,刚才其实也是像我说到的智能化这一块,Machine Learning 的这些技术,机器学习这样的技术最适合的就是人类的经验。比如说我这些东西见多了,我大概感觉往这个方向走一走就行了,这种事情其实最适合的是机器来做。当然,我刚才说到的像 Serverless,其实这些更多的是一种基础架构,或者说构建这个数据库的方式发生了变化,以至于我们终于可以去提供一个更简单的接口。从古到今都是,大家永远喜欢简单的东西,Serverless 是去实现更简单这一步里边会用到的一个技术的流派方向而已。

从产业界看 HTAP 的应用场景和趋势

刘松:东旭其实提到了几点,虽然数据库有了这么多年,但是最近有三个大的变化,一个是数据量,成百上千倍的增长,第二数据的负载越来越混合,第三就是对于怎么把数据库和人工智能结合,让数据库自己运行得更智能,更有易用性。这几点,可能这是几年发生的变化。

那从需求侧看,这几个趋势是不是大家觉得未来也是数据技术领域最热门的?

魏凯:自动驾驶的数据库,现在是大家梦寐以求的,用户都需要有这样的一个数据库。我也特别同意刚才盖总说的,内涵式的创新。刚才提到 Serverless,包括之前的上 Docker,上容器,这都是数据库部署方式的一种变迁。内涵式的变化,我觉得确实是一个趋势,而且有可能是未来创新的一个洼地。

不光是小企业希望简化他们的数据栈,从业务系统到分析系统的管理,大企业也需要,大企业也苦于这几年他们要做 ETL,要做数仓,现在又要做数据湖,中间这个 Gap 又特别的大,他们花了大量的金钱去请咨询公司,去做数据治理,然后再建一个第二平面,这两个系统之间还经常还有数据质量的问题等等,他可能也需要一个融合。从宏观来看,可能未来我们的数据基础设施,我觉得不仅要照顾到交易的处理,还需要考虑到分析的处理,而且更好地支持这两个系统,让数据管理、后续的运维更加简单。这可能不只是一个 HTAP 数据库能搞定的,可能是一个更大的数据架构的再造。

刘松:大多数客户都希望有一个简化的方式来处理这种混合负载,有可能你不知道到底是正在写入还是正在查询,这个尤其对于很多小企业来说,他没有大量的工程师团队去搞 ETL,搞数仓,尤其是一些现在新的系统。那么沈总,您从之前的经历和最近的金融经历来看,这种实时数据分析,类似于 HTAP 这种场景,你看到哪些?

沈旸:HTAP 还蛮熟悉的,因为我从 2013 年就开始做 SAP HANA。SAP HANA 算是蛮早的一批做 HTAP 数据库,我一开始从做数仓起来的,做了很多年,当时零几年就通过 ETL 工具导到数仓,再做分析,从 ERP 系统导到 DW 数仓里面去做数据库的分析,一般来说延迟至少半个小时或者整个晚上的时间。这是一个比较传统的架构,其实这种架构到今天为止也基本上能支撑大部分企业的业务,因为我们讲所有的基础架构最终还是要为业务服务,我们看到所谓的业务主要分两种,第一个业务场景是互联网公司,互联网公司是对实时性要求非常高,他们做的一些决策其实也是有很多临时决策,比如做双十一的时候你看到很多订单过来是不是马上要做一些优惠,做一些促销?是这样一个场景。还有另外一种是比较传统的,尤其是制造业或者说不跟客户发生直接关系的零售行业,因为有些零售行业是通过分销或者代理的方式,大部分零售并不是实时的,比如在阿根廷的某个店卖出了一双鞋,是不会马上推送到总部那里去做实时分析?所以说我觉得企业会分两种,对于传统的企业,比如制造业或者非直客的零售业,其实用数仓的方式是能够解决问题的。

还有对云的概念,现在我们想要用 HTAP 数据库的话,我们希望在云上有一款数据库能够快速提供服务的,不要让我知道底层所有的逻辑,在 AP 和 TP 之间做一个平衡,针对我这种场景做得还不错的。等到哪一天量特别大了,这时候我要去做一个更优化的场景,有可能会往回走,会要求我的数据从云上能回来,要提供能上得去又能下得来的便利性。

黄东旭:稍微补充一下,我觉得沈总的观察还挺敏锐的。我就提一个点,对于一个 HTAP 为什么我们一定要在云上做,刚刚我觉得沈总回答到精髓了,我发现真正 HTAP 的形态基本上在云上做意义才大,因为 it’s all about balance,你只有在云上才能去打破 AP 跟 TP 之间对于资源的不平衡,比如像 TP,其实要求的是一个稳定的、高性能的、低延迟的一些硬件资源,但对于 AP,可能是短时间大量海量的计算资源,因为你要做高性能的 AP,你会发现在云下这个东西怎么摆都别扭,我为什么要去买这么高配的服务器,我为什么每天就跑三次大的全表扫描,但是 99% 的时间 CPU 都压不上去。这件事情如果要达到沈总刚才描绘的那个理想的状态,有可能不一定是说你量大了要往回搬,反而可能是量大了在云上其实可能才能更省钱或者用云的技术才能更好解决。

刘松:刚才沈总讲了他对 HTAP 的看法是以他从当年 SAP 的经验来看,这种存量的、稳态的应用其实数据仓库依然有很大价值,但是对于创新的、敏态的、追求实时性反馈的应用,HTAP 有它的空间。

再往下,HTAP 恰好是在云上可能更能发挥负载均衡的效率和它的价值。这又延伸到了之前在私有部署情况下服务器的限制。所以其实是一步一步过来的,从负载,从场景,越来越多的场景部署到云上,HTAP 的部署对资源的要求也越来越多,发现云才能解决。

中国数据库产业的三大共识

刘松:目前有一个差异,国内的公有云离硅谷的还是有差距的。但我们国内的技术人大多数人都相信公有云或者是新一代云的技术还是会逐步因为技术的演进带来更大的空间,是不是这些技术未来也能够有部分的反向,比如云原生的技术,K8s 的技术反向回到了私有部署的空间,这个不知道盖总有没有什么思考?

盖国强:我稍微再补充一下,我们从国内看整个数据库产业的状态大体上是一个什么样子呢?上半年我曾经写过一篇文章来讨论中国数据库的产业格局,第一个洞察是说开源在国内也成为主流了,开源数据库,所以从墨天轮的排行榜上来看,TiDB 长期在榜首。从 TiDB 到华为的 openGauss 再到 OceanBase 的开源,其实开源成为了国内数据库的一个关键的驱动力量。其实跟刚才陈昱总讲的非常相似,其实全球是一样的,大家都缺人,大家都希望省钱。缺人的一个解决方案就是通过开源能够汇聚众智,大家共同创造,比如我们知道 GitHub 上有 800 万的中国的程序员在贡献代码,这个力量是庞大的。

第二是说开源能够为很多用户提供比较自由的使用方式,开源又在成本上提供了很大的优势,当然从全球看,从 DB-Engines 上来看开源数据库超越商业数据库的时间是在 2021 年 1 月份。我们比较乐观地看到在中国开源数据库的走势超越商业数据库其实已经也有大约一年时间,我觉得跟全球的格局是接近的。

刚才讨论的 serveless,再到我们大家刚才探讨的 HTAP 在国内又呈现一个什么样的格局?这些探索从云上到云下会不会形成联动,或者是说成为一个共识?我们一直在观察和思考这件事情,中国市场如果从云的角度来看,他远远比北美更复杂,我们有公有云、行业云、政务云等等不同的形态,不同的形态在基础架构上其实就有很大的差异,在数据库上我们看到的差异性会更大。但是有几点共识我觉得是达成的:开源成为中国数据库里面的一个核心驱动力,大家围绕开源去构建生态,去构建核心应用;不管是数据平台还是整个企业级 IT 的基础设施也都已经梳理成了云模式,随之而来的就是以云架构去建设数据库,我们过去谈云原生,现在我认为 serveless 其实是云原生向前又更进了一步。所以开源、平台化、云架构,我认为不管是从公有云还是从行业云上这都是共识。

再到刚才大家探讨的 HTAP,我一直在思考这件事情,有一些不同的看法。我始终认为未来的数据库应该对用户来说是无感的,你不要告诉用户我是什么样的数据应该去选择在 100 种时序里去挑一种,我又要在 100 种图里面挑一种,我要在 100 种 HTAP 里挑一种,我觉得未来不要给用户这种复杂性,只要这个数据来了,那我后端自动去匹配跟他最适合的,不管是存储场景还是计算场景。

首先我认为 HTAP 其实是 OLTP 在发展过程中所衍生出来的一个概念,这个概念其实是不断将 OLTP 的场景在做放大化,从而去为用户提供简化的数据库应用场景。Oracle 在他 23C 里面提出的一个名词也叫 App simple,就是让用户简化、简单,我觉得这也是 TiDB 的一直以来的理念。站在这个出发点上我觉得不管我们是谈 HTAP 还是谈什么,他一定是正确的,只不过我们是如何让他做到更高效,让用户更无感。或者将来不需要再谈 HTAP,我们已经创作了太多的词汇。我记得爱因斯坦想做的一个事情叫统一场论,就是想把不同的概念力统一起来,他觉得太难理解了,如果我们将来把数据库的词汇也统一起来,把他简化,让名词“less”掉。

云原生、开源成为企业基础软件的入场券

刘松:我们先换一个视角,陈昱总从投资人的角度你对开源也很熟悉,对云也很熟悉,包括现在的平台化。你看这两年从企业服务也好,整个的技术来看,是不是最重要的、新的软件技术都要遵循,一个是开源技术,而且是真正的国际化开源,另外一个都是面向云架构的。你投资项目的时候会不会看项目对云原生架构的支持、是否开源、开发者生态是否活跃等,你怎么看待这三个趋势?

陈昱:因为我们基金也是双币基金,做美元基金投资的时候和做人民币基金投资的时候还是蛮不一样的,day one 就得想清楚说你到底做的是国产化市场还是想去投资一个更大的全球市场。

在国内,金融、政企去用的时候,肯定不会把云原生放到这么重要的地方。另外这么多花里胡哨的 serveless、HTAP 这些名词也并不重要,你给他一个数据库就好了。

但是在全球市场来说,这些就可能也是个数据库 101 里面的东西,大家已经接受了,因为讲了十几年了,或者大家从一开始接触数据库的时候可能就会在公有云上面去玩,他也可能没有在自己本地上去装过一个 MySQL 或者 PostgreSQL,新一代的海外程序员可能对他来说数据库就应该跑在云上面,这可能就有很大的不一样。所以在做美元投资的时候肯定是开源、云原生,这肯定是绕不开的两个要素。

黄东旭:这个地方我从技术角度稍微评论一下。我觉得云原生跟 cloud only 或 public cloud only 这两个不一定是等价的,你在私有部署的环境下,刚才说的云原生的架构也好,serveless 的架构也好,技术层面上都是可以应用到私有环境。第二,在这种私有环境下的 cloud native 以及 serveless 他带来的价值是不一样的,这个价值其实很传统的那些纯 OP 的产品比,他确实有自己独特的价值。

2023 年最值得开发者和企业用户关注的技术趋势

刘松:2022 年底我们往下看 2023 年,你认为最值得用户,包括开发者和企业用户关注的技术趋势和场景的趋势会是什么?

魏凯:确实云是一个大家高度共识的,中国市场其实也在全面上云,大企业自己在建私有云,因为不管从什么角度,从监管的要求,从成本经济性的考虑,像中国头部银行他们从自己成本控制上,从自己业务的合规的要求上,都不得不自建云。但不管怎么样都是云,可能有很多差别,但整体上趋势都是在往云上迁,这个是一个大的背景,我是高度同意的,只不过他们不是完全用公有云。

要说整个的趋势的话,我觉得可能还是回到刚才那个观点,我们要看怎么更好的让数据的存储、管理更高效,同时让上层数据的资产价值发挥更加地便捷,节流和开源都同等重要,我们的技术创新肯定也是朝着这两个方向去努力。

沈旸:大家开头讲 OP 模式,中国的 OP 会是长期存在的,这个 OP 跟公有云还是有很大区别,比如说私有云的投资周期,可能投资三到五年中间是不会经常迭代的,但是公有云其实每年都会有大量新的投入跟投资,每年都会涌现很多新的技术。但是我觉得未来可能会有一种混合模式,就类似于我们现在大家看到的,既不是燃油车也不是电动车,而是是混动车在中国占的份额越来越高。因为中国也不能到处装充电桩,如果全部用石油可能资源又耗不起,最终用了一种所谓的混合模式。在国内如果说公有云和私有云之间的带宽跟延迟能降到足够低的程度的话,我觉得未来在国内这种混合模式也可能变得有可能。

另外一个趋势,我觉得无论是 serveless 还是 databaseless,未来过几年大家可能会更关注“dataless”,因为大家去用数据,或者搭建应用的时候,其实把数据库搭完才实现了第一步,剩下还要大量时间找数据,做数据分析,最终为了得到一个很小的结论,你从前到后花了很多很多时间,在找数据上也花了很多时间。今年参加 TiDB Hackathon,大家把 TiDB cloud 拿来做很多的 public data 的共享机制,这个未来大家可以关注。因为没有数据,你根本无法做分析,也不是所有的数据都是你个人产生或者企业内部的数据,我觉得未来 20% 是企业自己内部的数据,80% 应该是社会或者其他各种数据拿来一起做分析,而且一个云上的数据库天生从 create 以后,就应该带有各种各样的 demo 场景的数据,否则 create 这个数据库我进去玩什么,我没什么可以看的,也没什么可以用的,这个对应用开发者和数据开发者不是一件非常友好的事情。而且这件事情也是 cloud only 的事情,就是在线下不可能做这件事情。

盖国强:我概括几个词,第一个是开源,我特别希望说中国的数据库产业界能更加地走向开源开放,也要从中国走向世界,当然 PingCAP 已经作出了一个示范,在中国诞生的一个数据库今天在北美去征战市场。我们相信中国技术会越来越多走向全世界,在每一个角落里找到应用场景。让开源更开放,中国技术才能走向世界。

第二,让应用更深入,更广泛。虽然国产数据库出现了一个蓬勃发展的生态格局,我们在墨天轮排行榜上有超过 200 个国产数据库品牌,但是整体上大家的市场占有率仍然很有限。在国产化的浪潮之下,其实我们能够预测或者感受到 2023 年会是国产数据库蓬勃发展、广泛应用的一年。

第三,我希望产业界的同仁们能够携手协作,东旭刚才也讲了在很长时间内数据库的开发者和 DBA 是两个世界,开发者干一套活,DBA 是这样在用,在整个行业市场我们看到其实从学术界到产业界再到用户,其实都存在很多的壁垒,如何能够在国产化的浪潮里加速打破这个壁垒,让大家能够携起手来让用户真正的需求能进入到数据库内核,让学术界的科研成果也加入到数据库内核里面去,这样的话会加速发展。我看到 PingCAP 在跟 CCF 做了很多合作,我希望能够加速融合的态势。

最后我有一句话作为总结:开源莫畏征途远,开源这个事是非常漫长的,需要坚持,需要大家共同投入聚焦,还有一句话:耕获菑畬又一春,只有不断的耕耘才能最终获得收获,数据库绝对是一个长期主义者。

陈昱:从投资人角度,我更希望看到数据库发展往一种技术无感化的趋势去发展,无论 HTAP 也好还是 serveless 也好,其实他都在尝试着去降低用户的使用门槛,我希望有一天作为一个程序员不用再关心 TP 和 AP 使用起来有什么样的差异,你不用去关心怎么才能够把我的数据库在云上部署,然后能够把各种存算分离、各种弹性扩展的东西给用起来,我不需要花一天把数据库部署上去,再花一个月做数据库调优。我希望以后这些东西就全部都消失,对于程序员来说你只需要两行或者三行代码把你的商业逻辑写清楚就好了,你不需要去了解数据库底层到底是怎么实现,到底怎么才能够用好,我希望长远来说数据库能够往这个方向去发展,技术无感化。

黄东旭:首先数据库技术还是有很多事情可以做,包括像刚才魏所和沈旸提到的数据共享,包括盖老师这边讲到的各种各样的应用场景,陈昱这边提到的门槛降低,其实还有很多事情可以干。但很多事情我个人觉得有一条主线,这条主线就是贴着应用开发者,到最后不管是企业级应用还是其他各种应用,这些应用都是程序员写出来的,都是代码的开发者开发出来的。

本质上来说你怎么去提升这些应用开发者的效率,这点可能是一个大的主线,有可能这个主线发展到未来,会发现数据库技术在做很多事情上都不是数据库技术了,比如一个更好用的 serveless 数据库怎么做?我用一大堆负载均衡或者弹性计算的技术,甚至接下来我在想是不是 SQL 对于应用开发者来说还是太复杂了,有没有更好的离用户更近的数据产品表现形态?包括刚才说的数据共享,现在有大量的 web3 公共数据集,也有其他各种公共数据集,我能不能快速在启动数据库的时候自动加载上去,在云上这一切其实都是可能的。我觉得接下来未来的数据库技术,技术本身不重要,最后的方向是提升每一个应用开发者的幸福指数。数据库技术一定会往更简单、更加好用、更加方便地让大家写出新的应用,加速 go to market 速度这个方向去努力。

相关推荐

TiDB 可观测性解读(二)丨算子执行信息性能诊断案例分享

通常我们可以用 explain analyze 语句获得算子执行信息。explain analyze 会实际执行对应的 SQL 语句,同时记录其运行时信息,和执行计划一并返回出来,记录的信息包括: actRows 、 execution info 、 memory 、 disk。不同算子的 execution info 可以通过 TiDB 文档 ( https://docs.pingcap.com/zh/tidb/stable/sql-statement-explain-analyze )了解。

TiDB_PingCAP 的博客 1020

TiDB × AI :DeepSeek 时代你需要什么样的数据基座

AutoFlow 是一套 GraphRAG 框架,不仅提供了类似于 LlamaIndex 的能力,而且还内置语义化的知识图谱构建和召回,以及我们在 AutoFlow 上实践得出的一系列行之有效的领先的 RAG 能力(这些接下来会介绍)。不过需要强调的是,Dify 是一个开箱即用的非常易用的界面,而 AutoFlow 虽然功能更强却则具有比较高的使用门槛,所以这两个选择其实面向了不同的群体,用户需要依据自己的实际需求进行选择。它并非传统的基于规则的优化工具,而是利用大模型的知识来优化不同类型的数据库。

TiDB_PingCAP 的博客 1417

架构师必看!现代应用架构发展趋势与数据库选型建议丨TiDB vs MySQL 专题(一)

随着业务系统数据量的增长,早起只能无奈采取分库分表方案以及架构,这不单为运维带 来了极高的复杂度,同时对业务开发也带来的极大的入侵,SQL 只能限定按照 shard key 维度进行编写,无法任意维度的进行 SQL 查询,开发不得不牺牲业务需求,业务的发展也不得不受限,同时又需投入大量的高精尖人才进行开发维护。这对数据库的承载能力提出了极高的挑战,不但需要承载大数据量,又需要保障业务读写性能的稳定性,而在数据的承载能力上,MySQL 的极限,是 TiDB 的起点。一行命令完成扩展,无需任何的人工干预。

TiDB_PingCAP 的博客 1233

TiDB 观测性解读(一)丨索引观测:快速识别无用索引与低效索

通过识别并优化未使用或低效的索引,可以减少资源浪费,并提高系统的响应速度和稳定性。在 TiDB 中,TIDB_INDEX_USAGE 系统表提供了相对丰富的索引使用统计数据,帮助 DBA 快速发现低效索引,并通过优化或删除它们来提升数据库效率。尽管删除索引的操作相对简单,但在实施时仍需注意潜在的限制和风险,尤其是在大数据量和高并发环境下。定期检查索引使用情况,尤其是对于大规模数据库。确保用于决策的统计数据涵盖足够长的业务周期,避免误判。

TiDB_PingCAP 的博客 974

海量数据融合互通丨TiDB 在安徽省住房公积金监管服务平台的应用实践

目前安徽省住房公积金监管服务平台已具备一系列功能模块,包括首页、运营分析、统计报表、智慧大屏、数据治理、风险检查和系统管理。其中,运营分析主要用于从不同维度分析公积金业务指标,统计报表则负责生成、填报和查询住建部规定的报表,同时也支持省级用户的报表导入、核对和更新。智慧大屏提供了综合和业务两大类可视化展示,而数据治理模块则涵盖了传数统计、数据检核和人工数据核对等功能,以确保数据的质量。风险检查方面,平台不仅支持公积金中心的自我检查,也支持省厅的检查,并可以根据需要添加新的检查模型。

TiDB_PingCAP 的博客 1133

TiDB 2024 年度报告:增长的故事

TiDB 2024 年度报告:增长的故事

TiDB_PingCAP 的博客 328

TiDB Chat2Query 深度解析:我们如何打造一款更高效、准确的智能 SQL 生成工具?

上个季度的销售额是多少?“哪个产品类别表现最佳?“本月客户投诉的趋势如何?相比其他工具,Chat2Query 能够对用户上传的大规模数据集进行理解和分析, 摒弃繁杂的专业术语和查询语句,Chat2Query 使得用户能够通过自然语言直接向数据库提问,并即时获得答案。

TiDB_PingCAP 的博客 1335

4.98 亿月活背后的国产数据库:咪咕视讯携手 TiDB 攻克内容分发核心系统挑战

咪咕大概是 2018 年左右正式开始对分布式数据库进行研究的,到现在为止我们看到和测试过太多的国内产品。但是在当时,敢用 LSM 树而不是 B+ 树做存储引擎,敢做分布式存算引擎分离的,能够行列副本共存、优化器路由分流做 MPP shuffle 的,市面上真的真的非常非常地不多见。比较多的是精致的分库分表外挂,或某些知名国外产品的模仿版。TiDB 的产品给我的印象是极具冲击性的,那么大胆、不随大流。验证和使用下来,效果也是切实的。

TiDB_PingCAP 的博客 1208

53 倍性能提升!TiDB 全局索引如何优化分区表查询?

在 TiDB 中,全局索引是一种定义在分区表上的索引类型,它允许索引分区与表分区之间建立一对多的映射关系,即一个索引分区可以对应多个表分区。这与 TiDB 早期版本中的本地索引(Local Index)不同,本地索引的索引分区与表分区之间是一对一的映射关系,即一个分区对应一个局部的索引块。全局索引能覆盖整个表的数据,使得主键和唯一键在不包含分区键的情况下仍能保持全局唯一性。此外,全局索引可以在一次操作中访问多个分区的索引数据,而无需对每个分区的本地索引逐一查找,显著提升了针对非分区键的查询性能。

TiDB_PingCAP 的博客 1356

一行代码不用写,用 Autoflow + Gitee AI 搭建本地知识库问答机器人

本文详解 AutoFlow 从部署到配置的完整流程,包括数据库连接、模型设置、知识库创建及聊天引擎配置,实现了一行代码不用写的问答机器人快速搭建。轻松上手,助力开发者探索智能问答解决方案。

TiDB_PingCAP 的博客 1046

TiDB 分布式数据库多业务资源隔离应用实践

本文将分享某客户在 TiDB 分布式数据库中实现多业务资源隔离的实践案例。

TiDB_PingCAP 的博客 1317

攻克多版本运维难题:爱奇艺百套 TiDB 集群升级至 v7.1.5 实战宝典来袭!

本文将深入探讨爱奇艺如何通过升级,成功将百套 TiDB 集群从多个旧版本升级至 v7.1.5,攻克多版本运维挑战,获得更稳更快的 TiDB 使用体验。

TiDB_PingCAP 的博客 1157

百亿大表的实时分析:华安基金 HTAP 数据库的选型历程与 TiDB 使用体验

明确需求:首先评估业务对 TP(事务处理)和 AP(分析处理)的需求比重,确定数据量、查询速度和响应时间,确保数据库能满足业务对实时性的要求。技术特性评估:考虑数据库的实时分析能力、可扩展性、高性能、安全性和灵活性,以支持业务人员实施的场景需求,特别是后台营销人员对数据实时性的需求。集成与兼容性:评估数据库与现有数据库、应用程序和其他关键系统的集成能力,确保数据同步策略的无缝实施。安全性与可靠性:重视数据库的安全性措施、容灾备份机制、数据恢复能力和错误处理机制,保障业务连续性和数据安全。

TiDB_PingCAP 的博客 1019

TiDB 的高可用实践:一文了解代理组件 TiProxy 的原理与应用

TiDB 是一款典型的分布式存算分离架构的数据库,其中计算层由多个无状态的 TiDB Server 组成,这些 TiDB Server 同时对外承担连接请求。为了可以将连接分发到多个 TiDB Server 节点上,一般需要借助外部负载均衡组件如硬件负载均衡 F5、软件负载均衡 HAProxy 等。为了实现全链路的高可用架构,我们经常也需要考虑负载均衡组件本身的高可用性,比如通过 KeepAlived 来保证 HAProxy 的高可用。

TiDB_PingCAP 的博客 1255

你需要什么样的资源隔离?丨TiDB 资源隔离最佳实践

通过本文的学习,相信大家对 TiDB 的资源隔离能力有了更全面的理解;大家可以根据不同的场景需求,选择合适的资源隔离方案。如果您有新的资源隔离需求或场景,欢迎与我们联系。

TiDB_PingCAP 的博客 1254

狂飙 50 倍丨TiDB DDL 框架优化深度解析

前面我们介绍了 TiDB DDL 任务的整体执行流程。接下来,让我们聚焦到在线 Schema 变更的细节上。执行单步变更:Job Worker 会根据任务定义,执行一次在线 Schema 的变更。每一次变更都代表着 Schema 向目标状态迈进了一步,即进入下一个状态,可能的状态包括 write-only 和 delete-only 等。状态更新:完成单步变更后,Job Worker 会将当前的 Schema 状态更新到元数据中。

TiDB_PingCAP 的博客 1204

唐刘:TiDB 的 2024 - Cloud、SaaS 与 AI

最后再说下产品,在今年,我们发布了TiDB 8.1和8.5两个版本。在 2025 年,我们会有一个重大的改变,就是会持续的投入到 8.5 版本的质量加固,同时收敛新功能的开发,只会在 2025 年发布一个有更高质量的 LTS 版本。关于 TiDB 8 系列,我后面再写一篇文章详细的介绍一下吧。在 2024 年,我们交付了非常不错的成果,当然,能取得这样的成绩,来自于我们不断地交付优异的产品,满足客户的需求,赢得客户的信任。

TiDB_PingCAP 的博客 1054

PingCAP 连续两年入选 Gartner 云数据库管理系统魔力象限“荣誉提及”

TiDB 凭借领先的 HTAP 架构设计,支持用户在云上的数据库中同时运行关键业务交易和实时分析任务,充分享受云的弹性优势和业务连续性优势,助力企业实现数据敏捷。PingCAP 是业界领先的企业级开源分布式数据库企业,提供包括开源分布式数据库产品、解决方案与咨询、技术支持与培训认证服务,致力于为全球行业用户提供稳定高效、安全可靠、开放兼容的新型数据服务平台,解放企业生产力,加速企业数字化转型升级。

TiDB_PingCAP 的博客 705

TiDB 8.5 LTS 发版——支持无限扩展,开启 AI 就绪新时代

TiDB 8.5 扩展了Runaway Queries 的功能,新增“处理行数”和“用量(RU)”作为识别标准,实现更精确的识别,并允许将这些 Runaway Queries 放入一个资源可控的组中,确保在高负载环境下集群的稳定性。TiDB 8.5 通过实例级执行计划缓存功能,使得同一 TiDB 实例内的所有会话共享执行计划缓存,减少SQL编译时间,从而降低整体 SQL 运行时间,提高 OLTP 的性能和吞吐量,并有效地控制内存使用,提升数据库的稳定性。

TiDB_PingCAP 的博客 776

基于时间维度水平拆分的多 TiDB 集群统一数据路由/联邦查询技术的实践

通过该组件与 TiDB 分布式数据库的有效结合,可以实现近乎无容量上限的超大规模数据管理,尤其是对于重要程度高、吞吐量大、业务敏捷性强、数据冷热特征明显的业务系统。不仅能够支撑面向内外部客户业务无损的多维度、不受分片键制约的灵活高效访问,还可以有效控制和平衡单集群的负载、容量、资源利用率、稳定性等关键指标,在不增加过多复杂性的前提下实现更强的整体扩展能力。当然,组件的现有功能更多是聚焦在当前的客户场景,未来可以按需在功能性、易用性、高性能等方面进一步优化和提升。

TiDB_PingCAP 的博客 915

Rakuten 乐天积分系统从 Cassandra 到 TiDB 的选型与实战

Rakuten 乐天是一家成立于 1997 年的日本公司,总部位于东京,员工总数超过 30,000 人,业务遍及 100 多个国家和地区。除了电商业务外,乐天还涉及电信、金融等多个行业。乐天的积分系统在日本非常普及,用户通过使用乐天的服务,如银行卡、手机卡等,可以获得积分,并在乐天商城中使用这些积分进行购物或抵扣,我们每个季度还会举办促销活动、会有大量用户高频访问积分系统,因此,乐天积分服务平台的性能、延迟和可用性要求极高。

TiDB_PingCAP 的博客 1355

平凯星辰亮相开放原子开发者大会,TiDB 荣获年度活跃开源项目奖项

12 月 20 - 21 日,以“一切为了开发者”为主题的 2024 开放原子开发者大会暨首届开源技术学术大会在武汉成功举办。平凯星辰亮相本次大会,出品 AI 时代的数据库技术发展论坛,获评“校源行”优质开源课程合作单位。由平凯星辰创立的开源分布式数据库 TiDB 获评“2024 年度数据库领域国内活跃开源项目”,7 位 TiDB 开发者获评“2024 年度数据库领域国内活跃开源开发者”,彰显了 TiDB 在开源数据库领域的卓越影响力和社区活力。

TiDB_PingCAP 的博客 606

B 站数据库负责人赵月顺:助力海内外业务增长,百套 TiDB 的选型与运维实战

B 站的 TiDB 集群规模已达到 100 多套,计算节点超过 2000 个,存储节点超过 800 个。TiDB 的应用场景非常广泛,包括视频观看、一键三连、发送弹幕、撰写评论、阅读漫画以及视频后端的存储等。B 站的 TiDB 部署采取了存算分离的策略,计算节点被部署在容器中,这种做法的优势在于能够充分发挥容器化管理无状态服务达到水平弹性拓展能力,允许根据需求随时对计算节点进行扩展或缩减,整个过程仅需一次服务发版,有效提升了效率与灵活性。存储节点则继续部署在物理机上。

TiDB_PingCAP 的博客 1234

微众银行携手平凯星辰荣膺金融科技创新奖,共同打造纳管千台服务器的大规模数据库运维平台

在过去的十年中,平凯数据库在金融行业积累了丰富的实践经验,已经在国有大型银行的 PB 级别数据服务平台、头部商业银行的核心交易系统、头部保险公司的核心保单系统、头部证券公司的核心交易系统等领域,成功完成了对国外商业数据库和 MySQL 数据库的替换升级,部署了超过 1,000 套关键业务系统,集群节点总数超过了 10,000 个。为了应对这些挑战,同时满足金融行业对高可用、高可靠、高性能数据库的需求,微众银行开发了一套完整的运维体系,打造了大规模信创原生分布式数据库智能运维平台。

TiDB_PingCAP 的博客 805

知乎 PB 级别 TiDB 数据库集群管控实践

知乎的数据库团队以“致力于提供稳定、高效和易用的数据库服务”为目标,为公司业务团队提供更好的 TiDB 存储服务来应对高并发、复杂查询和大数据存储的需求。本文详细介绍了 TiDB 的生态架构,包括核心组件、数据迁移与同步、运维与监控平台、备份与恢复、生态集成、K8s 支持、工具集和安全与审计等方面。同时探讨了知乎如何在云上和云下环境中管控 TiDB 集群,以及如何通过自研的天穹平台实现数据库平台化建设,提升业务研发团队数据库变更和 DBA 团队的资源管控效率。

TiDB_PingCAP 的博客 1180

TiDB 优化器 | 执行计划管理及实践

本文深入解析了 TiDB 优化器的执行计划生成过程及其局限性,介绍了如何通过 Hint、SQL Binding、执行计划缓存等技术手段进行执行计划管理,确保查询性能的稳定性和高效性。

TiDB_PingCAP 的博客 1315

商业银行基于容器云的分布式数据库架构设计与创新实践

本文介绍了某商业银行基于 TiDB 和 Kubernetes(简称 K8s) 构建的云化分布式数据库平台,重点解决了传统私有部署模式下的高成本、低资源利用率及运维复杂等问题。通过引入 TiDB Operator 自动化管理与容器化技术,银行能够实现多个业务系统的高可用、弹性扩展与自动化运维,极大提高了运营效率与资源利用率。本文还详细阐述了平台架构设计、面临的技术挑战及创新解决方案,展示了 TiDB 在金融行业数字化转型中的应用前景。

TiDB_PingCAP 的博客 1360

PingCAP 荣膺 2024 亚马逊云科技合作伙伴两项殊荣

近日,在 2024 亚马逊云科技 re:Invent 全球大会上,PingCAP 荣膺亚马逊云科技年度技术合作伙伴和年度亚马逊云科技 Marketplace 合作伙伴两项殊荣。这是 PingCAP 连续第二年获得亚马逊云科技年度合作伙伴奖项,彰显了 PingCAP 在与亚马逊云科技合作服务客户的过程中所展现的卓越技术实力和专业服务能力,共同推动全球用户业务取得成功。

TiDB_PingCAP 的博客 569

基于 AutoFlow 快速搭建基于 TiDB 向量搜索的本地知识库问答机器人

通过本篇文章介绍,相信大家对使用 PingCAP 开源项目 AutoFlow 实现快速搭建基于 TiDB 的本地知识库问答机器人会有一个完整的了解。如果提前准备好 Docker、TiDB 环境,整个搭建过程估计在 10 分钟左右即可完成,无须开发任何代码。文中使用一篇 TiDB 文档作为本地数据源作为示例,在实际情况中,您可以基于自己的企业环境用同样的方法快速构造企业内部知识库问答机器人。

TiDB_PingCAP 的博客 1283

TiDB 关联子查询及半连接的优化实践

TiDB 针对子查询语句会执行多种子查询相关的优化,以提升子查询的执行性能。半连接语句和关联子查询语句是常用的两类子查询,TiDB 优化器默认包含一些自动优化策略,同时 TiDB 也提供额外的 HINT 用于影响优化器在特定场景下可以选择更高效的执行计划。本文针对半连接及关联子查询语句在 TiDB 中的用法及优化技巧进行说明。

TiDB_PingCAP 的博客 1405
上一篇: 案例故事丨老虎国际 x TiDB ,降低架构复杂性,保障全球用户安全可靠投资
下一篇: PingCAP 成为中国唯一入选 Forrester Wave 数据库厂商,被评为卓越表现者
TiDB_PingCAP
TiDB_PingCAP 企业官方账号 企业官方账号
博客等级 码龄10年 2726粉丝 780原创
评论
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符
 
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付:10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值