中国技术出海，TiDB 数据库海外探索之路 | 卓越技术团队访谈录

据 PingCAP 介绍，目前他们旗下的 TiDB 数据库产品已经服务海外多家巨头企业，覆盖互联网、科技、金融、游戏等行业。熟悉数据库的开发者都知道，有着基础软件“三驾马车”之一的数据库对一家企业的重要性有多大。

PingCAP 从成立之初就坚持国际化，他们是如何成功出海，在海外这个巨头林立的市场成功立足。TiDB 做了哪些技术上的优化，海外业务有哪些特点，它在针对这些场景做了什么工作？他们在海外业务上遇到了什么挑战？本次，InfoQ 深度采访了 PingCAP 团队核心人员，了解 TiDB 数据库海外探索的那些事儿，希望可以给你带来启发。

对于拥有全球化业务的 PingCAP 来说，数据库产品 TiDB 对云的适配是一个必选项。尤其是对海外客户，从 DB 到 DBaaS，只有云上的服务才能突破地域的限制，提供无限算力。

不过上云并不只是底层资源换成云端这么简单，技术上，要实现降本增效、运维自动化、多租户管理；合规上要考虑数据安全、监管规则；商业上，计价模式、商业化策略等等这些因素都需要纳入考量。

下面简单从技术的角度谈谈 TiDB 从本地部署向 TiDB Cloud （DBaaS）演进过程中解决的问题。

首先是分离的架构设计。过去 TiDB 使用 TiDB + TiKV 的协处理引擎，存储与计算的边界是模糊的，在本地部署（ On-Premise ) 的情况，如果需要增加存储容量，就需要增加存储节点，由于硬件的限制，除了磁盘，CPU 与网络带宽也会同步增加，比较难处理不同负载率的场景，也容易造成资源的浪费。

迁移到云上之后，一切都变得不同。以 AWS 的块存储设备 EBS 为例，尤其是 GP3 系列，它可以在不同的机器上运行，性能很好，对云原生的整合也不错。为了利用 GP3 的这些特性，TiDB 将计算和存储的边界下移，从原来的 TiKV 到存储，变成现在 TiDB、TiKV 的大部分都可以是计算单元。

除了计算存储分离，不同角色的组件对硬件资源要求也是不同的，按需选择存储服务类型、弹性计算资源、无服务器计算、运维自动化等都会成为成本节约的方案。

总的来说云原生技术最重要解决的就是成本问题。除了成本，云的安全性也是重中之重。云上安全体系与云下不同，云下只需要考虑 RBAC 数据库内部的权限，云上则要有从网络到存储的整套健全的安全体系，最关键的就是利用云本身提供的安全机制，如密钥管理、规则等。

最后回到业务，为云上的海外客户提供服务，技术之外还有个前提条件就是合规。而云上的生态整合主线是跟着数据走，数据上游、下游、管控是最重要的三个部分。以 TiDB 为例，其上游是 MySQL、S3 中的数据文件；下游只需要支持 Kafka 或其他消息队列服务的同步；最后对于云上的海外用户，相比数据库厂商去做管控，他们更愿意与 DataDog、Confluent 等平台去打通。

中国技术出海容易遇到信任度、监管、地理位置等各种各样的问题。以欧盟为例，虽然国家比较小，但数量非常多，而且 GDPR 非常严格，个人相关数据不允许出境；再比如，印尼由很多块岛屿组成，为应对自然灾害，就要求数据在几百公里以外有存档，另外像日本是多灾害国家，经常海啸、地震，也会要求做跨区域的备份，比如公共云厂商一般都会在东京放一部分，大阪放一部分。所以 TiDB 也必须支持跨区域数据的灾备。此外，海外人力成本越来越贵，所以部分地区会要求把所有技术设施都使用代码进行管理，对 Infrastructure as Code 即 IaC 的挑战会很大，同时对自动化的运维要求也很高。

除了基础技术 TiDB 可以顺利出海有几个关键因素。首先是上云，只有云上的服务才能突破地域的限制，前文已经提到，这里不再赘述。TiDB 在云平台化完成之后，第二个重要的事情就是解除信任门槛。不得不承认，在这点上，开源是个很好的敲门砖。中国技术公司服务海外客户，如果没有采用开源技术，怀疑会被加大，尤其是数据库这种基础设施，用专家的话说：“数据库像心脏搭桥手术一样，是比较要命的东西。”TiDB 开源社区的活跃度在这方面也提供了很大的帮助，既解决了信任门槛的问题，同时在往国外市场做广告和宣传上也省掉很多麻烦。

