什么？比 MySQL 性价比更高的 TiDB Cloud Serverless Tier 来了？

PingCAP 2022-12-13

1553

每隔一段时间，TiDB 会发布一些关于架构演进的大新闻。比如 2020 年的 TiFlash 和 HTAP，2021 年的 MPP，比如今年的 TiDB Cloud。在靠近年底时，我们很高兴又有大新闻可以跟大家说：TiDB Serverless 内嵌下一代云原生架构上线了。

面向经济适用场景

一直以来 TiDB 都是面向大体量关键在线业务而设计的，这使得我们的产品定位也偏向这类场景。而实际上，作为一个通用型数据库，除了大体量关键业务之外，TiDB 也在无数用户的非关键或者中小规模场景发挥着巨大作用。例如历史数据查询，实时数据服务和洞察，温数据存储，SMB 场景等，这类场景无疑和关键在线业务的看点与需求都有相当大的不同：例如对成本更敏感，存储和计算资源比更大，更看重弹性以及按需伸缩等等。TiDB 单一产品要兼顾这些不同的场景，会显得力有未逮且定位模糊。现在我们新推出的 TiDB Serverless Tier 正是为了解决这个问题而设计的。

新云原生和 Serverless Tier

云原生一直都是诸多数据库厂商发力目标，但非常少有人能解释清楚何为云原生。作为数据库厂商之一，我们认为云原生意味着借助云上基础架构提供远强于私有部署的能力。例如云原生架构的先驱之一 Snowflake，借助云对象存储和虚拟机资源池，提供非常低成本的存储以及非常弹性的计算能力，这是任何私有部署的数据仓库平台完全无法企及的「超能力」。将存储委托到云端对象存储使得数据库拥有超高的可用性和持久性，但与此同时也需要仔细处理随之而来的高延迟。因此，重度依赖 S3 作为存储之前都是分析型数据库的专属设计。但 TiDB 迈出了全新一步。

TiDB 在新的云原生架构下，原创性地借助由本地缓存辅以便宜可靠的对象存储作为主存实现了更低成本，更具弹性，甚至更高性能的存储架构。TiDB 在原有架构中，数据是分别存储在各个 TiKV 的 RocksDB 中，每次写入会通过 Raft Log 向各个副本同步。在新架构中，数据在保留原有的 Raft Log 传输机制确保快速写入的基础上，将经由 S3 来同步不同副本的持久化数据，这种设计在不引入更高延迟的前提下，获得了诸多云原生特有的优势。
另外，计算资源则由池化的虚拟机提供资源，这使得计算节点（TiDB 和 TiFlash）随时可以按照负载弹性变化。

更少的消耗

在新的架构中，TiKV 的写入不需要在多个副本之间重复应用，而只需改变主副本并经由对象存储向其余副本扩散，这使得写入的 CPU 消耗由三倍大幅减小到略高于一倍，整体存储层可以达到 30% 乃至 50% 的 CPU 效率提升（或者理解为成本下降）。

更高的稳定性，更少的资源预留

由于主存改为共享的对象存储，在新架构下，诸如 LSM 整理、Analyze Table，Add Index，甚至 BR 等以往间歇性干扰正常作业的操作，得以委托到独立的微服务中，按需获取资源并运行。以往，用户需要为此预留 1/3 ~ 1/4 资源，而在新架构下则不再需要这些预留，且性能将更稳定。与此同时，由于无需兼顾业务稳定，诸如备份等重量级操作，可达数量级的速度提升。

对温数据存储更友好

在新设计中，不同 Region 不再共享同一颗 LSM 树，从而大幅降低了层数，提升了读写性能，且能承受远超以往的 Region 大小，降低 Raft Region 相关的维护开销。这也使得单 TiKV 节点的存储容量上限可远大于现有的 4T 上限，对于温数据存储场景，我们可以选择更少的单节点 CPU 以及更大的存储（1~2倍存算配比提升），大幅节省单位存储所需计算资源。

超高的弹性

在以往设计中，TiDB 计算层的弹性较为容易实现，但存储层扩缩容实际需要经由 Leader Region 向目标节点写出副本数据以实现搬迁。由于这个动作需要占用一定量的资源，因此我们不得不限定副本迁移的速度以防影响在线业务的运行。而在新架构下，数据存放于几乎可视作无限带宽的对象存储，数据均衡将仅仅受限于节点本身的入口带宽，这使得存储层扩缩容可以以原本 30 倍甚至更快的速度完成。这大大提升了 TiDB 应对更频繁流量涨跌的能力，也使得用户可以真的仅仅为所需的负载规划资源，例如，白天和夜晚使用不同量的资源以大幅降低成本。除此之外，在 Serverless 下 TiDB 配合资源池将更好地提供基于负载的资源弹性伸缩，使得低负载时无需为空转的资源付费。

所以？这又如何？

TiDB 在大家认知中，往往更合适中大型规模的数据量（TB 规模以上），毕竟如果单机 MySQL 所能处理的规模下，之前的 TiDB 设计并不具备更好的性能和性价比；此外，虽然具备不错的弹性，但我们也经常遇到用户白天和晚上短时间内的负载有非常大差异，但集群却无法快速伸缩以节省资源的例子；而在中低负载下的温数据存储场景，TiDB 的固有消耗也使得部分用户对其保有成本有所顾虑。
但在新架构下，Serverless Tier 提供了一个更好的选择：它在业务启动负载较低的情况下提供了优于 MySQL 的性价比，独特的 HTAP 能力而无需建立复杂的分析平台，内置的高可用而无需担心业务连续性；而随着业务的不断增长，用户也完全无需重新规划和选型新数据库，TiDB Serverless 可根据负载上升持续提供良好的性能和弹性的资源。无需为未来可能的业务增长预先垫付数据库支出，这在当前的经济环境下，是一个值得考虑选择。

欢迎品尝

针对 5 GB 以下的小规模应用，新的云原生架构搭配 Serverless 已经在 TiDB Cloud （AWS）以免费的形式提供给广大用户，点击文末阅读原文即可注册 TiDB Cloud 体验 Serverless Tier。而如果你想尝试更大规模场景，欢迎直接联系我们，在「PingCAP 订阅号」后台回复【serverless 交流群】可以加入微信群与我们讨论。

💡 点击文末【阅读原文】立即体验 TiDB Cloud Serverless Tier！

文章转载自PingCAP，如果涉嫌侵权，请发送邮件至：contact@modb.pro进行举报，并提供相关证据，一经查实，墨天轮将立刻删除相关内容。

什么？比 MySQL 性价比更高的 TiDB Cloud Serverless Tier 来了？

评论