有了 Serverless 数据库，用户就不需要 DBA 了吗？

作者 | 冬梅

随着 5G 和 AI 等技术的发展，作为 IT 系统核心基石的数据库技术也在持续演进，从复杂走向简单。

近年来 Serverless 概念的热度颇高，Gartner、Forrester 等知名咨询机构对 Serverless 投来关注的目光，AWS、阿里云、腾讯云等云计算大厂也在不断布局 Serverless 相关产品。可以说与 Serverless 的结合，再次为数据库的发展添了把火。

Serverless 数据库 是一种基于 Serverless 架构的数据库服务，它结合了云数据库和 Serverless 两者的优势。Serverless 数据库更加适用于 IoT 边缘计算、开发测试、无法预估负载等场景，这些场景平均负载比较低，资源大部分时间可能都是闲置的，使用 Serverless 后，可以节约大量成本，最高可节约 90%。

与传统的云数据库相比，Serverless 数据库具有以下特点：

• 自动匹配资源：根据用户的业务负载，自动匹配相应的资源，无需用户预估业务规模，从而节省了大量精力；
• 按需付费：用户只需根据实际使用的资源付费，无需关心底层基础设施服务，实现了真正的按需付费；
• 降低数据库选型难度：用户无需关心数据库选型，只需关心自身业务即可；
• 减轻 DBA 运维工作：Serverless 数据库可以根据流量洪峰自动弹性伸缩资源，为业务运行提供强有力的保障，大幅度减轻 DBA 的运维工作量；

在 Serverless 概念爆火之际，各厂商纷纷摩拳擦掌推出 Serverless 数据库。近日，InfoQ 有幸采访到了泽拓科技（KunlunBase）创始人 &CEO 创始人赵伟，听他聊一聊 KunlunBase Serverless 版本数据库背后的思路及对未来 Serverless 趋势 对思考。

InfoQ：您能介绍下 KunlunBase Serverless 版本数据库的设计思路是怎样的？

赵伟：Klustron（曾用名 KunlunBase） 的设计目标是支持水平弹性伸缩的分布式数据库，同时支持金融级高可靠性。我们充分发挥了 PostgreSQL 和 MySQL 两款开源单机数据库系统各自的优势，在其中增加了大量自研的内核模块，完成诸如分布式事务处理、分布式并行查询处理、分布式 DDL 事务处理和复制，全局死锁处理，全局多版本并发控制，fullsync & fullsync HA，自动化的故障恢复，集群物理和逻辑数据备份和恢复，集群双活和多 IDC 高可用，等等一系列分布式数据库特有的新功能，并且改造了其中部分模块，最终把它们糅合成为有机协作的组件，实现了上述设计目标，达到了 1+1>>2 的效果。

InfoQ：Serverless 版本更适合哪些应用场景？从 0 到 1 的技术路径是怎样的？

赵伟：KunlunBase Serverless 基于 KunlunBase，增加了租户管理、数据隔离、以及为计费而增加的使用量统计等功能，并且限制了多租户场景下集群管理的部分功能，确保这些功能不暴露给租户，只有我们作为服务提供商才能使用。Serverless 版本适合的场景：

• SaaS 场景：相同的业务逻辑，不同的用户规模，不同用户的业务规模增长速度也不同；
• 统一的数据平台：大公司内数据平台部门，提供类似私有云的 DBaaS 给公司各部门或者各个产品、服务条线使用；
• 公有云 DBaaS 服务商；

InfoQ：在使用过程中，数据库的使用成本是客户在数据库选型时会着重考虑的问题。那么，Serverless 版本的计费原则是怎样的？

赵伟：KunlunBase Serverless 根据每个租户存储的数据量，以及使用的计算资源数量来设计计费规则。基于 Klustron 分布式数据库的现有能力，构建 Serverless 模式 的 DBaaS 的复杂度相对可控。

KunlunBase Serverless 概述

Klustron（曾用名 KunlunBase）目前在 AWS 上线的 DBaaS 服务就是 Serverless 模式运行的。

KunlunBase 使用 AWS 的 EC2 节点和 EBS 存储服务部署了一个 KunlunBase 集群，用它为多个租户提供 KunlunBase Serverless 服务。泽拓科技负责运维部署在 AWS 的 KunlunBase 的集群，用户完全不需要安装、运维 KunlunBase 集群。在运行期间只要按需增加更多的 EC2 节点和 EBS 存储空间，就可以提供更多的存储和计算能力给当前租户和更多的新租户。

每个租户使用其私有账户和密码连接到 KunlunBase Serverless，并读写其数据。任何租户无法访问其他租户的数据，也无法知晓集群当前有哪些租户在使用。

那么，KunlunBase Serverless 背后的技术实践是怎样的？在过程中又遇到了哪些技术难题？在采访过程中赵伟对这些问题进行了详细解答。

Klustron Serverless 技术实践

数据隔离

数据隔离对于多租户模式的 DBaaS 来说是至关重要的，系统必须确保任何一个租户无法访问其他租户的数据，甚至无法看到其他租户有哪些 database、schema,、table 等数据库对象 --- 这些对象的存在性和名称对其他租户都必须是不可知的。