第三就是对于新技术趋势要敏感，以 TiDB 为例，开源技术快速进行迭代，才能跟其他技术如 Flink、Spark 融合在一起。海外的许多企业技术前瞻性看的非常远，技术的进化一定要跟上客户的新形态才能保证不掉队。回过头看国内，我们的云厂商在架构上并没有出现特别领先的技术，同质化的竞争和卷的局面仍在继续，工具确实有很多，但是模式没有明显优势。

海外的用户基本上天然都在云端，许多都是在云端使用 MySQL 或者云端的 RDS，这对 TiDB 来说也是天然的优势。TiDB 的做法是优先选择海外公有云上的头部互联网企业，公有云解决了数据安全性的问题，头部互联网企业解决了体量的问题。不管对方是使用 MySQL 还是其他传统数据库，遇到瓶颈就会有新的需求，恰巧 TiDB 向下兼容 MySQL。同时，TiDB 开源的形态也起到了关键作用。

对于 TiDB 来说，不同地区海外客户的需求也有明显的区别，目前海外云上的客户主要有两个分支，之前多数都使用 RDS，其中以 MySQL 的 RDS 最为普遍，在出现无法处理的数据量后就会有两种选择。第一种是全托管，即所有技术上的事情全都不管，全部服务交给 TiDB，这也就是 TiDB Cloud 做的事情，这个分支当前主要以日本客户为主；另外一部分就是还需要防止云厂商锁定，比如美国大部分客户希望不会被某一家云厂商绑定，甚至未来有可能出于成本考量为选择本地部署做准备，那么他们会选择一个同时满足多云甚至本地支持的数据库方案。北美的用户也对全托管的 TiDB Cloud 表现出了很大的关注度，去年 11 月 TiDB Cloud 面向开发者的免费版本 Dev Tier 就有很高的访问量和试用者。

当然其中还有部分架构翻新的需求，比如大型技术公司往往会更积极地寻求更先进的解决方案，以期望获得更好的业务收益。

以北美一家著名社交公司 A 为例，A 公司的用户体量比较大，HBase 规模达到了 10PB。A 公司刚成立时正是 NoSQL 比较流行的阶段，所以使用了很多 NoSQL 的服务，其中诸多业务实际上需求的是可扩展的关系型数据库，但当时并没有更好的选择。后来随着发展，他们慢慢发现 NoSQL 很难满足业务的需求，需要进行大量定制开发，就准备寻找下一个数据库解决方案，花了半年时间，看了 15 个系统，从这里其实可以看出，A 公司在数据库选择的事情上还是比较严谨的。最后他们选择了 TiDB，主要的原因是 TiDB 无需太多定制开发，解放心智，成熟度高、且维护成本低。A 公司经过评估后，开始逐渐把 HBase 向 TiDB 迁移。

其实从这家公司的技术栈选择可以看出来，虽然目前典型客户还不够多，但是 NoSQL 替换将会是一个趋势：不少用户选择 NoSQL 未必是为了解绑关系型的特性，相反他们可能仅仅是为了可扩展而被迫牺牲关系型数据库的特性。

还有一个案例，B 公司之前花费了近千万美元购买了 300 多台机器的 Aurora，但是效果并不是太好。300 多台机器的升级对他们来说工作量就会非常大，Aurora 也无法满足当前的业务需求。此外，B 公司正在做 Data Service，此前的 SQL 方案对于现在的应用开发来说体验也较差。于是基于这些事，B 公司希望使用 TiDB 来做支撑，支持 100 多万的 QPS。B 公司选择 TiDB 的原因是因为 TiDB 有更好的可观测性，同时可以把架构简化，这与他们下一代的云原生架构很接近。B 公司的下一代云原生架构希望在每个公有云上去部署一套 Kubernetes，让 TiDB 在跨 Kubernetes 中提供服务，整体上是一个 TiDB 集群。

日本市场则有其独特的场景，经过调研后 TiDB 发现其主要特点有以下几个方面，首先是传统数据库扩展困难的痛点比较突出，实时业务的需求使得传统公司正在考虑逐步尝试换掉 Oracle 等数据库，升级 MySQL 数据库的扩展能力，并提升实时分析能力；第二，新冠疫情对日本整个数字化行业有一定的助推作用，虽说总人口并不多，但场景越来越趋向于高频业务，这种情况非常适合 TiDB 发挥；第三、由于人力成本与多方面原因，日本缺乏经验丰富的 SRE 工程师和 DBA（数据库管理员）。同时 TiDB 发现，基于这几个因素 TiDB 可以做的事情加上开源社区的影响，TiDB 在日本的热度还是比较高的。

