数据库 Schema 变更大概是应用开发中风险最大的领域 - 这个过程充满了困难程度、风险和痛苦,今天我们来盘点一下最佳数据库 Schema 迁移工具,从最基础的 CLI 到吸纳了相对较新理念的 GitOps / Database-as-Code(数据库代码化)的工具,看看有什么工具可以缓解痛苦?
命令行客户端 CLI - mysql / psql
mysql 和 psql 是最直接的可以与 MySQL 和 PostgreSQL 交互的工具,你可以从命令行直接向 MySQL 或 PostgreSQL 服务器发送命令或查询。虽然 CLI 界面简单,对于新手可能也不是很友好,但是上回看到 Timescale 做的 State of PostgreSQL 2022 调研 (https://www.timescale.com/blog/state-of-postgresql-2022-13-tools-that-arent-psql/) 说 psql 是最流行的与 PostgreSQL 交互的工具,甚至超过了有 GUI 的工具 pgAdmin 和 DBeaver 🤯。
图形用户界面(GUI)
phpMyAdmin, pgAdmin
phpMyAdmin 和 pgAdmin 是非常老牌的经典 SQL 客户端。phpMyAdmin 现已发展成管理 MySQL 和类 MySQL 数据库(比如 MariaDB)的最主要工具之一,pgAdmin 则是用于管理 PostgreSQL,现在已经出到了 pgAdmin 4。相比 CLI 工具,phpMyAdmin 和 pgAdmin 提供了可视化的图形界面来运行 SQL 命令和执行 SQL 操作,非常易于使用。
DBeaver
DBeaver 是一款老牌 SQL 客户端,比前面两款工具进阶一些,支持的数据库(SQL 和 NoSQL)种类相当齐全,最近的热点 AI 他们也没落下,DBeaver 已经支持把自然语言转换成 SQL。Navicat
Navicat 是一款历史悠久的图形化数据库客户端,第一个版本推出于 2001 年,从一开始只支持 MySQL,后来又陆续加上了更多数据库种类。Navicat 的界面虽然有些陈旧,但是功能齐全,整体操作数据库体验流畅。不过如果你还在用 Navicat 连数据库,What are you doing?
GitOps / Database-as-Code
为了更妥善管理和记录数据库 Schema 变更,许多工具把代码变更的流程引入到数据库变更,也就是数据库即代码(Database-as-Code)。Liquibase
始于 2006 年,Liquibase 可以说是这一领域中最知名的产品。冷知识:Liquibase 2012 年被一家叫 Datical 的公司收购并且改名了,2022 年又改回了 Liquibase 以巩固品牌形象(明智)。如果有人在 Reddit 或者 Stack Overflow 上求推荐数据库 schema 变更工具,下面的回答大概率会提到 Liquibase 而不是 Datical。Liquibase 既是一个开源项目,也是一个提供其商业产品的公司,它提供开源版、Pro 版和 Enterprise(企业)版。它的主要产品是一个基于 Java 的 CLI,开发团队可以通过 CLI 将数据库 schema 迁移整合到他们的 CI/CD 工作流中。可能是由于它是 Java 的根基,最常用的形式是 XML(YAML 和 JSON 的支持是后来加上的),也支持普通 SQL(需要适当注释)。Flyway
Flyway 在很多方面和 Liquibase 有相似点:他们都历史悠久,有庞大客户群,都是开源项目。它的核心产品是一个 CLI 和一个 Java 库。Flyway 背后的商业实体是 Redgate(2019 年将其收购)。它提供社区(开源)版、Team 版($597 用户/年)和 Enterprise(企业)版。能看出他们在开源和商业产品之间设定了一个界限,Flyway 有一种更随性的感觉。
Flyway 的网站虽然不像现在 DevTools 公司那么闪亮耀眼,不过他们最近更新了一下文档站,之前的一些基本 UI 问题也得到了解决🙏,虽然内容比外观美丽更重要,但是看起来舒适确实会让工作幸福感得到极大提升。Liquibase 和 Flyway 不相上下,主要的区别在于它们各自的定位。Liquibase 比较适合企业用户,而 Flyway 更适合开发者。Sqitch
Sqitch 是一个纯开源项目,没有商业版本,在市场上有一段时间了(2012 年开源)。Sqitch 是纯 CLI,没有 UI。与基于 Java 的 Liquibase 和 Flyway不同,Sqitch 是用 Perl 开发的。此外,Sqitch 在如何管理数据库 schema 变化方面有自己的理念:Liquibase 和 Flyway 都使用文件命名方式来控制 schema 迁移行为(惯例高于配置,Bytebase 也使用这种方法)而 Sqitch 采取的方式是使用命令来进行 schema 迁移,这赋予了团队更多的权力,将数据库版本部署接入应用开发周期。Atlas
Atlas 是一个很摩登(去年才亮相)的数据库 schema 管理工具,它有开源(自部署)和 cloud 版,由一家叫做 Ariga 的公司维护。深受 HashiCorp 的影响,它在 HackerNews 上的首次亮相就自称 Terraform for Database Migrations。他们甚至根据 HCL (HashiCorp Configuration Language) 发明了 Atlas DDL(数据定义语言)。在此基础上,Atlas 以 CLI 为中心(类似 Liquibase / Flyway / Sqitch),不过它也有一个轻量级的 UI。Altas 的优势在于用了现代编程语言 Go(而不是 Java),并从 Terraform 和 Prisma 等工具中汲取了不少经验。
GUI + GitOps / Database-as-Code + 团队协同
对于想要建立一个可持续的全栈应用的前端工程师来说,TypeScript / Express.js 解决的是代码问题;MongoDB 这样的 NoSQL 数据库解决的是数据问题;Prisma 解决的是最后一个问题,即数据 <> 代码。Prisma
虽然数据库 schema 迁移属于后端范畴,但 Prisma 是一个具有前端根源的 ORM。对于前端工程师来说,可用性和可访问性尤其重要,他们可能并不精通 SQL,为了降低管理数据库 schema 的门槛,Prisma 使用 Prisma schema file: `schema.prisma` 来定义数据模型。DSL 是基于状态的(声明式),即描述了目标数据库 schema 的预期最终状态,而不是增量变化,这与 Liquibase / Flyway / Sqitch 不同,Prisma 在整个应用程序开发周期中提供了一个更全面的数据库数据和模式管理视图。Prisma ORM 开源且免费,他们的 Data Platform 提供了一个云上可协作平台,包括了一些进阶功能(看得出他们的野心绝对不局限于一个 ORM 和 schema 迁移工具)。Bytebase
Bytebase 是一款开源和商业并行的 Database DevOps 平台,能够管理整个数据库的开发生命周期,一站式覆盖各种数据库的变更,查询,安全,治理场景。
Bytebase 提供了可视化的变更审核界面,开发者和 DBA 可以在同一个界面上对于数据库变更进行协作。为了更好兼容开发者的工作习惯,Bytebase 将其能力集成到了代码仓库如 GitLab, GitHub 中,配置好 GitOps 工作流后,开发者可以在熟悉的代码仓库中提交数据库的变更文件,在审核完成提交到代码仓库后,会自动触发在 Bytebase 这边的部署流程,避免了在多个工具中切换。Bytebase 支持在工作空间(Workspace)和项目(Project)两个层级定义成员的不同角色,赋予团队成员在不同项目的不同角色和权限,并且基于不同角色配置审批流,比如指定具体该项目的 DBA 或测试负责人。
Prisma 和 Bytebase 之间的区别主要体现在,Prisma 主要是面向前端/全栈开发者的,Bytebase 则是更多面向后端和 DBA 的。两个产品都提供了协同能力,Prisma 针对的是单个业务团队内的开发者之间的协同问题,而 Bytebase 针对的是整个企业内的协同/数据安全/治理,开发者和 DBA / 平台工程 / 运维团队之间的协同问题。
总结一下
如果是个人操作数据库,那么经典的 CLI 或者像使用 Navicat 这样的 GUI SQL 客户端就能满足需求。如果需要和代码库集成,那么像 Liquibase / Flyway 也提供了解决方案。但要提供像类似 Jira, GitLab 这样完整的 GUI 界面,完善的项目协同能力,可选的就只有 Prisma 和 Bytebase 了,而其中也只有 Bytebase 可以进一步提供组织层面的管理能力,在让数据库变更变得更加稳定/高效的基础之上,也能保障企业中的数据安全和合规问题。如何使用 Bytebase 快速实现 SQL 自动化
PostgresML|几乎蹭上了所有热点:向量数据库, AI, Serverless, Postgres
16 年等待,再见 SQL Boy,这一次数据库交互形态彻底被颠覆了!
常见的数据库 schema 变更错误