刘奇:能否掌控复杂性,决定着分布式数据库的生死存亡
本文回顾了 PingCAP 创始人兼 CEO 刘奇在 9 月 22 日的 用户峰 会 上以《现在决定未来》为主题的演讲, 分享了 PingCAP 在技术演进、用户价值、数据库技术趋势、国际化、社会价值等方面的思考, 同时也记录了建信金科、百胜中国、传音控股、老虎国际等用户在刘奇的演讲中分享的最佳实践。全文字数约 8,800,预计阅读时间 20 分钟。
PingCAP 到今天已经成立 7 年了,在全球拥有 3,000 多家大中型用户,其中很多还参与到 TiDB 开源社区的建设中,这些情况如果放到创业之初很难想象。
今天,我们认识到做一个真正广泛应用的数据库,是一个需要以十年为时间单位进行投入的基础工程。 这一路走来离不开关心和支持 PingCAP、喜欢 TiDB 的每个人。
与客户对话,客户眼中的 TiDB
过去一段时间,在和包括日本、美国、印度、欧洲等全球客户交流时,我们试图从更多不同客户的视角去了解他们到底是怎么看待 TiDB 的。
在 TiDB 的设计里,有很多设计是从第一天就开始的,我们甚至完全不觉得这个设计有什么特别之处。直到我问一些专家型用户“你到底为什么选择 TiDB ?”时,他们告诉我: 因为 TiDB 的开放式架构可以管理复杂性。 我当时挺诧异,因为这个东西第一天就是这样设计的,已经融入 PingCAP 的血液当中,所以我们自身已经无感。但对这些专家来说,他们当中很多人在各个大公司本身就做过数据库,甚至是大型分布式系统,做过这些系统的人都会产生一个心态,那就是对“复杂性”会无比敬畏。
一个数据库,哪怕它是一个小型数据库,通常代码规模都会有几十万行,上百万行,如果是一个传统的成熟型商业数据库,那更是一个以千万行代码为单位的系统。 面对如此 复杂的系统,用户在考虑未来的迭代时,通常要做 3-5 年的规划。 如果用户需要花 3-5 年来替换一个 PB 级数据库,很大程度上意味着接下来 5-10 年的时间他就不想再动了,这也是本次峰会的主题为什么是“现在决定未来”。
今天我们做一个数据库替换的决定,它的影响周期很可能是接下来的 10-20 年。 在这个较长的周期中,大家看系统价值的时候就会看到完全不一样的价值。比如最近我意外地发现 TiDB 在 CFO 眼里其实很受欢迎,他们表示,在现有实践中,TiDB 至少可以降低一半的成本,所以 CFO 很快就会批下来对 TiDB 的部署和应用。大家可以试想一下,如果用户有 PB 级的数据,用 TiDB 替换能够省一半的成本,是不是非常有吸引力?
今天的世界充满了不确定性,在此前提下如何能更好地生存下去?省钱自然会变成一个全世界都关注的话题。
但所有这些价值的前提是接下来 5-10 年,甚至 10-20 年这个系统不能死,能持续支撑业务。这时候问题就来了, 凭什么一个系统在接下来 10-20 年间还能够支撑用户的业务?用户做架构选择最重要的标准是什么?
是整个设计团队是不是具备掌控复杂性的能力,是不是能够看到未来 10-20 年企业中的系统复杂性会朝什么方向迭代,今天在系统里做好设计,可以应对未来的高速演进和迭代,而不只是一个过渡方案,过两年还要再换。 虽然我们在设计 TiDB 的过程中,已经做了高度分离式架构,开放式 API ,但有些东西融入血液时就会无感,而在用户看来这恰恰是他们最看重的,这给了我们很大启发。
一个专家型用户跟我说: “人类几千年来应对复杂性只学会了一个道理,就是分而治之”。 这听起来好像是一个很简单的道理,回想一下会觉得他说得太对了,这也是人类几千年来应对复杂性的唯一办法。分而治之落在软件或者数据库的复杂性上面,应该是什么样的?这就是 TiDB 未来的演进方向,也是整个行业未来的演进方向。
与专家型用户不同,应用型客户又是完全不一样的观点。有些用户是做创业公司,能不能活过两三年自己也不知道。 如果选择一个东西需要花 2-3 年才能看到足够大的价值,肯定等不起,他需要更快地兑现价值。 事实上,这些应用型客户不仅仅是那些创业公司,还有很多是大公司里面的新项目。大家知道在一个大公司里经常出现一种情况,当做一个新业务时,每个人心里都清楚时间很有限,公司可能等不了用 5 年时间来做一个创新,所以怎么才能更快地释放数据价值才是他们关心的话题。
今天的数据库是一个百花齐放的状态,甚至在国内的一些场景出现了数据库“四世同堂”的局面,同时跑着大型机、小型机、x86,接下来甚至还要引入分布式数据库、云数据库,对用户而言选择一个数据库其实非常困难。
世界变化太快,很多时候用户可能是在项目进行的过程中突然有了一个新的想法。 怎么用最快的速度把这个东西做出来,并且做出来之后不用操心它是不是能扛更高的并发?如果快速把第一个原型推到线上,用户是不是可以不用操心后面的并发问题?当推到市场时立刻就能获得新的反馈,新反馈作为新需求加进来后,能不能在当天就直接提供服务?这个时候非常依赖数据库的能力,特别是当我们和越来越多的年轻人聊时,会发现他们今天已经不再关心数据库任何底层的东西。 他们只关心你有没有能力让他用最快的速度将产品或服务推向市场,在推向市场后有没有能力支持业务高速发展 ,有些用户甚至连 SQL 都不想写了。
重新思考:如何以敏捷性应对未来
所有这些对数据库的能力要求非常高,本质上我们要用数据库的能力支撑业务的敏捷性:如果要支持一个敏捷业务,那数据库本身的迭代能力是不是足够敏捷? 这让我们对敏捷产生了全新的思考。
有两个用户让我觉得特别震撼,其中一个是区块链领域的用户,通过使用区块链技术追踪区块链里的每一笔交易,如果是相同的人还可以追踪跨链的交易。这个用户在不到一年的时间里,单个集群数据量从几 TB 上涨到一百多 TB。因为 TiDB 太好用了,他会把更多的数据往 TiDB 里放,把 TiDB 作为在线服务。当你有这个想法时就会发现,你根本找不到一个其他数据库能满足这个需求;它需要在线服务、低延迟,需要从不同角度查询数据,你可以用索引、HTAP 能力,还必须要有非常强大的 SQL 能力,因为用户会不停往里面塞数据。
前两天在 Hacker News 上有一个热帖,微软云的 CTO 发了一个推特,引起了轩然大波,他说现在 C 和 C++ 这类语言被标识为过时的语言,如果大家用 Java 或者其他软件,经常会把过时的不再支持的 API 标记成过时数据。他的建议是我们应该把 C++ 标记成过时,任何项目不再用 C++ 写,应该全面使用 Rust。可能有人有印象,TiDB 在 2015 年就开始用 Rust 写存储层。但对于新用户来说,当知道我们用 Rust 和 GO 作为编程语言时,他们就会说你们好时尚,实际上这是我们 7 年前的决策。当初,Rust 还没有发布 1.0 版本,拿这个东西来写数据库简直是开玩笑。
很多时候,我们的一点创新,一点激进的动作,很可能在当初饱受非议,但在未来却可能成为主流。 PingCAP 在技术、架构上面一直会选择非常积极的创新,非常具有前瞻性的创新,这些创新甚至要在 5-7 年后才能感受到当初的选择是非常正确的。
总结来说,如果用几个词来形容 PingCAP 的成功范式,那就是自主开源+持续引领+面向未来的创新,都服务于客户成功,不管是专家型的客户还是应用型的客户,TiDB 都能够很好地去支持他们的业务更好、更敏捷地迭代发展。 TiDB 也因此成为众多行业头部用户的共同选择,助力用户业务敏捷增长。
用户分享:建信金科为什么选择与 TiDB 同行?
建信金科基础技术中心副总裁邢磊分享了建信金科如何借助 TiDB 实现业务增长敏捷性。 建信金科自关注分布式数据库以来,PingCAP 一直未离开过其视线。与大多数用户不同,建信金科与 PingCAP 的接触不是从 TiDB 开始,而是 TiKV,为什么是这样的选择?
建信金科的微服务、分布式,要求对数据做拆分,需要在现有业务不做大调整的情况下,去开启业务应对未来不确定性的能力。在这个过程中有一个绕不过去的问题,这么多传统渠道、传统业务和交易,如何在不影响现有交易模式的前提下改造后端的服务能力?TiKV 在这样的场景下进入视野,以前建信金科用的是国外开源软件,整个历程中遇到的问题和挑战非常大,也给自己的安全稳定运行带来很大挑战。
建信金科一直在思考怎么去找一个自己能掌控的技术,去解决后续将在这个领域上面对的问题。从 2020 年开始接触 TiKV,做业务场景适配,包括早期的技术、产品验证,以及双方在 TiKV 上投入研发的资源和精力,一起努力了差不多一年时间。这是建信金科做过的所有案例里耗时最长、投入最大的项目。2021 年 10 月,建信金科第一次把 TiKV 5.0.4 版接入到全行分布式体系当中,顺利扛住 4 万多 TPS 压力稳定运行,开启 TiKV 在建信金科分布式体系中的重要作用。 随着核心业务的改造,建信金科去年底将整个核心业务在分布式平台上进行切换,TiKV 起到了非常关键的作用。自 2022 年开始,建信金科更进一步借助 TiKV 的高可用体系构建了跨地域、跨中心的灾备能力。
HTAP 在金融场景的验证
传统金融企业在交易业务线、数据分析业务线的处理其实都会分开,多维查询和管理类分析业务倾向于用大数据业务处理,但随着自己的数字化转型逐步深入以及各种平台生态建设,所有的关键业务、核心业务都面临着新的挑战,这恰恰就是 HTAP 要解决的问题。这个场景用传统的大数据技术很难在数据实时更新场景下同时提供多维的分析和查询能力。在这个场景下,当时建信金科遇到非常大的挑战,留给 PingCAP 的时间非常短,从 4 月底提出到 5 月底验证,只有一个月的时间。去年 10 月正式投产进入稳定的迭代。现在,建信金科每个新的场景都会有 TiDB 的身影。
当前,建信金科正在尝试将系统升级到最新的 TiDB 6.1 版本。同时,也在将更多的统一视图、全量资产、反洗钱业务在 HTAP 上做验证和迁移。 未来,建信金科与 PingCAP 将进行联合技术创新攻关,在金融场景下更大规模业务模式的创新以及未来数据库如何更好的适应云计算趋势等方面进行更多探索。
回顾来看,为什么 PingCAP 能够在众多分布式数据库厂商中受到建信金科的持续关注?主要有三点:
第一,服务于客户成功。 数据库是一个服务于应用的产品,只有关注客户的成功,关注客户遇到的实际问题,才能够赢得更好的发展;
第二,PingCAP 的开放性。 PingCAP 从出生开始就一直以开源开放的特征存在于数据库行业,正是这一点使得建信金科更倾向于选择它,相信开源和开放的力量会成为未来企业技术重要的组成部分;
第三,成长性。 所有的技术不能光看它在当前已经取得的成就,以及当前表现出来的状态,更重要的是关注它的成长性。技术从当前的里程碑到下一个里程碑,加速度是不是足够快,如果有更快的加速度,现在所有存在的困难和差距都会在短时间内得到突破。与 PingCAP 一起,与优秀的开发者和专家一起,将取得更大的成长。
百胜中国:拥抱开源,加速创新
百胜中国首席技术官张雷分享到,百胜中国是中国最大的餐饮企业,致力于成为全球最创新的餐饮先锋。百胜中国获受肯德基、必胜客和塔可贝尔在中国内地的独家运营和授权经营权,并完全拥有小肥羊、黄记煌和 COFFii & JOY 餐饮品牌,也和意大利咖啡企业 Lavazza 合作,在中国探索和发展 Lavazza 咖啡店品牌概念。截止 2022 年 6 月底,百胜中国在中国的足迹遍布除港、澳、台之外的所有省市自治区,在 1,700 多座城镇,有 40 多万员工经营着 12,000 多家餐厅,全年客流量超 20 亿次。
2021 年,百胜中国正式启用了位于上海、南京、西安三地的数字化研发中心,这是公司打造一个充满活力的数字化生态系统的重要里程碑。由数字化研发中心、合资公司以及第三方合作伙伴组成的多层次研发体系,为公司品牌和业务进一步创新发展,加速扩张,抓住市场机遇奠定了坚实的基础。 在数字化不断发展的今天,打造敏捷高效的数字化能力,成为了餐饮企业的立身之本。
百胜中国在业内率先推出了手机点餐业务,在全国范围门店推出了数字支付,疫情期间也落地了大规模的无接触配送,百胜中国不仅持续地完善从线上点餐、外卖到会员计划、礼品卡等消费者场景,同时在餐厅内也构建了百胜自主研发的点餐和收银系统,持续打造餐饮业领先的端到端的数字化生态。
截止 2022 年 6 月底,百胜中国的线上会员数量超过了 3.85 亿,2022 年第二季度,数字化订单占比达到了 89%,会员营销额也约占到了系统销售额的 62%。百胜中国也不断利用数字化能力赋能门店运营,例如基于数据和 AI 能力,构建了餐饮行业特有的营运大脑以及口袋经理,为门店运营效能的提升提供了数据以及系统支撑。同时也聚焦自动化、IoT 及智能餐厅等领域,基于当前不断蓬勃发展的大数据、云计算等基础能力,借助于百胜中国自己的研发中心、合资公司以及第三方合作伙伴,共同为百胜中国两万家餐厅的目标夯实牢固的数字化基础。
百胜的生态环境中拥有丰富的应用场景,让各种技术能力有生根落地的机会。 同时随着企业数字化转型进入了深水区,对于数字化基础设施的自主可控性和灵活性的要求也进一步在提升。开源软件起到了越来越重要的作用,成为企业创新实践的催化剂。
基于开源基础软件体系,可以提升企业 IT 技术的标准化;活跃的开源社区,也可以有效帮助企业降低试错成本。当企业投入一定的资源协助开源社区建设时,能够同步提升自主的技术品牌和技术人才的能力以及影响力。TiDB 是业内开源分布式数据库的翘楚,百胜中国在 2019 年就开始了前期研究,以尝试替代传统的商业数据库产品。 百胜中国非常看重核心数据的处理主权,开源数据库恰恰能够帮助掌握这一主权,同时借助活跃的开源社区,进行企业内部创新性的架构研究以及落地。
经过大概一年的探索,TiDB 最终在百胜的业务中台,例如消息中台、用户中台以及支付中台中得以落地实施,用于支撑百胜中国的线上交易。 TiDB 对于百胜中国的海量数据提供了稳定可靠的系统支持。众所周知,由于餐饮行业存在着明显的高低峰场景,目前像肯德基“疯狂星期四”,它的交易量是远超平常的,TiDB 的灵活水平扩展能力,使得百胜中国可以根据业务的需求进行计算资源实时调整,助力降本增效。
同时,在社群营销、ERP 报表等典型分析场景中 TiDB 的 HTAP 特性,也使得百胜中国可以以较小的代价进行海量数据的在线融合分析,以实现敏捷的业务支撑,百胜中国将 ERP 中的交易数据同步到 TiDB 中,再与 BI 工具进行集成,大幅缩短了企业内部的财务报表生成时间,极大提升了内部的工作效率。随着云原生和开源技术的持续发展,百胜中国不断加强各种新型开源技术的深度探索、应用以及融合,从而更有力地推动餐饮垂直行业云能力以及自我创新的发展。
本次峰会中, PingCAP 与百胜中国强强联合,成立“百胜中国 ✖️ PingCAP 分布式数据库联合实验室”。 联合实验室立足于双方的技术和生态优势,共同探索前瞻技术的创新和落地实践,提升餐饮行业的数字化服务水平和能力。
其实不只是建信金科与百胜中国,今天 TiDB 已经支撑了很多人一天 24 小时各种各样的生活需求,融入了人们的日常生活中。
在软件领域有一句经典的话,“Make it work, make it right, make it fast”,TiDB 今天就在 make it fast 的阶段。随着 TiDB 架构本身的分离做得越来越好,TiDB 架构的正确性会让性能提升和改进非常惊人。一个正确的内核才有成长的可能和更高的成长性。在过去一年的时间里,PingCAP 在核心场景 OLTP 领域获得了显著的性能提升。
新物种:聊聊 HTAP
我在和客户聊的时候发现,HTAP 是一个很难讲明白的技术,它和 Hadoop 有什么区别?原来的大数据非常重,像是一只大象,相较之下 OLTP 数据库就像一条蛇,很灵活很快速,它不是加法,而是融合,是一个全新的物种。
但关于 HTAP 的挑战并没有解决,到底什么叫 HTAP?有没有一个例子能让用户一下子明白?TiDB 能干什么别人干不了的事吗?我们做了一个 DEMO,试图在 5 分钟内讲明白到底什么是 HTAP,到底 HTAP 能带来什么样的价值。
一个好的 DEMO 应该具备什么特点?第一得好看,第二得好用,我们的 DEMO 除了好看、好用,还得好玩。这个 DEMO 所有数据都是真实的,并且一秒就能体验。我们也希望将这个 DEMO 开源出来分享给其他伙伴,这也非常符合 PingCAP 开源的理念。
有一位用户曾经问我们 “用 HTAP 前后有什么差别?”,有一个非常直观的体验:OSS Insight 第一版只用了两个人,一个周末就做出来了。如果是传统方案,通常要用 4-6 个人,花半年时间。
这个事情给了我们另外一个启发, 每个人都有好奇心,每个人都有自己洞察的视角,每个好奇的灵魂都值得用 Insight 去激发。 这之前,我们只能看非常冰冷的 TPCC、TPCH 等和业务看起来一点关系都没有的东西,对新一代程序员来说这简直是上古语言。产品的价值能不能和用户的挑战结合起来?业务创新的敏捷性又依赖于数据敏捷。
最近一段时间脱口秀比较火,人人都能说 5 分钟的脱口秀。通过 OSS Insight ,我们可以让人人都能在 5 秒钟内获得 Insight 。我们设想每一个组织、每一个企业、每一个人都可以获得这个能力,都有这个好奇心去获取 Insight,像我们 700 人的企业就有 700 个脑袋。OSS Insight 中都是开源数据,任何一个人去看都能提出自己的 idea。
通常情况下,用户接下来的问题会是:到底有什么场景不是你的舒适区?我们根据所有线上用户真实的情况,画了下面这张图,大致描述了 TiDB 的舒适区到底在哪里。
HTAP 已死?
在我们和用户聊的时候,经常有用户说 HTAP 这个概念已经听了 8-9 年,为什么一直没有火?甚至以为 HTAP 已经死了。 如果按照它原来的定义,HTAP 确实已经死了 。
HTAP 原来的形态基于两个基础假设:一个是内存即硬盘。十年前,“内存是新一代的磁盘”这一说法被炒得火热,如果真是这样,每台机器上现在都可以拥有 1 PB 以上的内存。但现在大家看到内存依然很贵,这意味着当时 HTAP 的第一个假设,内存足够大足够便宜,被证明是不现实的;另外一个是摩尔定律,过去当 CPU 高速发展的时候,我们对摩尔定律充满期待,而显然过去十年 CPU 发展速度让我们很失望,所以当时的两个基础到今天都不存在了。
但有一句话说得好, “科学的每一次进步都是在葬礼上取得的”; 上一个 HTAP 已经死了,为什么 PingCAP 还在坚持 HTAP ?最近 HTAP 又很火的样子,这是为什么呢?
实际上,关于足够大的内存和硬盘,足够多的 CPU 和算力,如今都可以通过云的方式来得到,在云上你可以拥有近乎无限的内存。今天用户的使用习惯也产生了改变,用户希望在一个系统里面能存储足够多的数据,足够快地处理事务。所以, 一个强大的 OLTP 能力是 HTAP 的基础,但凡不具备这个基础就不能称之为 HTAP。
在这个背景下,HTAP 重生了。 过去一年里, MySQL 发布了 HeatWave 作为 MySQL 的 HTAP 解决方案,Google 也在今年发布了 AlloyDB ,不久前 Snowflake 也发布了它的 HTAP 引擎 Unistore。
我们认为 HTAP 带给用户的体验就是简单 + 实时,同时还要求整个系统具备非常强的隔离性。 共享一份资源会面临较大挑战,因为它会吃掉大量的 OLTP 资源,所以物理隔离是 HTAP 的基础。 TiDB 的架构很直接地展示了这个能力,当我们完全是物理隔离的时候,TiDB 的执行计划会很智能地从 OLTP 中选择这部分数据。 TiDB 在过去发展过程中,最早是作为一个业务数据库在用,随着里面数据越来越多,一定程度上它就变成了一个实时数据服务层。 各种各样的业务系统开始把 TiDB 作为中间层提供彼此交互的能力,比如 CRM 不能和 ERP 直接对话,但通过 TiDB 把数据聚集在一起,它们就可以直接对话了。
持续引领数据服务的敏捷性
TiDB 在持续引领数据库的演进方向,我们相信在接下来 2-3 年的时间里,会有越来越多的数据库加入这个队伍,朝着共同的方向去迭代和演进。
未来的方向一定是数据库微服务化。 这表面看起来有点奇怪,为什么数据库要微服务化?微服务和数据库有什么关系?我们认为,今天的数据库不仅仅是数据库的一个内核,它已经是一套复杂系统,前面提到的掌控复杂性的方法只有一个,那就是分而治之。
微服务化本质上会达到一个效果,让规模化效应开始掌控一切,最后带来的结果和用户的价值,可以大幅压低用户使用成本。 目前,TiDB Cloud 在过去一年中通过持续孵化改造,成本已经降到了原来的
1/10。一个很简单的例子,今天每一个数据库都有一个能力叫 GC,如果每一台服务器都去 配这样一个能力,要么压力大的时候不够用,要么完全浪费了,但是这个功能又不得不配上。比较好的办法是让这个 GC 也能够规模化,使它本身变成微服务。数据压缩、持续后台优化都是这样,我们不能用原来的系统资源去做,用户希望花钱买的每一份计算资源都是为他服务,而不是用 1/3 来做后台服务。
连接中国与世界
在全球,TiDB 一直发挥着连接中国和全世界的作用。 为什么那么多的用户、合作伙伴会选择我们?开源、云中立以及全球合规,就是 TiDB 起到的连接作用。
同时,PingCAP 有大量的应用场景也是连接全球的,上图可以看到今天 TiDB 已经被用到了全球各行各业。每一个场景里都有中国的用户,也有来自美国、日本、新加坡、欧洲和印度的用户。
基于中国全球领先的场景,基于开源非常高效透明的传播与协作模式,基于开源汇聚全球的智慧,最终使得 PingCAP 得到全球更多的客户与合作伙伴的信任。
用户分享:传音携手 PingCAP 打造全新数字化非洲土壤
传音控股是一家致力于成为新兴市场消费者最喜爱的智能终端产品和移动互联服务提供商,在与 PingCAP 的合作中,将其移动商店的整体服务架构迁移到了 TiDB 上。传音控股移动互联 CTO 史团委表示, PingCAP 使得传音控股可以将更多资源投入在业务的推进上,从中后台工作中解放出来,大幅降低成本 。TiDB 的水平扩展、故障自恢复、数据强一致性、高度兼容性等特点,帮助传音控股实现了技术进阶,提升了用户体验,加速了技术架构平台化与垂直化的演进。
用户分享:老虎国际 - 只有真正的全球化公司 才能服务全球化客户
老虎国际作为全球知名的国际化券商,在新加坡、美国、中国香港、澳大利亚等地持有 59 张牌照或资质,在全球多地开展业务。老虎国际技术副总裁柳锴表示,只有真正的全球化公司才能服务全球化客户。基于全球化的业务,老虎国际的数据架构、数据安全等也面临着全球化的挑战。 TiDB 可以解决系统架构的复杂度,同时通过低延迟、数据强一致性,解决业务挑战与数据安全挑战。
技术人如何创造社会价值?
作为一个技术人员,我们一直在想一个问题, 作为一家企业怎么创造社会价值,怎么做更多的贡献? PingCAP 最早从开源起家,把所有一切能开源的东西都开源了,开源始终融在我们的基因里。
作为数据库从业人员,作为数据库的开发者,我记得上大学时还没有一个非常好的数据库教程。那时数据库依然没有办法做到足够的平民化,并不是每一个人、每一个开发者都能拥有一个永远在线的数据库。所以当时我就有一个想法,以后一定要让数据库变得触手可及,让每个人都可以拥有自己的数据库。为了让 TiDB 触手可及,我们做了很多事情,推出了自己的 Talent Plan,与 VLDB 合作,所有的一切都是希望让数据库变得触手可及。同时这也帮我们带来了非常繁荣、多样化的社区, 目前已有 1, 895 位 Contributor, 覆盖 45 个国家与地区。
说到触手可及,最要紧的一件事情就是成本。随着 TiDB 的新一代分布式架构和规模化效应,今天我们终于能够让每一个开发者都可以拥有一个永远在线的免费的数据库,我们可以随时去体验这个数据库,这就是新的架构带来的成本优势。
在过去的 7 年中,PingCAP 一路走来磕磕绊绊,我一直在想能不能把这些经验教训也都开源出来?今天我们非常高兴地宣布,经过半年多的集体创作,我们将过去 7 年的那些经历、经验和教训,也开源出来,首发《与开源同行》这本书,希望大家喜欢,继续与 PingCAP 同行。
最后,TiDB Hackathon 是我最期待的一年一度的技术盛会,也期待你的加入。
- TiDB 6.5 新特性解析丨过去一年,我们是如何让 TiFlash 高效又稳定地榨干 CPU?
- TiDB 在安信证券资产中心与极速交易场景的实践
- 微众银行 TiDB HTAP 和自动化运维实践
- PingCAP 副总裁刘松 :“ Serverless 化” 即将成为数据库的下一个变革性技术
- TiCDC 源码阅读(四)TiCDC Scheduler 工作原理解析
- Hackathon 实用指南丨快速给 TiDB 新增一个功能
- Hackathon idea 清单出炉,总有一款适合你
- TiDB Hackathon 2022丨总奖金池超 35 万!邀你唤醒代码世界的更多可能性!
- 刘奇:能否掌控复杂性,决定着分布式数据库的生死存亡
- TiFlash 源码阅读(九)TiFlash 中常用算子的设计与实现
- TiFlash 源码阅读(八)TiFlash 表达式的实现与设计
- 如何在 TiDB Cloud 上使用 Databricks 进行数据分析 | TiDB Cloud 使用指南
- TiFlash 源码阅读(五) DeltaTree 存储引擎设计及实现分析 - Part 2
- 深入解析 TiFlash丨面向编译器的自动向量化加速
- TiFlash 源码阅读(四)TiFlash DDL 模块设计及实现分析
- TiDB v6.0.0 (DMR) :缓存表初试丨TiDB Book Rush
- TiFlash 函数下推必知必会丨十分钟成为 TiFlash Contributor
- TiDB 6.0 实战分享丨内存悲观锁原理浅析与实践
- TiDB 6.1 发版:LTS 版本来了
- TiDB 6.0 实战分享丨冷热存储分离解决方案