TiDB 在日本的规划是先从游戏、互联网行业入手，之后慢慢转向传统行业、金融行业。一方面游戏行业有着天然的周期，其次互联网行业有高频的场景，有大数据量的增长需求，还有一个原因是他们普遍对新技术的接受度很高，比较少顾虑产品技术以外的东西，只看产品能力和成功度，这正是 TiDB 需要的。

不过不同于北美，日本的客户更倾向于使用托管的服务，这样可以使他们更专注于业务本身。以游戏行业为例，日本游戏的特点是生命周期普遍比较长，一个游戏经营运行几十年，有许多忠实的粉丝，用户付费习惯也比较好，所以游戏付费是他们最常见的场景诸如高频交易、时效性、交易完整性等等要求都很高，另外他们一直有非常稳定的用户，这些用户对游戏的稳定性和因为游戏升级等原因导致的维护期非常看重。所以日本的游戏公司也会在游戏制作上重点投入，比如采集游戏的声音。他们并非不重视技术，只是因为人力成本的原因，相对缺乏有经验的 SRE 工程师和 DBA（数据库管理员），这些对云端的数据库来说都是很大的挑战。

以某游戏公司 C 为例，C 公司每年游戏收入大概 2-3 亿美元，他们一年要开发十款游戏，但是开发团队只有 10 个人，如果细分到数据库和云的开发小组，人员就更少了，基于非原生分布式方案例如 MySQL Sharding 的复杂度需要更多的工程人员，对于小型团队而言将大幅拖慢业务推进。TiDB Cloud 这种托管方式显然更为合适。同时，TiDB 在实时反馈、高频交易、时效性、完整性等上面也确实达到了对方的要求。

另外还有一个比较有特点的是金融行业，日本市场非现金支付不像国内发展的这么快，他们在几年前有一个快速增长的过程，经过分析后发现主要有以下几个原因，第一是电商的快速增长，第二智能手机和电子支付的发展，第三是外来游客的涌入，电子支付对他们来说是最方便的支付渠道，这些突增的用户量、实时在线交易使得本地的支付公司数据库无法承载。

以其中一个金融公司 D 为例，他们的架构非常简单，主要包括支付、用户、商户、钱包、风控、活动等模块。他们在从 1500 万用户量增长到 4000 万的过程中，原有 Aurora 数据库无法处理实时在线的需求，选择了迁移至 TiDB。D 公司的需求是扛住 1000 TPS，由于他们架构是一写多读的性质，现有的 Aurora 数据库很难突破这个瓶颈，TiDB 是多写横向扩展的架构，迁移至 TiDB 之后，TPS 也是轻松达到了之前的三倍。除此之外，TiDB 还解决了之前 Aurora 的性能问题同时提供了更好的恢复性。

最后简单总结，除了基础技术、性能等关键产品特性能够满足自己的场景和需求之外，TiDB 还有另外几个吸引海外客户选择的因素，第一 TiDB 是开源的，有着活跃的开源社区；第二不作为数据容器，客户的数据还是会存放在 AWS、GCP 等公有云上；第三是远程支持，不必依赖当地技术团队，可以有效解决部分地区人力资源贵的情况。

进入云 2.0 时代，之前 RBS（远程 Blob 存储）覆盖的群体，基本上已经有领先的客户再进行升级。其中一个是跨云、云原生；第二就是采取全托管云中立的类似 DBaaS 这种，比如 TiDB Cloud。另外如今的分布式数据库已经不单单是一个数据库，它已经逐渐变成了一个 Data Platform （数据平台），同时它还处理了许多大数据的工作比如 HTAP 代替大数据的实时分析，受访专家认为，最终它会借助开源演变成云上的 Data Ecosystem（数据生态系统）。

目前现在的数据库，还没有真正为云原生比如 Serverless 去设计。真正的下一代数据库，应该具有以下这几个特点。第一可以从云上获取到更多更灵活的资源，存算可以做到随意，现在普遍的数据库在云端部署，理论上白天需要 1000 台计算节点，较少的存储节点，晚上则相反；第二未来数据库的底层比如在存储层，能够在云端做到更深层的优化，支持像 SnowFlake 这种可以动态调用云的资源，根据不同类型的请求来决定底层选用什么样的存储逻辑。这个才是未来真正的云原生，目前还在路上，但期望可以在未来实现。

采访嘉宾介绍：

刘松：PingCAP 副总裁，曾在 Oracle，阿里云担任技术管理等职位

陈辰：PingCAP 日本分公司 首席技术官，曾在阿里云，IBM 担任技术开发顾问职位

裴立全：PingCAP 北美分公司 首席技术顾问 ，曾在 Pinterest 担任技术运维等岗位