{
"componentChunkName": "component---src-templates-company-news-detail-tsx",
"path": "/about-us/company-news-detail/pingcap-at-china-property-insurance-technology-application-summit",
"result": {"pageContext":{"companyNewsDetail":{"id":"About-us-news_23","title":"PingCAP 朱巍：以敏捷，开放，一栈式数据服务助力保险行业数字化变革","customUrl":"pingcap-at-china-property-insurance-technology-application-summit","image":{"alt":"中国财险应用高峰论坛封面图","media":{"url":"https://img1.www.pingcap.com/prod/_b65e890aeb.jpeg"}},"date":"2021-10-13","body":"2021 年 9 月 29 日，PingCAP 高级副总裁朱巍受邀在由中科软科技股份有限公司主办的“中国财险科技应用高峰论坛”上发表了以“**以敏捷，开放，一栈式数据服务助力保险行业数字化变革**”为主题的演讲。 \n\n朱巍表示，随着保险行业数字化变革加速，保险应用的线上化、实时化、海量化、智能化也在加速，这对分布式数据库提出了更高的要求，PingCAP 基于 TiDB 5.0 的解决方案可快速应用到多个保险行业场景，并已有多个金融行业成功案例，PingCAP 也将与中科软紧密合作，共同推进保险业信息化建设。以下为分享实录： \n\n\n\n保险行业的数字化转型很早就已经开始，现在已经进入了不断深化的阶段，这种转型主要从两个方面展开：一是利用科技加速保险业务的重构，也就是服务的精准化、智能化。二是通过金融科技助力业务的发展，提高业务的质量，最后使业务的运营变成数字化的运营，这就需要依托数据的分析来实现。\n\n数据分析不是一个新的概念，**关键是怎么能实现数据洞察、分析、消费的实时化**，除了传统的数据治理、数据模型的创新之外，需要新一代的数据基础架构作为基石，这也是我今天分享的主题：从过去到未来的转型。\n\n## 产险行业数字化转型三大变革\n\n过去保险的业务都是在固定时间、固定场所，通过固定的代理人实现一个有边界的业务场景，而未来很可能进入非固定时间、非固定场景、非固定代理人无边界的场景。具体说来，今天客户购买保险产品可能不在是营业厅，而是在互联网生活 APP 上，企业所售卖的也不再是简单的产品，而是需要基于驾驶员驾驶行为的变化而给这个产品定价，这就是**场景化、碎片化、行为细节化**。\n\n产险行业数字化转型的三大变革可以总结为：**场景体验创新、数据的价值创新和架构的创新**。比如某个财险总公司把产品或者保单的定价能力不仅开放给各地的分公司，也开放给各个生态的合作伙伴，从有边界变成无边界，挑战也随之而来：业务量和数据量有巨大的扩展和提升，而且带来了短时的高峰。PingCAP 对接的很多生态合作伙伴场景都有短时高峰、突发性强的特点，特别做大促的时候就对**技术架构创新**提出了更高的要求：比如对在线扩缩容的支持，来满足业务敏捷、弹性访问量数据量的需求；也带来了**场景体验创新**的需求：新对接一个合作伙伴、新支持一个场景很可能涉及到业务的迭代，传统的迭代速度可能无法跟上这种速度；同时由于对接大量生态合作伙伴，除内部数据之外，现在可能拥有大量外部生态合作伙伴回流的数据，大量数据进来之后，需要实现实时洞察、实时数据汇聚、实时分析和实时变现的能力，这就是**数据价值的创新**。\n\n## 场景体验创新、数据价值创新、架构创新中的挑战和机遇\n\n\n\n**场景创新中最大的挑战之一就是敏捷性的支持**，要敏捷地应对数据量业务量突然的短时高峰，海量数据的扩张扩容的要求。扩容不及时、数智化能力低、跨域流程割裂已经成为了场景创新时的三个瓶颈。\n\n\n\n**数据价值创新中如何解决数据时效性、集成性成为了最大的痛点**。刚才提到数据分析已经是很老的课题，为了实现 T+0 的数据分析，数据资源分布在不同技术栈上面，整合平台建设非常困难，跨流程客户体验比较差，技术要求也很高。负责 IT 大数据中心的团队，不同技术栈配备不同的人员，有很高的学习成本，不同业务运营对应不同技术栈也比较复杂，成本每年递增，数据转化和迁移成本都在提升。业务需要的实时风控、实时智能营销在复杂的技术栈下都会经受多种考验。\n\n\n\n**技术架构的创新，简而言之就是云化**。技术架构要云化，数据库也要云化，最大的区别是什么？就是从年到月到秒的变革：过去大型机，资源的规划资源的供给以年为单位；后来引入分布式计算引入 X86 服务器，实现了以月为单位；现在云可以实现以秒为单位，按照业务的需求去配置资源。**这样一种场景化、敏态的、实时智能的架构也需要云原生的分布式数据库来支撑**。\n\n## 打造新一代 HTAP 分布式数据库\n\nPingCAP 的核心产品 TiDB 是新一代的 HTAP 分布式数据库，PingCAP 立志做这个领域的全球领导者。PingCAP 首创工程化的 HTAP 分布式数据库产品，用一个技术栈实现 OLTP 和 OLAP 的混合负载处理。\n\n\n\n具体谈谈 **PingCAP 提供的解决方案和专业服务支持**，PingCAP 提供的企业级分布式数据库产品 TiDB，目前已经得到 1500 家全球用户的使用，其中包括几十家银行和金融机构和中国 80% 顶级互联网企业。微信九宫格的很多小程序，比如打车 APP，旅游 APP，微信支付页面下 80% 的 LOGO 下都有 TiDB 的支撑。TiDB 用敏捷高扩展的 OLTP 能力来支撑数字化转型的所有对业务敏捷性要求非常高的场景。实时的、支持 HTAP 混合负载的能力满足企业数据实时的洞察分析和消费的场景。同时也提供金融级的两地三中心高可用解决方案，TiDB Cloud是 PingCAP 推出的云数据库服务，目前已经上线为全球用户提供全托管的 DBaaS 服务。\n\n与此同时，**PingCAP 提供一系列专业服务支持体系**，常规运维类服务，应急保障服务，让用户能够非常顺利安心地将 TiDB 部署到自己的企业级关键应用里边。此外，**PingCAP 具备非常强大的社区生态**。今天在中国熟悉 TiDB 产品的 DBA 已经超过一万名，这为大家选择 TiDB 服务企业未来场景奠定坚实的人才基础，不管是运维开发还是运维支持人才都打好了基础。现在 TiDB 的代码有 40% 都来自外部贡献者。数据库是一个基础软件，是长跑，需要比拼的是人才的密度和数量，社区对 TiDB 产品的赋能，我相信也会是一支强大而且在不断增长的力量。\n\n\n\n现在，全球已经有 1500 家企业使用了 TiDB 的产品，通过敏捷高可扩展的 OLTP 提升了业务的敏捷性，**同时通过 TiDB 的 HTAP 能力实现在 OLTP 产生热数据之后，马上做实时数据的分析洞察和变现**。北京银行通过 TiDB 敏捷的高可扩展性的 OLTP，五个小时之内就实现了 5 亿条数据的在线扩容；今天 TiDB + Zabbix 在中国银行监控的对象超过 10000 个，运维部门每天采集的数据有接近 15 亿条；在中通快递，TiDB 顶住了“双十一” 35 万的 QPS 而且将实时多表关联查询的时间从五分钟缩短到了一分钟；在汽车之家 TiDB 成功应对了千万级的 DAU，也是一样聚合场景的查询，效率提升了 20 - 50 倍；也是通过 TiDB 的部署，中国人寿把单证状态查询的耗时从 8 个小时降低到 6 分钟……\n\n## PingCAP 赋能保险行业数字化转型\n\n\n\n聚焦于财险的数字化转型，**最重要的是技术架构云化场景体验创新的能力**，以及如何实现数字价值实时变现。在云化大的趋势下，TiDB 既是今天最佳的选择，也是能够支撑未来技术发展和演进的选择。\n\n**TiDB 是新一代 HTAP 数据库**，实现核心 OLTP 负载的同时，可以**对热数据做实时分析洞察和变现**，用一个技术栈实现 OLTP 和 OLAP 的混合负载处理。从场景角度谈，TiDB 经历了大量互联网业务的考验，所以当保险业务走向互联网化，对敏捷性、弹性伸缩要求高的时候 TiDB 非常适合。对于海量数据的处理，TiDB 可以做到在线的横向扩容，随时上下线计算和存储节点；敏捷性上除了弹性扩缩容，也特别合适今天保险业务大量接入合作伙伴的场景，更快速地实现应用的迭代。由于 **TiDB 不需要做分库分表**，不需要应用改变迭代重新考虑分表的策略，使整个应用开发迭代速度大大加快。最后就是创新，**TiDB 是云原生云中立的数据库**，可以实现跨云的部署。同时 TiDB 的敏捷不仅带来了弹性扩缩容的便利，而且意味着**终端用户体验的提升**，可以快速建立响应机制，帮助新场景、新业务合作伙伴迭代。\n\n\n\n在转型升级之外，回到根本，**金融行业最核心的还是稳定**。TiDB 充分考虑这一点，提供了金融级容灾多活保障能力，支持两地三中心部署，提供数据的强一致同步，可以满足 RPO 等于 0，RTO 小于 30 秒这样高等级严格容灾要求，实现了金融级多中心的容灾方案。\n\n下面举两个比较实际的例子。PingCAP 与国内某大型财险公司合作推出了新一代保险核心系统，支撑财险公司从实时保单的查询到实时的统计分析。PingCAP 与中科软联合打造的新一代保险核心系统覆盖了财险公司各个环节，“收付”、“承保”、“再保”、“报价”、“保单查询分析”等保险核心业务线提供高并发的写入和查询分析。对于保险产品模型里边还有非常复杂的查询，可以做到毫秒级的实时查询，同时支撑非常高性能高扩展的交易核心，提供金融级的高可用的保障方案。TiDB 在平安人寿金管家，面对 DAU 数千万，用户量级达到三亿多的大促时，能够进行几百个节点的弹性在线扩缩容，上线时间从一个月缩短到一天；实现了标准化的 API，业务部门可以实现非常高的敏态开发，相比原来的数据库架构节省了 30% 以上的成本。\n\n## 携手中科软助力保险行业数字化变革\n\n\n\nPingCAP 与中科软的合作已经涉及到多个行业领域，包括产险、公共卫生、银行等，从产品适配到解决方案推出，为客户提供统一的解决方案。产险领域，已经联合为多家客户的核心系统提供服务，也都收到了非常好的反馈，在公共卫生领域，PingCAP 与中科软通力协作，实现了基于 TiDB 的包含新冠疫苗数据在内的国际级免疫系统数据库。**PingCAP 也将与中科软紧密合作，共同推进保险业数字化转型升级**。","author":{"name":"PingCAP","description":""},"type":"detail"},"prev":{"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\n\n上图是我理解的数据库发展历程。追溯到十几年前，我们开始使用单机 MySQL，这个时期我们对数据库的需求只有朴素的增删改查，2010 年前后直到今天，爆发的数据量让单机数据库难以为继，大家只能通过分库分表或者中间件来实现分布式部署。\n\n \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\n\nPingCAP 始终坚持开源战略，也因此受益颇多。\n\n从**生态**角度，开源的研发模式能够迅速积累用户。TiDB 1.0 版本 2017 年 11 月发布，从诞生到现在，我们知道名字的用户有 2000 多家，贡献者有 1500 多个，CNCF 开源组织的 Contribution Rank 中，PingCAP 排名全球第六。\n\n\n\n从**技术**角度，开源加速了产品的迭代速度。这张图的纵轴是代码量，横轴是时间，不同色块是代表某一年写的代码量。从图中我们能够看出，基本上每年 TiDB 的代码都在被重写，几乎没有一年是跟去年的代码一样。这个迭代的速度就是通过开源社区来实现的，是任何一个团队、任何一个公司、任何一个企业从头开始做一个数据库都无法达到的进化速度。\n\n## Why DBaaS\n\nTiDB 的产品能力不是今天分享的重点，我今天想谈的是把一个产品变成云服务到底有多重要。首先抛出一个最终结论，现在这个时代对 CIO 尤其是海外的客户来说，数据库产品对云的适配成为了一个必选项。\n\n\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\n\n在过去，TiDB 有一个 TiDB + TiKV 的协处理引擎，计算和存储的边界是非常模糊的，很难处理不同负载率的场景。本地部署的情况下，如果需要增加存储容量，就需要增加存储节点，因为硬件的限制，除了磁盘，CPU 及网络带宽也会同步增加，这就造成了资源的浪费，这是所有 Shared-Nothing 的数据库都要面临的问题。\n\n\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\n\n图中是 TiDB 的安全体系，云上的安全体系和我们云下的思考完全不同。举个特别简单的例子：云下只需要考虑 RBAC 数据库内部的权限，但在云上就非常复杂，需要考虑从网络到存储一整套的用户健全安全的体系。做好云上安全的关键点是千万不要自己重复发明，因为基本都有安全漏洞。所以我们现在就是要充分利用云本身提供的一套完整的安全机制，比如密钥管理和规则等。当然，最好的地方都是这些服务都能够明码标价，只要做出计费模型就好了。\n\n### 运维自动化\n\n关于 DBaaS 的构建还有一点很重要，其实也和成本有关，就是运维自动化。云是一个规模化的生意，而现在国内数据库生意最麻烦的部分之一就是交付。一个大客户恨不得派二十个人驻场，但这件事情可持续吗？。我们要实现的就是可以通过 10 个人的交付团队去支持有 1000 个客户的系统，这是规模化的前提。\n\n\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\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"},"next":{"id":"About-us-news_26","title":"成为全球可信赖的数据库云服务供应商，TiDB Cloud 通过第三方认证符合 GDPR 标准","customUrl":"tidb-cloud-attains-gdpr-certification","image":{"alt":"TiDB Cloud GDPR 认证","media":{"url":"https://img1.www.pingcap.com/prod/Ti_DB_Cloud_756076e3be.png"}},"date":"2021-10-12","body":"\n\n近日，企业级数据库提供商 PingCAP 的全托管数据库云服务产品 TiDB Cloud 由第三方机构 ePrivacy GmbH 认证符合欧盟 GDPR 要求。这也是 TiDB Cloud 继完成 SOC 2 Type 2 和 ISO 27001 认证后在数据安全方面获得的最新认证。\n\nGDPR (General Data Protection Regulation) 通用数据保护条例是欧盟议会和欧盟理事会在 2016 年 4 月通过，在 2018 年 5 月开始强制实施的通用数据保护条例。GDPR 意义在于推动强制执行隐私条例，规定了企业对用户数据的收集、存储、保护和使用的新标准；另一方面，也给予了用户对自有数据更大的处理权。\n\nTiDB Cloud 是全托管的数据库即服务（DBaaS, DataBase as a Service）产品，依托于公有云提供开箱即用的 TiDB 服务。TiDB Cloud 屏蔽了 TiDB 数据库部署、运维和性能调优的复杂性，通过图形界面点击就可以快速创建和管理 TiDB 实例，使用户可以专注于自身业务应用程序的开发，降低总体拥有成本。\n\n“数据已经成为企业的重要资产，作为数据库服务提供商，保证数据和隐私的安全是我们的首要任务。PingCAP 致力于向全球用户提供安全可靠的服务，打造可信赖的 DBaaS 平台。\" PingCAP TiDB Cloud 总经理代闻表示，“PingCAP 在全球范围内依照严格的数据隐私和合规标准进行产品设计，经由一系列认证确保产品的合规及安全性，TiDB Cloud 有能力成为全球最值得客户信赖的数据库云服务之一。\"\n\nPingCAP 希望通过 TiDB Cloud 把 TiDB 的价值交到全球每一位开发者手中，让用户能够在任意地方、任意规模享受到 OLTP 规模化和 Real-Time HTAP 的能力。在加强安全合规的同时，TiDB Cloud 的功能也在不断增强。尤其在最近半年内，TiDB Cloud 增强了对云厂商数据导出格式的兼容，让数据链路的集成更容易，并且实现了在云上基于 HTAP 的实时数据分析，让实时洞察成为业务标配。\n\n了解 TiDB Cloud 详情： \n\n立即注册，试用一年免费的 TiDB Cloud Developer Tier： ","author":{"name":"PingCAP","description":""},"type":"detail"}}},
"staticQueryHashes": ["1327623483","1820662718","3081853212","3430003955","3649515864","4265596160","631028557","63159454"]}