数字化时代下，企业的发展与数据库的建设息息相关。如果搭建云下数据库，不仅要通过大量的运维投入保证数据库稳定运行，随着企业规模与数据量的发展，还要应对数据库扩容、弹性、运维、备份等各种各样的问题，云下数据库对企业提出的要求日益增长。此时有两种应对之法，一是凭借扩充技术团队解决问题，但这无疑将会带来不菲的运维与人员成本，二则是把一切交给云服务。

数据库上云的优势主要体现在四个方面：1. 成本降低，把数据库的部署、监控、调优这些事情都交给云来负责，让企业把重要资源投入到自身的业务上；2. 云数据库按需使用，资源可以弹性伸缩，比如可以快速扩容数据库扛住市场促销带来的流量洪峰，活动过后缩容到正常规模以节省成本；3. 云数据库自身提供高可用性和 SLA 保障；4. 多数据副本保障数据安全可靠，实时在线备份应对灾难数据恢复。

作为近年来讨论热度居高不下的技术话题，数据库上云受到很多企业和开发者的关注和研究，其中，一部分实践者也取得了诸多成果，如 Google Cloud 自研的 Cloud Spanner 、PingCAP 打造的国内第一个 NewSQL 开源项目 TiDB，在数据库市场上都取得了很好的口碑。

想了解数据库上云的更多技术点吗？想知道它们的实践场景都有哪些吗？想了解云数据库的架构设计吗？10 月 22 日的线上直播「出海纪 | Google Cloud 今日谈」系列活动第二期：对话 TiDB 核心数据库上云秘籍中，Google Cloud 资深架构师吴斌与 PingCAP TiDB 云产品负责人刘寅通过对话的方式分享了 TiBD 开源及架构演进以及 Google Cloud 对于数据库上云的技术赋能，助力你探寻以上问题的答案。

以下内容经由 InfoQ 编辑整理自【对话 TiDB 核心数据库上云秘籍】直播速记。

Google Cloud 与 TiDB：一篇论文引发的不解之缘

作为国内首个开源的分布式 NewSQL 数据库，TiDB 理论基础来自于 2013 年 Google Spanner/F1 论文，特性上和 Spanner 非常类似，有非常强大的水平扩展能力，在数据的增长和业务流量爆发期间，可以通过伸缩节点来让数据库满足企业自身的业务需求。同时，TiDB 混合了交易型数据库和数据仓库两种负载的特性，提供 OLTP/OLAP 一站式解决方案，具备强一致分布式事务、高可用、故障自治愈、MySQL 协议兼容的特性。

“我们能做出 TiDB 这样一个开源的实现，让更多的开发者可以更低门槛地去使用、去研究这样的技术，来解决他们的问题，某种程度上来说受到了 Google Spanner 很多方面的启发。”

谈及 TiDB 借鉴 Spanner 的核心技术点时，刘寅进一步解释到，Google 在软件和硬件方面都有非常厉害的创新，比如说像 Spanner 用的 TrueTime 技术，依赖于原子钟和卫星来实现单调递增的全局时间戳，但对于硬件技术开源软件很难复制。TiDB 的架构和 Spanner 有非常相似的地方，比如底层的分布式存储架构，Spanner 论文给出一个非常漂亮的方案，将数据按照 key-value 进行组织并拆分成固定大小的 tablet，随着数据增长 tablet 可以进行分裂，通过上帝视角的调度器 PD 实现数据在集群节点之间自动平衡分布。同时每一个 tablet 借助分布式共识算法复制多个副本并保持一致性，数据副本分布在不同的地区以实现全球级别的高可用性。尽管 TiDB 和 Spanner 选择的分布式算法有所不同，但是达到的效果是一致的。

除了借鉴 Spanner 论文的技术原理之外， TiDB 在发展过程中也进行了拓展和创新。首先 TiDB 实现了完整的与 MySQL 兼容的协议，这对更多的开发者更加友好，也降低了用户的迁移成本；其次，TiDB 实现了实时更新的列存，并且利用 Raft 实现行存和列存之间的一致性数据同步，而优化器可以根据用户的查询自动选择合适的存储引擎，这样在一个数据库之上可以同时提供高并发和低延迟的交易型负载和执行实时分析的复杂查询。

在被问及是否提供方便迁移的便利工具时，刘寅表示，一方面 MySQL 兼容的数据导入、数据迁移工具都可以无缝的应用于 TiDB。另一方面，大家熟悉的 MySQL 客户端工具，也可以直接的在 TiDB 上使用。此外，支持数据进来同样也要能出去，TiDB 支持全量导出，可以用 MyDumper 等工具将数据库导出到文件，另外借助 TiDB 的 CDC 机制，把数据库的变化日志写入 Kafka, 再按照用户想要的格式写到下游的数据仓储、数据湖。这样一来，用户完全可以将 TiDB 和其他数据存储和计算生态无缝衔接，组合起来构建业务的底层数据架构。

