工程团队如何合理地管理数据库访问
一直让 DBA 或者负责运维数据库的团队头疼的事情,是如何合理地管理数据库的访问。一方面,数据库运维团队希望能中心化地管控数据库的访问,但另一方面,使用数据库的开发团队希望可以随时随地就能访问数据库。
前者的极端就是,所有访问数据库的行为,都需要经过数据库团队的审批,这会导致数据库团队成为瓶颈,拖累产品交付进度,被研发团队不断投诉。
数据库访问场景
响应用户从网页端/移动端发出的请求 (end user initiated),通过应用服务器 (Application Server) 对数据库进行的增删改查操作,比如用户在外卖软件上下一个订单,最终就会在数据库中生成一条订单记录。
软件部署时的数据库变更 (change on deploy)。有时软件版本升级后,也需要对于依赖的数据库 schema 或者数据进行变更。许多软件的做法是在新版本第一次运行前进行变更,不少语言的应用开发框架以及 ORM 也都内置了相关的能力,比如像 Ruby on Rails 提供的 Active Record Migrations (https://guides.rubyonrails.org/active_record_migrations.html), django 的 Migrations (https://docs.djangoproject.com/en/4.1/topics/migrations/)。
后台定时服务访问数据库 (cron)。比如说财务对账系统,定期进行自动对账操作,最终在数据库中生成对账记录。也比如说下游数仓从数据库同步数据。
一次性执行 (one-shot / on-demand)。比如牵扯复杂业务逻辑的数据清理/迁移/订正。这些操作会包装成单独的脚本或者是命令行程序 (CLI),仅在需要的时候被运行。
交互式的数据查询 (interactive query)。直接连上数据库,使用 SQL 语言进行数据查询。
数据订正 (ad-hoc data correction)。直接连上数据库,使用 SQL 语言进行数据订正。
数据库 schema 变更 (offline schema change)。用户有时也会直接连上数据库,进行 schema 变更。所谓的删库跑路,指的就是用户错误地执行了 DROP TABLE / Database 的 schema 变更操作,导致了严重的甚至是无法挽回的损失。
数据库运维管理 (admin operations)。DBA 连上数据库,进行管理员操作,比如终止执行时间过长的 SQL 语句。
解决思路
访问数据库尤其是线上生产数据库是高危操作。即使不是变更,一条不经意的 SELECT 语句也可能拖垮整个数据库,造成严重故障。所以说,但凡有条件,管控是必要的。
尽量减少甚至避免手工直接连上数据库的操作。是人就会犯错误,而且手工连接数据库也意味着需要把数据库的访问信息给到个人,大大增加了数据泄露的隐患。
应用程序访问数据库是无法避免的,否则程序就无法正常运行。但是对于数据库的 schema 变更是可以单独分离出来的,不需要在应用新版本部署后,第一次运行时进行变更。而且把 schema 变更和应用部署解藕可以更好地掌控整个变更流程,以及应对可能的回滚。
Bytebase 定义了两层权限模型,一个是在整个 workspace 级别的全局权限,一个是在 project 级别的具体业务开发项目权限。这两层的权限体系分别对应到中央的 DBA 团队和各个应用项目组的开发团队。
Bytebase 提供了可视化界面,来管理数据库 schema 以及数据的变更审核流程。同时还支持和 GitLab, GitHub 集成,提供 Database-as-Code 的 GitOps 流程。
Bytebase 提供了 SQL Editor,开发者可以进行查询 SELECT 操作。而对于 DBA 们来说,可以在 SQL Editor 中开启管理员模式,执行数据库管理命令。
用户可以配置 SQL Review 审核规则。如下图,在数据变更流程中,规则阻止了用户执行不带 WHERE 的 DELETE 语句。并且针对研发流程中的 dev, test, prod 等不同环境,用户还可以配置不同的规则。
还可以配置不同的审核策略,比如 dev 环境,可以跳过 DBA 审核;prod 环境,必须 DBA 审核或者也可以要求 project owner 审核。
总结
MotherDuck,从 SQLite 走向数据届的 Docker