查看原文
其他

数据库代码化——黄金三镖客

天舟 Bytebase 2022-05-27
标题借用了电影「The Good, the Bad and the Ugly」的中文翻译 「黄金三镖客」
原文标题| Database as Code - the Good, the Bad and the Ugly原文链接| https://bytebase.com/blog/database-as-code


在讨论「数据库代码化 (Database-as-Code / DaS)」之前,让我们先讨论一下一个更普遍的概念,即 “配置代码化 (Configuration as Code / CaC)”。CaC 是在代码库中管理配置资源的做法。典型的配置资源包括:

  • 基础配置,如计算 (虚拟机),网络资源 (负载平衡器)。由于 HashiCorp Terraform、AWS CloudFormation 等工具的流行,这一系列资源配置被称为「基础设施代码化 (Infrastructure-as-Code / IaC)」

  • 监控和告警配置

  • 访问权限控制策略 (Identity and Access Management / IAM)

  • 持续集成 (Continuous Integration / CI) / 持续交付 (Continuous Delivery / CD) 配置,如 GitHub Actions, GitLab CI

  • 功能开关 (Feature Flag)

  • 最后也是最重要的,我们今天的主角,数据库 schema,又称「数据库代码化 (Database as Code)」


对于一些类型的配置资源,在代码库中管理它们已经成为事实标准,比如用 HashiCorp Terraform 管理基础设施,通过 Prometheus 管理监控 / 告警配置。


另一方面,在代码库中对其他类型的配置资源进行管理尚不普遍,如数据库 schema。证据之一就是数据库代码化还没有自己的维基百科页面。


与管理应用程序的代码一样,管理应用数据库 schema 也是软件开发过程中的日常操作。而说到变更数据库 schema 的实践,则有 3 套方案:

  1. 直接连接到数据库,并进行 DDL 变更。简单直接,但容易出错。

  2. 开发人员通过一个审核控制台,提交一个 DDL 工单,由 DBA 进行审核。DDL 在审核通过后由控制台自动把 DDL 变更到数据库中。这通常被称为 SQL 审核 (SQL Review) 流程。

  3. 所谓的「数据库代码化」,在如 GitLab / GitHub 的版本控制系统 (VCS)
    中管理数据库 schema,如 GitLab / GitHub。每当开发人员想要进行 schema 变更时,她会创建一个包含这些 DDL 语句的 schema 变更文件并
    将该文件提交审查。当审查通过后: 如果自动化程度较高,该变更将触发流水线,自动应用到数据库中;如果自动化程度不高,开发人员仍会使用第一种方法,直接连接到数据库,手动进行变更。



好的 (The Good)


目前业界已经达成共识,认为「配置代码化 」是优于通过 UI 界面进行配置的方法。相应的,将数据库 schema 进行代码化也不例外。在我们看来,schema 代码化有 3 大优点:

  • 充分利用现有的代码库基础设施,避免重复工作。我们可以免费获得诸如代码版本 / 分支管理、代码审查、代码搜索等功能。像 GitLab / GitHub 这样的产品已经在这些方面投入了巨大的资源。

  • 与持续集成 (CI) 和持续交付 (CD) 的 DevOps 工作流程保持一致,通过回放 (replay) 存储在仓库中的 schema 变更文件,自动准备本地/测试数据库的过程。

  • 拥有唯一的可信来源 (single source of truth / SSOT),即存储在仓库中的数据库 schema 文件。有了 SSOT,开发环境可以在不连接到生产数据库的情况下进行诸如 schema 漂移检测 (schema drift detection)、分析数据库 schema 这类的操作。没有开发环境下的 SSOT,这样的操作是很困难的,因为生产网络通常与开发网络相分离。



坏的 (The Bad)


从纯技术的角度来说,「数据库代码化」就是管理数据库 schema 的最佳实践。

实际上,10 多年来每个谷歌工程团队都是在代码库中对数据库 schema 进行管理的。

但与其他方法相比,落地这一方法的主要障碍仍然是学习曲线,以及遵循最佳实践所需要的工程纪律。实话实说,如果实践的前提是需要谷歌级别的工程素养,也有点不切实际了。