GKE 为云上部署和运行 TiDB 提供理想的底座

大家可能都有这样一个疑问：像 TiDB 这样一个相对比较复杂的分布式数据库是如何跟云进行结合，在架构上是如何实现云原生设计的？

在 TiDB 的开发初期，容器技术开始被广泛应用，因此 TiDB 早期就定位为云原生数据库并探索如何构建和运行在云环境中。当时选择了 Kubernetes 作为 TiDB 的一个理想底座，但对于 Kubernetes 来讲，很多用户认为 Kubernetes 自身的管理和运维比较复杂，维护成本较高。而使用云托管的 Kubernetes 服务，这个问题就可以得到完美的解决。

“在 GKE（Google Kubernetes Engine）上面，一键就可以创建 Kubernetes 环境，再通过几个命令就可以把 TiDB 部署起来。并且通过 TiDB Operator 的接口，用户可以快速对集群进行扩缩容，滚动升级，实现自动故障转移，以及对集群进行监控、备份。对于运行 TiDB 来讲，GKE 是一个非常理想的底座。”

随后刘寅进一步分享了 TiDB 在 GKE 上的一些最佳实践。事实上，在 Kubernetes 上最难的就是管理有状态服务，而像运行 TiDB 这样的分布式数据库更是需要克服很多技术困难。对此 GKE 的四大特性也为 TiDB 在云上运行提供有力的支持：

StatefulSets 的出现使得 GKE 上管理应用状态变的简单；
通过 Operator 模式让升级、滚动重启、扩容等等一系列复杂操作变得统一且标准化，Operator 的模式成功地让复杂分布式基础设施组件具备运行在 GKE 上的能力；
高性能独立存储 (pdssd, pdhdd)，保证更好的吞吐的同时提供了很好的 IOPS；
[Beta] eBPF for GKE on GCP

作为面向核心业务的数据库，TiDB 在延迟、吞吐等方面有极高的要求，通常需要使用本地盘作为数据库的底层存储介质。然而本地盘在云上并不提供持久化保障，有一定的限制，例如在节点发生故障或者是在替换 VM 镜像时本地盘的数据会抹除。而 TiDB 本身是提供多数据副本，可以支持跨区部署，以此避免单点的磁盘故障对整个集群带来的影响，并进行自治愈恢复。

另一个方面来讲，在 GKE 上面去使用本地盘也有非常大的挑战。本地盘是不能随着 VM 节点来进行漂移，VM 节点的生命周期结束则本地盘的数据也会随之销毁。凭借 Operator 扩展 Kubernetes 的控制器和调度器是一个好方法，当 Operator 发现节点失效时会自动将 Pod 调度到新的节点，并通过 API 操作数据库完成失效节点的下线和新补充节点中的数据副本的恢复。

此外，在云上还可以把 TiDB 的数据副本分布在不同的地域，实现跨可用区部署，这样一来，即使一整个区域发生故障也不会影响到数据库服务的可用性。云提供的 Instance Groups 可以实现节点按需自动伸缩，通过将 GKE 的 HPA（Horizontal Pod Autoscaling) 能力和 Operator 相整合，将数据库和云的弹性能力融合在一起，借助云自身的安全特性提供用户一个可靠、弹性、成本经济的 TiDB 服务。

当被问及 GKE 未来产品路线图值得期待的特性时，吴斌透露出了几点重要信息：首先是 kubernetes 本身就 host 在 Google Cloud 的 GKE 上面，这代表着两个比较关键的信息，一是所有 k8s 原生的功能都将第一时间出现在 GKE 上，二是如果在 GKE 上进行应用整体的开发部署流程，那么它对于原生 k8s 的兼容性也将会非常好。另外，社区开源 k8s 集群在部署管理时受限与例如底层硬件等诸多条件的影响，规模上会有上限。目前在 GKE 上支持集群的大小已经达到了一万五千个节点。并且在原生的 k8s 集群上拉起 pod 的节奏也存在一定限制，在 GKE 上面这个限制取决于集群的大小，尤其对于相对较大规模的集群优势立现。

“GKE dataplane 第二个版本将会把 eBPF 网络层的特性引入到 GKE 的集群当中去，尽管不是 Google 引领的技术，但是我们依旧会第一时间把最新、最好的技术引入到产品之中。一直以来，Google 在数据、AI/ML 领域投入都非常大，TiDB 和 k8s 都是非常重要的伙伴和组件，我们也在尝试着把人工智能相关技术引入到 GKE 的弹性伸缩场景中去，让 GKE 变得更加酷炫。”

讨论云上 TiDB 在行业和场景中的应用

综上所述，既然 TiDB 拥有很好地特性和特点，那么在行业和场景中的应用又是否足够硬核呢？