昆仑数据库团队利用 Klustron 的 database 的隔离能力，来实现不同租户的数据隔离。KunlunBase Serverless 的每个租户可以连接到其专属的 database，执行 DDL 和 DML 语句。租户可以在其 database 内创建 schema 实现数据的逻辑分割。但是租户不可以使用 DML 语句读写系统 catalog 中的元数据表。

与 MySQL 不同，一个客户端连接到一个 database 后，无法通过 USE 命令或者 mysql_select_db() 切换到其他 database。同时，租户无法连接到其他租户的 database，KunlunBase 通过权限设置确保这一点。KunlunBase Serverless 的业务逻辑为每个租户创建其在 KunlunBase 集群的专属账户，并配置适当的权限，详见下文：

用户账户

每个租户需要使用专属用户账户来使用 KunlunBase Serverless，这样才能实现访问控制和其他高级管控功能。

当用户通过 AWS market place 的 DBaaS 购买界面买到一个 KunlunBase Serverless 后，购买流程中的内置逻辑会使用用户提供的数据库连接用户名和密码，在 KunlunBase 集群创建该用户的账户。每个账户配置的权限禁止它连接或者访问其他租户的数据库，不能创建账户和 database，非超级用户，也不能继承或修改权限。这个账户是这个租户的主账户，他可以使用此账户创建更多的子账户，用于其内部的权限控制。还可以在其数据库中为其不同业务创建多个 schema，分配给不同的子账户，分别给各个业务使用。所有这些子账户都只能连接此租户的数据库，并且 KunlunBase 的管控模块会合并他们对计算资源的使用量，以便 AWS 计费系统统一为此租户计费。

租户集群管控

泽拓科技扩展了 KunlunBase 的 XPanel 集群管控系统成为 XPanel Serverless，让它为每个 KunlunBase Serverless 的租户提供独立的和有限的管控功能。相比于 on premise 部署的 KunlunBase 集群，诸多集群管控功能不适用于 KunlunBase Serverless 的租户，包括扩缩容，增加 / 删除集群节点和存储 shard，集群物理备份和恢复，全集群的逻辑备份和恢复，多可用区（多机房）高可用，同城 / 异地集群双活等功能不再适用。仅有 database、schema、table 级别的逻辑备份恢复、online DDL & repartition、CDC 等功能继续有效，并且租户使用 CDC 功能只能导出租户自己的 database 的数据更新事件流。每个租户使用其用户名密码登录 XPanel Serverless，且只能访问和操作该租户所拥有的数据库以及其中的 schema 和 table、存储过程等。

后台集群管控

泽拓科技作为 KunlunBase Serverless 的技术服务方，负责 KunlunBase 集群的管控，包括扩缩容，增加 / 删除集群节点和存储 shard，集群物理备份和恢复，全集群的逻辑备份恢复，多可用区（多机房）的高可用，同城 / 异地集群双活等功能。通过 XPanel 使用管理员账号登录集群完成这些功能。

日志访问控制

KunlunBase 支持使用 ElasticSearch 收集集群所有节点的日志，出于数据安全的考虑，这些日志只有我司技术支持人员在后台集群管控界面可以访问全部日志，租户无法访问其他租户的操作产生的日志。租户只能访问其数据库对应的接口 SQL 日志（即计算节点发给存储节点的 SQL 语句），存储节点的慢查询日志，以及计算节点中的慢查询日志和 SQL 日志。

资源隔离

目前 KunlunBase Serverless 采用集群可以使用到的所有计算资源来执行来自每一个连接客户端的每一个 SQL 语句，并没有做资源隔离。从用户角度看，没有资源隔离的 KunlunBase Serverless 是非常划算的。这里对用户唯一的限制是连接数量，这个参数是在用户购买 KunlunBase Serverless 服务时提供的，并且这个参数也会作为计费的基础参数之一被使用在计费规则中。

在 Serverless 模式下，传统使用 cgroup 做资源隔离的做法不再合适，因为 KunlunBase 任何一个存储节点的进程 / 线程可能在服务任何一个租户，与租户没有 1 对 1 的对应关系。因此，如果要针对租户做资源隔离，就要统计租户的资源消耗并做资源调度，这些工作本身也会消耗可观的 CPU 和内存资源。所以，目前泽拓科技还没有做这方面的工作，赵伟表示以后会适时完成。

InfoQ：您认为当前 Serverless 数据库还面临哪些挑战？又有哪些应对之策？

赵伟： 缺少精确的资源隔离和用量控制，这需要较多系统级开发工作量。目前我们的做法是不做资源隔离，而是让用户充分使用计算资源来服务其请求。同时，我们作为 DBaaS 服务提供商，我们能够即使发现这种资源吃紧的情况，从而迅速提供更多计算资源来服务更多用户请求。由于按量计费，所以这样做对厂商来说其实是更有利的。

InfoQ：您是如何看待未来 Serverless 数据库的发展趋势？会有怎样的机会？

赵伟： 未来 Serverless 的数据库服务对中小用户还是很有吸引力的，因为 Serverless 模式大大简化了数据库运维管理工作，用户的 DBA 的工作负担大幅降低，可以专注于查询性能优化，Serverless 服务状态监控，数据访问控制机制管理等工作。用户的数据库使用成本也会相应大幅降低。从这个角度看，Serverless 就是一种共享 DBA 的技术。

采访嘉宾：

赵伟，泽拓科技创始人 &CEO 创始人