丑的 (The Ugly)


所以说「数据库代码化 」虽然听起来挺诱人,但在现实中,有不少缺失的环节阻碍了它被广泛采用。

困难的初始化配置

首先团队要搞清楚如何组织 schema 文件以便管理不同环境下的数据库 schema 变更。而如果想要设置一提交 schema 变更文件便能触发 schema 变更的自动化工作流,需要:

  1. 通过 OAuth 获得 VCS 实例的 root 访问权限,然后在 VCS 项目中设置适当的 webhook,并要正确设置监听的仓库目录。

  2. 在此基础上,团队还会自定义规则,比如只允许 dev, test 环境的数据库 schema 变更可以自动进行,而仍然针对生产 (production) 环境的变更进行人工审核。


进程缓慢 - 没有持续正反馈

使用「数据库代码化」的变更流程肯定要比直接连接数据库进行变更要麻烦。即使和基于 UI 界面的 SQL 审查过程相比,也繁琐了许多。另一方面,尽管我们从 VCS 中得到了一些有用的功能 (比如版本管理), 但是需要花更多的力气来解锁它真正强大的功能:
  • 类似 schema 漂移检测这样的功能只有在代码库和数据库服务器之间具有
    更深的集成时才可能实现,前者需要存储代码版本的信息,后者需要存储 schema 的所有变更历史记录。

  • 除了数据库和代码库,它还需要更高层次的抽象来对协作开发工作流进行
    建模,比如像项目 (project),工单 (ticket) 这样的容器,以提供一个完整
    的解决方案。

  • 为了构建一个真正自动化的数据库 CI 流水线,它不仅需要回放 schema 变更文件,而且还需要构建测试数据,这通常需要与应用逻辑的集成。


可运维性欠佳的开源数据库

从核心功能来看,MySQL 和 PostgreSQL 都是功能强大的开源数据库。然而,相比于商业化数据库来说,两者的可运维性都堪忧。举个例子,这两个数据库都没有内置的 schema 版本管理支持,这就加大了搭建 schema 变更工具的难度。


💡 Bytebase - 降低数据库 schema 变更的门槛,特别是为落地 DBA 和开发者协作场景下的「数据库代码化」最佳实践

Bytebase 团队在数据库方面已经深耕 10 多年了,曾经在 Google Cloud SQL 和蚂蚁集团 OceanBase 管理过全球数一数二规模的数据库集群。我们做 Bytebase 就是为了扫清团队在采用「数据库代码化」这个最佳实践中的障碍:

  • 我们为团队提供了一个 web 控制台,以便在数据库相关任务上进行协作。

  • Bytebase 为用户提供细化到每一步的点击向导, 来进行「数据库代码化」和  诸如 GitLab 这样代码仓库相关的初始配置。

  • 如果用户还不想一步走到数据库代码化的方案,Bytebase 也提供完全基于 UI 界面的 SQL 审查解决方案。


Bytebase 针对 DBA 和开发者的协同场景进行了顶层设计,抽象出了如「项目」、「工单」、「环境」、「实例」、「数据库」、「数据源」这些模型,以帮助团队采用最佳实践来管理数据库 schema。

我们将所有与结构变化相关的活动都一览无余地展示在界面上,如 schema 变更步骤,schema 变更历史。如果配置了比如 GitLab 的集成,也会展示相关信息。



还有一些其他的功能,篇幅所限无法一一介绍,我们当前也在积极努力增加更多的功能。我们的目标就是要大大降低门槛,让团队可以用上管理数据库 schema 生命周期的最佳实践,这就像 GitLab / GitHub 使得团队管理代码声明周期的门槛大大降低一样。当前 Bytebaes 先从目前最流行的两个开源数据库系统 MySQL 和 PostgreSQL开始,来逐步实现这一目标。

BTW,如果你喜欢这篇文章,你可能也会对我们的产品 Bytebase 感兴趣,这是一个开源的、网页版的 schema 变更和版本控制工具。试试我们的实时演示或查看我们的安装指南(只需一个命令行,如果你已经有了docker,5秒钟就可以完成安装)。


您可能也对以下帖子感兴趣

文章有问题?点此查看未经处理的缓存