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

作者: 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/
询问AI

相关推荐
阿里云云原生11 小时前
Agent 数据飞轮平台的选型和实践
云原生
做运维的阿瑞12 小时前
云项目可观测性与成本治理:告警、日志、Dashboard 与预算标签
大数据·云原生·云计算·terraform
无人生还别怕13 小时前
如何搭建k8s服务(containerd部署)
linux·云原生·容器·kubernetes·openanolisos
知已难寻13 小时前
01 · OpenStack的认证管理 Keystone
运维·服务器·云原生·云计算·openstack
分布式存储与RustFS13 小时前
模型权重散落在每台 GPU?用 RustFS 给 vLLM 做共享权重库
云原生·开源·对象存储·分布式存储·s3·rustfs·性能基准
fb_1234515 小时前
从探针到权限:一篇吃透 Kubernetes 健康检查、RBAC 认证授权与 Dashboard 可视化管理
云原生·容器·kubernetes
mengge.cloud15 小时前
10-28-Kubernetes健康检查认证授权与Dashboard
云原生·容器·kubernetes
做运维的阿瑞16 小时前
EKS 可销毁环境:集群创建、应用部署到账单归零
云原生·云计算·terraform
每天一道题16 小时前
微服务为什么会变慢?从 QPS、P99 到 Trace 与性能瓶颈
微服务·云原生·架构
时间售卖铺19 小时前
MySQL事务ACID与隔离级别深度解析
运维·数据库·mysql·云原生