TiDB 的核心价值是可以无限地去水平扩展，同时满足业务高吞吐和低时延的要求，应用场景也非常广泛，以游戏行业举例来讲，数据的可靠性和服务可用性是非常重要的，数据库一旦出现故障就会影响到玩家体验，业务不停机是很多游戏公司对数据库选型提出的要求。而 TiDB 本身有多数据副本、高可用部署的架构特点，容忍单点故障和自动治愈，以及支持滚动重启升级等特性，可以很好满足这些场景的需求。

“很多游戏厂商都存在用户量暴增的场景，TiDB 如何去解决这些行业场景下的痛点？”

针对上述吴斌提出的问题，刘寅举例回复道，在线游戏往往需要实时写库，在业务高峰期写入量非常大，而通常表的主键是一个单调递增的序列，高并发写入会导致出现写入热点。TiDB 可以支持一种 auto_rand 类型的主键，既能保证主键不会冲突同时将热点分散在各个节点。用户可以在不改变业务逻辑的前提下应用这个特性，满足唯一性约束的同时提升写入性能，这个特性在很多的游戏用户里面都非常受欢迎。

除此之外，TiDB 还有一个非常有意思的能力是提供实时分析。在 TiDB 上，行存和列存的数据保持同步更新，同时提供一致性的查询。运营人员可以直接基于线上最新的数据执行 Ad-Hoc Query，进行实习分析和实时决策。这个特性在反作弊和实时风控等场景中非常有用。

在此类业务场景下，很多企业也都在尝试结合人工智能技术更好地落地数据库产品，TiDB、Google Cloud 同样是其中的探索者。

“Google Cloud 本身有非常好的数据处理和 AI 生态，和 AI 相关的产品有两种，一种是开箱即用的 API 类产品，另一种就是大家耳熟能详的纯手动档产品。目前，TiDB 已经通过 GKE 这样很好的技术结合点‘牵手’ Google Cloud ，未来也期待在 AI 方面探索出更多的合作。不管是 TiDB 的用户，还是任何数据库产品的用户都可以借助 Google 这个强大的生态，还有数据交换的媒介更好地发展业务。”吴斌表示道。

从产品易用性和安全合规看 TiDB

前文讲了很多关于 GKE 和 TiDB 的优质特性，那究竟如何在 GKE 上面使用 TiDB 产品？

“两步就能搞定，第一步借助开源工具 Terraform，一键初始化 GKE 资源并自动安装 TiDB Operator；第二步完成 TiDB 集群的部署，整个过程非常流畅，用户可以通过这套方案来快速地去管理数据库。”这里提到的 TiDB Operator ，除了提供 TiDB 集群的部署管理外，还能够支持 TiDB 的监控、数据备份恢复等功能。

那相对于用户自建的方案，TiDB Cloud 又能带来哪些价值？

针对这一问题，刘寅表示，首先就是在于降低用户的总体拥有成本。通过 TiDB Cloud 这一全托管数据库服务，用户可以通过几下点击快速创建 TiDB 集群。而集群的运维全部交给 PingCAP 的专业工程师，由他们对集群进行 7*24 小时的监控，给数据库打安全补丁，定期备份，以及提供更专业的性能调优支持等。用户可以更专注在自身的业务，而不需要雇人和花精力在数据库的管理和运维上。

“在安全和合规上，一方面 PingCAP 与 Google Cloud 深入合作，借助云本身基础设施提供的安全性与合规保障；另一方面 TiDB Cloud 将自身的安全特性放在首位，例如通过静态数据加密和传输层加密保障用户的数据安全。同时 TiDB Cloud 也在做各种合规认证，例如：SOC 2，GDPR 等，以满足全球不同地区的合规性要求。”

事实上，安全和合规是云厂商和数据库厂商都非常重视的一个关键领域。在这样一个数据为王的时代，大多数企业都非常关注自身数据的安全性，这也是数据库上云虽然有千好万好，但是总有企业踟蹰不定的原因。相信在 Google Cloud 和 TiDB 的携手探索下，将会更快推动数据库上云这一前瞻性布局的发展。

“在 Google Cloud 上面我们对于数据安全也是永远放在第一位的，不论是在磁盘上面的数据还是在传输过程中的数据，都需要进行强制加密，在这一点上大家保持着高度的一致。”吴斌总结道。

分享嘉宾：
吴斌，Google Cloud 资深架构师，拥有 10 多年软件工程师研发经验，非常善于数据分析、搜索引擎以及大数据相关的技术，帮助很多企业构建了云原生的架构解决方案，同时也是一位开源软件社区的积极贡献者和组织者。

刘寅，TiDB 云产品负责人，早期加入 PingCAP 伴随 TiDB 一起成长，专注在数据库生态工具、容器技术和公有云产品相关的研究，同时热衷于开源技术，目前主要负责 TiDB Cloud 的平台研发和 SRE 相关工作，探索 TiDB 与公有云如何更深度的整合。

点击【此处】查看回放视频

创作场景

解读 TiDB：行走在 GKE 上的 NewSQL 开源数据库