{
    "componentChunkName": "component---src-templates-company-news-detail-tsx",
    "path": "/about-us/company-news-detail/tidb-5.3-ga-is-now",
    "result": {"pageContext":{"companyNewsDetail":{"id":"About-us-news_27","title":"持续引领一栈式数据服务 PingCAP 发布 TiDB 5.3  版本","customUrl":"tidb-5.3-ga-is-now","image":{"alt":"TiDB 5.3 发布","media":{"url":"https://img1.www.pingcap.com/prod/Ti_DB_5_3_0bd67d050f.jpg"}},"date":"2021-11-30","body":"2021 年 11 月 30 日，企业级开源分布式数据库厂商 PingCAP 正式发布 TiDB 5.3 版本。TiDB 在规模化联机交易和实时分析能力两大领域实现快速的迭代创新，TiDB 5.3 版本中 HTAP 架构的性能和稳定性取得显著提升，系统可观测性得到进一步增强，生态工具提速为 MySQL 用户带来重磅福利，累计优化和更新 40 多项功能，以“一栈式数据服务平台”帮助企业用户更好地应对双十一等海量数据严苛场景下的挑战。  \n\n![TiDB 5.3 发布.jpg](https://img1.www.pingcap.com/prod/Ti_DB_5_3_0bd67d050f.jpg)\n\n## HTAP 架构的性能和稳定性取得显著提升\n\n在数字化转型的过程中，企业对“海量、实时、在线”的数据需求变得更加迫切，企业中的任意人在任意时间、任意地点对任意形态的数据都可能产生消费的需求，作为 HTAP （Hybrid Transactional/Analytical Processing，即混合事务 / 分析处理）数据库的引领者，TiDB 用“一栈式数据服务平台”应对企业规模化交易和实时分析的需求，提升关键业务的时效性，降低数据技术栈的复杂性。  \n\n自 TiDB 5.0 版本 HTAP 架构发布以来，已经广泛地应用到金融、物流、零售、新经济等行业头部用户的风控、反欺诈、实时数据中台、实时数仓等场景。在小红书反欺诈数据分析场景中，面对单表破 50 亿的数据规模，TiDB HTAP 实时查询技能发挥稳定，分钟级呈现促销发放优惠券的使用与分发情况。汽车之家把 TiDB HTAP 应用于个性化营销场景，根据用户画像实时推荐喜好信息与促销信息推荐，相较 MySQL 聚合场景效能提升 20-50 倍。  \n\n得益于开源社区大量真实场景的验证与反馈，5.3 版本对 TiFlash 列式存储引擎进行了大幅深层优化，如调整存储引擎底层文件结构和 IO 模型，优化访问不同节点副本和文件区块的计划等。新版本中 TiFlash 支持更多的函数（涵盖字符串、时间和其他计算）下推到 MPP 引擎，提升了分布式计算时远程数据的读取效率，消除了高负载条件下数据等待造成内部进程超时引起的例外和任务失败。此外，数据校验的完善、SQL 告警信息和日志收集的优化提升了集群的综合运维能力。  \n\nTiDB HTAP 架构可随数据量和业务增长轻松扩展到 200 节点以上的大规模集群，并且做到 OLTP 和 OLAP 负载隔离互不影响，在双十一等读写压力双高的极致场景下提供性能优异、可靠稳定的服务。经实际验证，TiDB 5.3 版本在金融、物流等超高吞吐实时在线交易场景下读写混合负载的综合性能，提升幅度可达 50%～100% ，并大幅度降低了同等负载下 CPU、内存资源使用率以及由于 IO 阻塞等待造成的查询失败概率。  \n\n## 系统可观测性进一步增强\n\n分布式系统的可观测性成为基础软件设计的重要方向，TiDB 一直以来致力于通过技术手段描绘分布式系统的全貌，帮助技术人员快速诊断系统的健康状态，从而降低业务风险。  \n\nTiDB 5.3 版本的 TiDB Dashborad 新增持续性能分析（Continuous Profiling）功能，提供在集群运行状态下（包括故障状态）自动保存实例性能分析结果的能力，为用户带来数据库源码水平的性能洞察，让原本“黑盒”的数据库变成“白盒”。用户可通过火焰图进行快速的故障排查和定位，故障诊断时间缩短 50% 以上。持续性能分析提供对 TiDB、PD 和 TiKV 节点持续的性能分析并保存结果，功能开启后对集群读写损耗低于 0.5%，对业务不构成影响。  \n\n某银行技术负责人反馈：在分布式数据库选型 POC 测试中，某些业务的查询语句响应时间不达预期，分布式数据库厂商往往需要花费 1-2 天的时间进行大规模的性能排查。通过使用 TiDB 的持续性能分析功能，仅需 30分钟就能定位到性能瓶颈，为全链路的快速调优奠定了基础。  \n\n## 生态工具提速为 MySQL 用户带来重磅福利  \n\nTiDB 经常被用户比喻为”加大号的 MySQL”，当 MySQL 遇到容量和性能瓶颈的时候，可以轻松迁移到 TiDB 实现性能和容量的弹性扩展，减少分库分表对业务的侵入以及繁琐的运维工作，让 MySQL 用户即刻享受到 TiDB 实时查询分析的红利。  \n\nTiDB Data Migration (DM) 是一款实时数据同步工具，支持数据从与 MySQL 协议兼容的数据库同步到 TiDB。在 5.3 版本中，DM 在合并单行数据的多次变更、点查更新合并为批量操作等方面进行了多项优化，使得分库分表 MySQL 同步至 TiDB 的延迟大幅降低，保障了下游 TiDB 数据查询实时性，企业无需进行大规模数据架构的改造就能快速引入 TiDB 以增强实时查询分析效率。经场景实测，在 300K QPS 数据同步流量下，99.9% 时间内上下游同步延迟降低至 1 秒以内，尤其适用于高负载业务压力下 TiDB 作为只读从库的场景。  \n\nTiDB 5.3 版本中，TiDB Lingtning 实现了全量数据迁移的再提速，为 MySQL 分库分表架构上超过 100 TB 规模的业务迁移到 TiDB 提供了升级版方案。新版本 TiDB Lingtning 具备水平扩展能力，支持用户同时部署多个 Lightning，并行地将单表或者多表数据迁移 TiDB。例如：在升级后，上游为 10 个分表 MySQL 集群，数据总规模 10 TB，使用 5 个 Lightning 实例并行导入，导入速度较上个版本提升 400% 以上。  \n\n除了上述三大方向的突破和升级之外，新版本 TiDB 对分布式事务一致性的核心组件分布式时间戳（TSO）的处理流程进行了深度优化，在保障分布式事务线性一致性的前提下降低时间戳获取延迟，以更好地支撑百 TB 以及百万 QPS 超大规模集群的扩展，优化后集群整体 QPS 吞吐实现 100% 以上的提升。  \n\nTiDB 5.3 版本还引入了临时表功能，提供 Global 和 Local 两类临时表来缓存业务的中间历史数据，计算完成后临时表可实现自动的清理回收。一条 SQL 即可轻松创建临时表，高效地解决了业务中间计算结果的临时存储问题，帮助用户简化业务逻辑并提升性能。  \n\nPingCAP 首席架构师唐刘表示：TiDB HTAP 的使命不仅仅局限于对传统数据库的升级或者是交易和分析处理性能的提升，本质上 TiDB HTAP 是一个开放的生态体系，在企业中承担着支持数据服务消费化和构建统一实时数据服务平台的角色，为用户带来业务与架构的创新与提升。本次发布的 5.3 版本是 TiDB 迈向成熟企业级 HTAP 平台的一个重要里程碑，越来越多的企业希望通过“一栈式数据服务平台”简化数据技术栈，提升业务的实时洞察能力，用户只需要掌握最基础的 SQL 语言能力和数据分析能力就可以驱动业务决策。\n\n更多 TiDB 5.3 版本新功能，请查阅 TiDB 官网 [Release Notes](https://docs.pingcap.com/zh/tidb/stable/release-5.3.0)，\n立即[下载试用](https://pingcap.com/zh/product)，开启 TiDB 体验之旅。","author":{"name":"PingCAP","description":""},"type":"detail"},"prev":{"id":"About-us-news_28","title":"平凯星辰联合创始人兼 CTO 黄东旭受邀参与促进北京开源产业发展座谈会","customUrl":"promote-beijing-open-source-industry-development-seminar","image":{"alt":"促进北京开源产业发展座谈会","media":{"url":"https://img1.www.pingcap.com/prod/_0d06437481.png"}},"date":"2021-12-08","body":"2021 年 12 月 5 日，工信部信息技术发展司、北京市经济和信息化局组织的“促进北京开源产业发展座谈会”在京召开。工信部信息技术发展司司长谢少峰、北京市经济和信息化局党组书记、局长杨秀玲，中国科学院院士、国防科技大学教授王怀民及北京市丰台区、朝阳区以及中关村管委会、经济技术开发区管委会等单位有关领导出席会议。作为唯一受邀的创业公司代表，企业级开源分布式数据库厂商平凯星辰联合创始人兼 CTO 黄东旭参会并发言。同时参会的还有清华大学、北京大学、阿里、百度、腾讯等高校及科研机构的专家、企业代表。\n\n本次座谈会旨在推动产学研用各方参与共建，加快打造开源开放、协同共生、合作共赢的开源生态，促进北京市开源产业发展。平凯星辰联合创始人兼 CTO 黄东旭围绕着我国开源产业发展的机遇和挑战、开源生态要素和建设思路等几个方面介绍了平凯星辰在成立之初就坚持开源路径的经验及发展中的思考。\n\n![北京开源产业发展座谈会.png](https://img1.www.pingcap.com/prod/_0d06437481.png)\n\n对于开源产业发展机遇和挑战的话题，黄东旭表示：“我国已经进入极致应用场景红利、数据红利以及新一代工程师红利聚合爆发的时代，这是我国开源产业发展面临的战略机遇。” 同时，他结合平凯星辰自身实践经验提出**要保持开源生态长期的健康与可持续，开源企业从成立之初就要把开源作为公司长期战略，推动全方位开源，以此实现长期的资源投入，不被短期的商业利益所左右**。把产品研发体系建立在开源体系和开源社区的基础上，公司的治理体系也要为持续丰富的开源生态服务，而不仅是源代码开放。\n\n在开源生态要素的建设思路方面，黄东旭认为：“首先要倡导和发扬开放、共享、社区化协作的开源文化，遵循其发展规律；其次，完善相关的法律法规是建设开源生态的重要保障。”\n\n此外，他还指出值得注意的是开源生态的繁荣离不开开源创新主体的积极参与，近年来越来越多优秀的开源项目是由创业公司创造和引领的，中小型企业正在逐渐成为开源创新的主力军。以软件服务行业为例，MongoDB、Kafka、Elastic 等一批世界级的开源产品，在成长之初都是由开源创业公司打造的。平凯星辰虽然从体量上看还只是一家创业企业，但在《GitHub 2020年数字化洞察力报告》 中显示，其核心产品 TiDB 在 “2020 年 GitHub 上 20 个最活跃的中国开源项目”位列第一名；同时国内权威的\"墨天轮国产数据库排行榜\"上 TiDB 连续 23 个月排名第一。平凯星辰共计服务全球超过 2000 家企业用户，涉及金融、运营商、制造、零售、互联网、政府等多个行业。\n\n最后，他强调人才也是开源生态的核心要素。平凯星辰以贡献者的参与感和荣誉感作为核心要素，打造了“人尽其才”的自治开源社区，目前平凯星辰数据库产品 TiDB 在 GitHub 上已经获得超过 29800 个 Star。\n\n座谈上，北京市各区与会领导表示，希望和开源业界加强沟通合作，共同推动北京开源产业发展。\n\n\n\n","author":{"name":"PingCAP","description":""},"type":"detail"},"next":{"id":"About-us-news_24","title":"DTCC 2021 黄东旭：从 DB 到 DBaaS，数据库技术的当前和未来","customUrl":"dtcc-2021-from-db-to-dbaas","image":{"alt":"DTCC 封面图","media":{"url":"https://img1.www.pingcap.com/prod/DTCC_f84f0bdd4a.jpeg"}},"date":"2021-10-26","body":"10 月 18 日~ 20 日，第 12 届中国数据库技术大会（DTCC2021）在北京国际会议中心隆重召开。PingCAP 联合创始人兼 CTO 黄东旭受邀在主会场进行了以 **“TiDB Cloud：from Product to Platform”** 为主题的演讲，分享了云原生时代数据库产品平台化的重要性，以及 TiDB 从 DB 到 DBaaS 的经验和体会。以下为分享实录。\n\n在最近数据库行业的发展中，比起 “代码写得好不好” 这样的工程技术问题，科学问题更加突出：有一件事情非常深刻地改变了整个数据库的行业，那就是数据库底层发生了变化。\n\n以往大家去思考数据库软件和系统软件，都会先做一个假设：软件是跑在计算机等具体的硬件上的，即使是分布式数据库，每个节点都还是一个普通的计算机。现在这个假设改变了：我们的下一代到能够学编程或者写代码的年纪，不会再像我们现在这样能够看到 CPU、硬盘、网络，他们看到的可能就是 AWS 提供的一个 S3 的 API 。其实这种改变并不仅是软件载体的改变，更重要的是架构、编程的底层逻辑发生了变化。\n\n云对基础设施和软件的影响和改变是深远的。具体到 PingCAP 身上，最大的感受就是比起做数据库内核， 现在在云上做 TiDB Cloud 服务的投入可能多得多。这也是我今天要分享的主题，**From Product to Platform —— 从 DB 到 DBaaS，数据库技术的当前和未来**。\n\n## PingCAP 的创业初心\n\n![数据库发展.webp](https://img1.www.pingcap.com/prod/_65ed4920ea.webp)\n\n上图是我理解的数据库发展历程。追溯到十几年前，我们开始使用单机 MySQL，这个时期我们对数据库的需求只有朴素的增删改查，2010 年前后直到今天，爆发的数据量让单机数据库难以为继，大家只能通过分库分表或者中间件来实现分布式部署。\n\n![NewSQL.jpg](https://img1.www.pingcap.com/prod/New_SQL_992475a33a.jpg) \n\n然而分库分表对业务的入侵性太大，那能不能有这样一个数据库，用起来和单机 MySQL 一样简单，但是扩容时不需要考虑分片，而是**通过系统本身的机制来实现弹性、舒适、业务无入侵的拓展**？这就是 PingCAP 创业的初心。\n\nPingCAP 创业六年多以来，为了达成这个小目标，也**总结了几点心得**：\n\n### 易用优先：协议大于实现\n\nMySQL 协议比 MySQL 具体软件更重要。如果一款数据库能够兼容 MySQL 协议，能让用户在数据库的选型过程中无需考虑对应用和业务的影响，就能拥有最大的用户群。我们无需发明一种新的使用方式，就像电动车还是会通过方向盘和油门来操控，虽然引擎下的世界和汽油车完全不同。\n\n### 用户体验优先\n\n数据库的性能指标比如 TPS、QPS 等固然重要，但是用户的体验才是一款数据库成功的关键。因此，TiDB 在做所有技术决策的时候都是通过用户体验（Usability matters）来判断。从我过去的经验来看，许多互联网公司需要维护的数据库种类非常多，每启用一种新的数据库就会多一个数据孤岛。因此，在满足用户数据处理需求的同时，简化的技术栈可能才是真正的用户痛点。无论是 OLTP、OLAP 还是 HTAP，TiDB 希望做的事就是让大家的生活变得好一点。\n\n### 开源优先\n\n![开源优先.webp](https://img1.www.pingcap.com/prod/_249fcbf521.webp)\n\nPingCAP 始终坚持开源战略，也因此受益颇多。\n\n从**生态**角度，开源的研发模式能够迅速积累用户。TiDB 1.0 版本 2017 年 11 月发布，从诞生到现在，我们知道名字的用户有 2000 多家，贡献者有 1500 多个，CNCF 开源组织的 Contribution Rank 中，PingCAP 排名全球第六。\n\n![代码迭代.webp](https://img1.www.pingcap.com/prod/_00c6195299.webp)\n\n从**技术**角度，开源加速了产品的迭代速度。这张图的纵轴是代码量，横轴是时间，不同色块是代表某一年写的代码量。从图中我们能够看出，基本上每年 TiDB 的代码都在被重写，几乎没有一年是跟去年的代码一样。这个迭代的速度就是通过开源社区来实现的，是任何一个团队、任何一个公司、任何一个企业从头开始做一个数据库都无法达到的进化速度。\n\n## Why DBaaS\n\nTiDB 的产品能力不是今天分享的重点，我今天想谈的是把一个产品变成云服务到底有多重要。首先抛出一个最终结论，现在这个时代对 CIO 尤其是海外的客户来说，数据库产品对云的适配成为了一个必选项。\n\n![DBaaS.webp](https://img1.www.pingcap.com/prod/D_Baa_S_a3dcd3562f.webp)\n\n现在我们正好站在时代的交界点上。从技术上来讲，数据库的发展就是从 Standalone（单机）到 Cloud-Native（云原生）的进程。现在我们处在第二条红线的位置，就是从 Shared-Nothing 到 Cloud-Native 的边界。从商业角度看，整个数据库和基础软件行业的商业模式也正在发生特别大的变化：过去我们希望通过售卖 license 进行私有化部署，到现在希望能够实现规模化的扩张，这也正是 On-Prem 到 DBaaS 变革。\n\n作为一家成功将数据库商业化的公司，MongoDB 走出了一条很有代表性的道路。MongoDB 每年的市值都在翻番，现在已经到达了 300 多亿美金。从 MongoDB 的财报可以看出，DBaaS 产品 MongoDB Atlas 基本上每年都保持着超过 100% 的年复合增长率，这就是云服务的价值所在。\n\n## TiDB 在云上的平台化之路\n\n最近两年我也重新定义了一下我们的愿景和使命：**全世界的开发者享受到我们的服务，Anywhere with Any Scale**。\n\n想要实现这个目标，从 DB 到 DBaaS 是个必选项。只有云上的服务才能突破地域的限制，并提供无限的算力。从 DB 到 DBaaS，远不止将底层资源换成云这么简单，需要考虑的还有很多。技术上，要实现降本增效、运维自动化、多租户管理，合规上要考虑数据安全，商业上，计价模式、商业化策略等都是需要纳入考虑的范围。接下来我将从技术角度谈谈 TiDB 在 DBaaS 进程中付出的努力。\n\n### 成本节约：分离的架构设计\n\n云原生技术最终要解决的就是**成本**的问题。\n\n![TiDB 架构.webp](https://img1.www.pingcap.com/prod/Ti_DB_f3dbcde4a0.webp)\n\n在过去，TiDB 有一个 TiDB + TiKV 的协处理引擎，计算和存储的边界是非常模糊的，很难处理不同负载率的场景。本地部署的情况下，如果需要增加存储容量，就需要增加存储节点，因为硬件的限制，除了磁盘，CPU 及网络带宽也会同步增加，这就造成了资源的浪费，这是所有 Shared-Nothing 的数据库都要面临的问题。\n\n![Shared nothing.webp](https://img1.www.pingcap.com/prod/Shared_nothing_5fe4c7753a.webp)\n\n而到了云上，一切就截然不同。比如 AWS 的块存储设备的服务 EBS，特别是 GP3 系列，能够在不同的机器上运行，且达到同样的 IOPS 和 Cost，性能和对云原生的整合都非常好。为了利用 GP3 的特性，我们是否可以把计算和存储的边界往下移，从原来的 TiKV 到存储，到现在 TiDB、TiKV 的大部分都可以是计算单元，更加灵活。\n\n云带来的成本节约不止于此。云上真正值钱的东西是 CPU，瓶颈会是计算，而不是容量。集群和实例可以基于资源共享池进行优化（Spot instances & Clusters based on shared resource pools）、按需选择存储服务的类型、对不同类型的 EC2 实例在特定场景组合交付、无服务器计算、弹性的计算资源都将成为可能。\n\n此外，根据我的判断，除了计算存储分离，网络、内存，甚至 CPU 缓存都会是分离的。因为对一个应用程序来说，尤其是分布式程序，硬件资源的要求是不一样的。不管是做什么业务，就像做菜一样，手上只有一颗菜肯定做不出什么花来，但原材料很多，就可以按照口味去做组合，云带来的就是这样的机会。\n\n### 安全性\n\n除了成本，云的安全性也是重要课题。TiDB 官方支持的公有云是 AWS 和 GCP。云上网络用户使用的都是自己的 VPC，中间也会有 VPC Peering 打通的环节，我们看不到用户的数据，但用户可以很高性能地访问自己的业务，安全性要怎么保证？\n\n![TiDB安全体系.webp](https://img1.www.pingcap.com/prod/Ti_DB_8e64f07dd6.webp)\n\n图中是 TiDB 的安全体系，云上的安全体系和我们云下的思考完全不同。举个特别简单的例子：云下只需要考虑 RBAC 数据库内部的权限，但在云上就非常复杂，需要考虑从网络到存储一整套的用户健全安全的体系。做好云上安全的关键点是千万不要自己重复发明，因为基本都有安全漏洞。所以我们现在就是要充分利用云本身提供的一套完整的安全机制，比如密钥管理和规则等。当然，最好的地方都是这些服务都能够明码标价，只要做出计费模型就好了。\n\n### 运维自动化\n\n关于 DBaaS 的构建还有一点很重要，其实也和成本有关，就是运维自动化。云是一个规模化的生意，而现在国内数据库生意最麻烦的部分之一就是交付。一个大客户恨不得派二十个人驻场，但这件事情可持续吗？。我们要实现的就是可以通过 10 个人的交付团队去支持有 1000 个客户的系统，这是规模化的前提。\n\n![TiDB云服务技术选型.webp](https://img1.www.pingcap.com/prod/Ti_DB_b83e70a0ae.webp)\n\n这些是 TiDB 自己的云服务技术选型，通过 Kubernetes 实现云上部署，通过 Gardener 进行联邦管理，管控多个 Kubernetes 集群，Pulumi 是一个基础架构即代码的自动化工具。\n\n#### Kubernetes\n\n要把 TiDB 变成云服务总共分为几步？第一步就是人肉运维全部变成代码。TiDB 要扩容了，不要人肉扩容，系统自己能不能扩容？TiDB 故障恢复，人参与不了，机器能不能参与？我们把所有 TiDB 的运维全部变成了 Kubernetes Operator，相当于我们实现了自动运维 TiDB。Kubernetes 能够屏蔽所有云厂商的接口复杂性，每个云厂商都会提供 Kubernetes 服务。\n\n#### Pulumi\n\n刚才说过这些东西的部署、运维、调度的逻辑，如果都是靠人写脚本，一是不稳定，二是不可维护。我们的理念就是只要能够变成代码的东西就固化下来，千万不要依赖人，包括去开一个服务器，或者去买一个虚拟机，我们都会把它变成 Pulumi 编程语言的脚本。\n\n#### Gardener\n\nTiDB 通过 Gardener 的 API 来管控多个不同 Region 里的 Kubernetes 集群，每个 Kubernetes 集群再去划分不同租户的 TiDB 集群，形成一个多云、多区域、多 AZ 的大的系统。这个架构有一个好处：用户可以在自己应用程序所在的云服务商和地理区域按需启用 TiDB，保持技术栈的统一。\n\n### 商业 SLA\n\nSLA 里面要考虑的东西也很多，这是 TiDB 要做的且正在做的东西。\n\nTiDB 的海外客户特别多，海外用户对数据库的需求与国内用户有很大不同，**跨数据中心是一个刚需**。由于现在各国的数据安全需求，数据的传输有了诸多限制，**合规的、跨数据中心的能力对数据库来说十分重要**。比如面对欧洲的 GDPR 管控，如果能把一部分数据就放在欧洲，不要出来，只有不在管控范围内的东西能出来，就会省去很多麻烦。相信接下来这个能力对于中国的厂商和客户，包括做出海以及在国内做合规都会变成刚需。\n\n这个功能在云上很容易实现，比如 AWS 本身就是多 AZ、多 Region 的架构，无需考虑底层，在另外一个数据中心开几台机器，用户只需要在界面上点一下鼠标数据就过去了，但对于无法在云端部署的数据库来说，如果要去处理全局的数据分布或者全局 Transaction 和 Local Transaction，需要考虑的东西就多得多。\n\n现在 TiDB 就是未雨绸缪，这项功能已经马上就要发布了。\n\n![生态.webp](https://img1.www.pingcap.com/prod/_db0e8e0163.webp)\n\n想要在云上提供服务，技术固然重要，合规是个前提。云上的生态整合有一个主线，就是跟着数据走，**数据的上游、下游和管控是最重要的三个点**。TiDB 的上游就是 MySQL、S3 里面的数据文件，下游只需要支持与 Kafka 或其他消息队列服务的同步即可。在数据的管控层面，在云上尤其是对海外用户来说，比起通过数据库厂商去做整体的管控，更希望和类似 DataDog、Confluent 这样的平台打通。\n\n最后打个广告，TiDB 在 Q4 会推出对开发者的为期 12 个月的免费体验版，能够快速部署，默认支持 HTAP 功能，通过容器实现计算隔离，同时具有专用的块存储，大家在云上可以随意使用。我们的网址是 [tidbcloud.com](https://tidbcloud.com)，未来也会支持国内的云，期待大家的体验和反馈。\n\n希望 PingCAP 能够真正做到：**让全世界的开发者享受到我们的服务，Anywhere with Any Scale**。","author":{"name":"PingCAP","description":""},"type":"detail"}}},
    "staticQueryHashes": ["1327623483","1820662718","3081853212","3430003955","3649515864","4265596160","631028557","63159454"]}