写点什么

我们是如何实现 TiDB Cloud Serverless 的 - 成本篇

  • 2024-11-15
    北京
  • 本文字数:1823 字

    阅读完需:约 6 分钟

作者: shiyuhang0 原文来源:https://tidb.net/blog/fbedeea4

背景

Serverless 数据库是云原生时代的产物,它提供全托管,按需付费,自动弹性的云数据库服务,让客户免于繁重的数据库运维工作。关于 Serverless 数据库原理文章比较少,本文将介绍我们是如何依托云厂商提供 TiDB Cloud Serverless 服务的。如果觉得喜欢,可以点击链接试用一下,试试又不要钱:)

我们要做什么

我们做的是一款 Serverless 数据库服务。


Serverless 是云原生架构下的一种新兴模式,关于 Serverless 网上有很多定义,大家可以自行搜索。Serverless 数据库简单来说,就是一款开箱即用,无需部署运维的数据库。国外 Serverless 数据库产品起步较早,也比较成熟,比如 PlanetScale, Neon, Cockroachdb, AWS aurora。


那我们实现 Serverless 数据库,是在实现什么东西呢?自动弹性,多租户,高可用,备份恢复。但其中最重要我觉得还是成本。成本是支撑这个模式走下去的基石。在成本上,我们经历了从一开始的上百美金一个集群,到现在的几美金一个集群。可以说成本的降低让 Serverless 模式成为了可能。


本文从成本的角度出发,来看我们是如何实现 TiDB Cloud Serverless 的。

基于对象存储的数据底座

在云上,相比于昂贵的块存储,对象存储便宜的多。


我们的存储层 TiKV 针对 AWS S3 做了适配,以共享存储的方式提供给租户。但 S3 的访问延迟相比于本地盘高了不少,为了解决这个问题,我们将高速本地盘作为缓存,用户读写实际会基于作为缓存的本地盘。TiKV 启动时会从 S3 拉取全量的数据到本地盘作为缓存。最近,我们正在开发冷数据存储的功能,该部分数据会仅在使用时才从 S3 拉取,并收取更少的费用。


TiKV 针对 AWS S3 的适配说起来简单,实际是最复杂的部分,这部分也是和开源 TiKV 区别最大的地方。使用 S3 作为共享存储还带来一些其他好处:比如海量数据存储,极高的可用性,秒级的备份能力,快速的 region 迁移等等。

计算资源池化

对于一款 Serverless 数据库来说,不仅要做到流量高峰时的自动扩容,也要做到流量低谷时的缩容,甚至要做到无流量时缩容到 0,即按需付费能力。而对于数据库来说,低延迟是必须的,也就是说我们既要缩容到 0,又要保证快速的冷启动。因此我们不能在客户请求时才拉起计算资源。


对此,我们将计算资源进行了池化,形成了一个 TiDB Pod 池。该池子由一个内部组件进行管理,保证池中空闲 Pod 数量一直处于限定的范围内,其空闲数实际反应了 TiDB Cloud Serverless 快速应对突发流量的能力。池内所有的 TiDB Pod 会处于 standby 模式,当请求来临时即可针对对应租户激活。整个过程是极快的,就犹如你始终占有该计算资源。


无状态的计算资源池,也使得我们可以使用 Spot Instance 节约成本。


Spot Instance 是云厂商提供的一种抢占式实例,相比于按量实例节点可以节省至多 90% 的成本,但其缺点是随时可能会被云厂商回收。计算池中的 TiDB Pod 就使用了 Spot Instance 实例,为了防止 Spot Instance 被回收,我们还有一个监控的机制。当监控到 Spot Instance 实例不足,会提前购买 on demand 实例防止 TiDB Cloud Serverless 的计算能力跟不上 。

统一网关层

在很早期,我们没有统一的网关层,这导致每一个数据库集群都需要一个 LB。我们目前运行了上万的集群,如果每个都有一个 LB ,那就会带来巨大的成本。


因此,我们有一个 TCP 网关层,负责统一入口,只需要一个四层 LB。该网关层主要负责 MySQL 连接协议的处理,在建立连接之后,网关层作为客户端与 TiDB 之前的桥梁——透传数据的传输。


在网关层,我们主要解决的一个问题是如何区分租户。在 MySQL 协议中,能够传输额外租户数据的地方不多:


  • Connection attributes:许多 MySQL client 不支持该特性

  • 数据库名:少许 MySQL client 不支持 (PHP)

  • 用户名


最终我们选择了使用用户名承载租户信息,这也是当你使用 TiDB Cloud Serverless 时,用户名前有个前缀的原因。

总结

在成本上,我们还做了很多。比如 Copy on write 的备份恢复机制, Txn File 降低大写入成本,Remote compaction 充分利用资源等等。相比于上文,这些内容更细节,这里就不一一展开了。上述内容也不一定完全准确,有问题麻烦大家多多指正~


总而言之,正是因为这些成本上的优化,才有了现在 TiDB Cloud Serverless 具备竞争力的价格。以及为所有用户提供 5 个免费集群的能力。对的,我们为每个用户提供总计 25G 的免费存储以及可观的计算额度,快试试创建一个属于自己的 Serverless 数据库吧。https://tidbcloud.com/


发布于: 刚刚阅读数: 2
用户头像

TiDB 社区官网:https://tidb.net/ 2021-12-15 加入

TiDB 社区干货传送门是由 TiDB 社区中布道师组委会自发组织的 TiDB 社区优质内容对外宣布的栏目,旨在加深 TiDBer 之间的交流和学习。一起构建有爱、互助、共创共建的 TiDB 社区 https://tidb.net/

评论

发布
暂无评论
我们是如何实现 TiDB Cloud Serverless 的 - 成本篇_TiDB Cloud_TiDB 社区干货传送门_InfoQ写作社区