在 TiDB 8.1 发布后，TiDB 展现了强大的支持 SaaS 业务的能力，成为 SaaS 业务数据库的优先选择之一。
本文为“当 SaaS 爱上 TiDB”系列文章的第一篇，系列文章将从技术原理和真实用户体验两个角度深入探讨 TiDB 在 SaaS 业务中的表现，包括如何应对可扩展性、多租户管理、运维便利性、高可靠性等挑战，后续文章将分别从资源隔离、弹性扩展、方便运维、业务架构等角度展开。通过这些内容，您将了解为何 TiDB 是高成长 SaaS 业务的最佳选择。
本文作者：唐刘，PingCAP 研发副总裁。
当TiDB 8.1 发布之后，我非常相信，TiDB 已经具备了支持客户 SaaS 业务的能力，甚至可以做为客户 SaaS 业务数据库的最优先选择之一，为什么我会这么笃定，主要信心的来源就是我已经看到了非常多的客户，来自不同的行业（譬如游戏，电商，AI，互联网等等），基于 TiDB 构建他们的 SaaS 业务的成功案例。
当然，成功并不是一蹴而就的，TiDB 也并不是从一开始就能支持好客户的 SaaS 的业务，所以后面，我会写一系列的文章，来聊聊 TiDB 是如何在 SaaS 业务场景下，如何一步一步赢得客户的『信任之旅』，以及说明下为什么 『TiDB 会成为你高成长 SaaS 业务的第一选择』。
什么是 SaaS，网上已经有太多的解释，这里简单的说明一下，SaaS 全称为软件即服务，新一代 SaaS 目前都是基于云计算的软件服务，通过互联网提供软件应用。用户无需在本地计算机或服务器上安装和维护软件，而是通过网络浏览器进行访问。SaaS 业务由服务提供商托管和管理，用户可以从任何有互联网接入的设备访问，并且通常采用订阅制，使其对企业和个人来说既方便又具有成本效益。从某一方面来说，TiDB Cloud 也算是一种 SaaS，后面如果有机会，我也可以写写我们是如何构建 TiDB Cloud 这个 SaaS 业务的。
SaaS 业务的挑战非常的大，对于数据库的要求尤其的高。通常一个数据库要支持好 SaaS 业务，会面临如下的一些挑战：
可扩展性- SaaS 业务一个非常有意思的点就在于你的业务的租户数量可能会从一点点突然就涨到了成千上万，甚至百万以上的级别，而单个租户数据也可能从 GB 级别疯涨到百 TB 级别。在整个业务增长，数据膨胀的过程中，数据库的可扩展性尤其重要：客户总不可能容忍因为数据库没法承载业务增长导致错过成长红利。
多租户的管理- 如何在一个数据库里面管理多个租户，既要确保这些租户之间的数据隔离以及安全，又要保证租户之间不能相互影响，是一件非常困难的事情。
方便运维- SaaS 业务另一个好玩的点就在于业务的快速变化，我们如何对数据库进行快速的变更以满足不断变化的业务需求，还有如何快速的对不同的租户进行数据备份，性能监控等等，在运维上面都是挑战。
高可靠性和高可用性- SaaS 业务的连续性非常重要，如果 SaaS 业务出现宕机，影响的可是成千上万的租户，这个损失客户是承受不起的。数据库需要稳定高可靠的长时间运行，即使出现最极端的情况，也要保证能快速的帮助客户恢复数据。
还有：高性能、数据安全和合规、成本等等。
可以看到，要支持好一个 SaaS 业务，对数据库的核心能力要求非常的高。下面我就来大概的介绍下 TiDB 是如何应对上面的一些挑战的。
如果你问我，要支持好 SaaS 业务，对于数据库来说，最重要的特性是什么？我会毫不犹豫的回答 - 『可扩展性』。一个不支持可扩展性的数据库是没法支持好客户的 SaaS 业务增长的。
说起可扩展性，我猜测，大部分的读者立刻能想到的就是数据规模的可扩展性，这个也是 SaaS 业务一个通用需求。而这方面，TiDB 具备天生的优势，因为 TiDB 从一开始就具备水平扩展能力，随着数据规模的增大，客户唯一需要做的一件事情就是不断地增加存储节点，TiDB 会自动的将数据进行切分打散到不同的存储节点，并且使用多副本的方式保证数据的高可用性。这块网上因为有太多的文章，就不详细的说明了。
不过，数据规模仅仅只是可扩展性一个方面的挑战，这里说另外一个例子，就是 schema 的可扩展性挑战。我们的一个客户，他在设计自己的 SaaS 业务的时候，让所有租户共用一套 schema 模板，也就是实际创建一个租户的时候，一个租户一个数据库，每个数据库里面有十几张表，所以不同租户除开数据库名字不一样，里面的表结构是一模一样的。最开始这个客户只有几千个租户，不过很短时间，租户数量直接直接涨到了 10 万个，这就意味着他需要在 TiDB 里面存至少 100 万级别以上的 tables，简化一点，我们就说 1M tables，我不确定有多少数据库有信心说能很好的支持好 1M tables 这个场景。坦白的说，当前我们只能说能承接 1M tables 这个场景，还有很多挑战需要攻坚，关于这块的，我后面也会有文章详细的说明。
除开上面两个例子，可扩展性还包括很多方面，这个我们会在后面的文章中具体解析。
下图是一个客户实际的例子，他使用 TiDB Cloud 提供的自动扩缩容功能，在一小时之内直接新增了 200 个计算节点，承载住了那一段时间的业务流量，然后在业务稳定之后，又下线了 50 个计算节点，节省了成本。
SaaS 业务以灵活多变著称，灵活多变就意味着业务逻辑调整的频繁，甚至会对数据库进行变更，而变更，恰恰是最容易引入故障的。
第一个最直接挑战就是 Schema 的变更，研发不可能一开始就规划好 Schema 设计，所以就很可能出现为了业务对 schema 进行变更的情况。可能有些读者会说，不就是做 DDL 操作吗，对数据库不就是小菜一碟？不过假设现在一个客户在数据库里面存了 10 万个租户，一次业务变更，可能要进行 10 万次 DDL 操作，中间的任何失败，以及执行效率变慢，都会影响到实际的业务变更，拖慢业务的迭代。
所以对于数据库来说，在 DDL 这块，需要具备如下关键核心能力：
1.Online DDL 能力，确保做 DDL 的时候不会影响在线业务。
2.失败重试管理，譬如能随时从中途某一个阶段恢复继续执行。
3.高效，快速，性能好，譬如如果要给一个 100TB 的表添加索引，需要小时级别就能搞定，甚至越快越好。
另一个挑战就是依据对业务的规划，对数据库进行扩缩容处理。譬如下一周如果有一个重要的活动，譬如最近的欧洲杯，或者游戏新功能上线，客户需要提前做好应对。这一块一直是 TiDB 的优势，上面也说到了，这里就不提了。
还有一个非常大的变更挑战，这个算一个低频的操作，不过真要做的时候，大家的头一定是非常大的 - 这个就是数据库版本的升级。SaaS 业务在这方面，挑战尤其突出：如果只能停机升级，这个对于客户来说，就会面对成千上万个租户的业务停机，对客户来说这个损失不可想象。另外，如果因为代码 bug（无论是 SaaS 业务自身，还是数据库自身），可能会导致一部分租户能正常工作，一部分租户出现问题，对于特定租户的数据修复，也是一个非常大的难题。
TiDB 从一开始就支持了 online upgrade，能让客户不停机，直接在线滚动升级，不影响客户的业务连续性。在 TiDB Cloud 上面，我们也提供了非常充分的升级解决方案，更进一步保证升级的成功。当然 TiDB 也还有一些挑战需要更好的解决，这个后面有机会再说。
下图是另一个客户跑的一个 SaaS 业务（某客户给我们提供的数据，做了脱敏处理）。他在 30 分钟时间内进行了 300 多次 DDL 变更，这里我们仅仅列出了 create table，还并没有列 drop，alter 的统计。实际上这个客户的 DDL 频繁一直如此频繁，而如此频繁的进行 DDL 处理，我只能猜测，客户实际已经是基于 TiDB Online DDL 特性，构建他自己的 SaaS 业务逻辑了。
多租户的支持是 SaaS 业务里面一个很重要的能力，对于客户来说，在数据库里面，一个很重要的难题就是我需要给这一个租户设置多少的资源，才能确保一方面这个租户的业务能正常运行，而另一方面则是不能影响到其它的租户。
这里其实就涉及到数据库里面资源隔离，或者资源管控的支持。在非常多的数据库里面，通过使用 cgroup 或者其他方式，提供了按照 CPU/Mem 等物理资源拆抽象的隔离方案，譬如我给租户 1 设置只能使用 8c16g 的资源，给租户 2 设置只能使用 16c32g 的资源，这种资源设置的方案非常的直观，客户也容易理解，为了便于说明，我们后面叫这个方案为 resource group(RG)。
相比于单纯的 RG，TiDB 提供了另一种抽象，我们叫做 request unit(RU)。为什么我们要提供 RU 的抽象，一个很重要的原因就是我们希望客户能更加细粒度的控制自己的资源，譬如对一条特定的 SQL 进行细粒度的控制。一个例子，在 RG 这个方案里面，我给一个租户设置了 16c32g 的资源，不过这个租户完全跑满了，那么到底是哪几条 SQL 占用了最多的资源，是不是需要控制这些 SQL 的资源开销？另外如果我发现一个租户一直没跑满过资源，我是不是要重新设置下它的 RG，不过万一这个租户在某一天突然又需要更多的资源，我如何来调整？这些都是一些比较有意思的挑战。
而使用 RU 的方式，是容易就能达到精细化控制的效果，帮助客户能更好的看清楚自己业务每一条 SQL 的资源开销，针对性的进行成本优化。如果你要对你的租户进行收费，RU 也可以提供更加细粒度的账单，方便你更好的设计你的定价模型。当然，RU 这个方案也并不是完美的。关于 RG 和 RU 的优劣，后面有时间，可以再来讨论。
因为现在的数据库几乎都能支持HTAP了，所以如何在一个数据库里面很好的处理 TP 还有 AP 的业务，也是在资源管控上面的另一个挑战。不少的数据库，在自己的存储层支持了行列混存的方案，而 TiDB 则是完全的将行列两种数据分别放到了不同的存储节点上面，从物理上面进行了隔离。
为什么我们要选择行列分离的存储方案，一个很朴素的偏见就是我们认为 AP 的查询都是会占用比较多的资源的，无论是 IO 还是 CPU，在物理层面上面 TP 和 AP 分开，会显著的减少 AP 对于 TP 的影响，做到更好的，更彻底的隔离。行列混存方案在资源充分的情况下工作的很不错，不过当资源吃紧的时候，我们并不相信这样的方案能很好的保证 AP 不会干扰 TP。而 TP，恰恰是客户跑得最重要的业务。关于这两个方案的优劣对比，后面有时间，也可以再来讨论。
下图是一个客户在 TiDB Cloud 使用 RU 的效果（客户自己提供的监控数据），可以明显的看到，在设置好 RU 之后，租户之间的影响降低了，整体的 TP 业务更加的稳定。
上面仅仅只是列举了一些 TiDB 如何支持好客户的 SaaS 业务的例子，可以看到，我们实实在在的助力了客户 SaaS 业务的增长，帮助这些客户成功，能赢得这些客户的信任，是我们的荣幸。
当然，离真正的让任何的 SaaS 业务在 TiDB 上面都能完美顺畅的直接运行，我们还有很长的一段路要走。在后面的系列文章中，我会详细的介绍 TiDB 在 SaaS 业务场景中一系列具体的挑战（譬如 1M tables，资管隔离等） 以及我们是如何应对的。我也会介绍一些客户是如何基于 TiDB 构建他们自己 SaaS 业务的最佳实践。
在产品方向上面，SaaS 业务的支持也会做为今年以及未来几年 TiDB 重点的发展方向，所以如果你的业务是 SaaS 业务，需要选择一款数据库，不要犹豫，请从现在开始使用 TiDB。即使当前可能在一些方面 TiDB 会有一些问题，我们也会跟你一起努力，共同克服难关，在助力你 SaaS 业务增长的同时，也一起将 TiDB 打造成全世界上『高成长 SaaS 业务的首选数据库』。
热门跟贴