Bytebase的SQL审核体验(基于MySQL库)
一、关于我
我是DBA,想看看 SQL审核 的完成度,衡量 Bytebase 对日常SQL工单提审能够提供的帮助有多大。
二、什么是Bytebase
按官网上的描述,Bytebase是一款为DevOps团队准备的数据库CI/CD工具,专为开发者和DBA打造。唯一被CNCF Landscape收录的Database CI/CD产品。
其核心理念就是,像管理代码一样管理SQL。而对于SQL脚本的管理,其中最重要的部分就是SQL审核。
目前市面上主流的SQL审核产品,主要有Archery、Yearning、Bytebase,三者都是用于 SQL 审核的开源平台,这里是它们之间 SQL 审核方面的比较:
- Bytebase
- 支持针对 SQL 代码的审查,同时也支持提交的数据变更的审查;
- 以 pull request 作为审查流程触发器;
- 提供多种审查标准,包括大小写、变量名检查以及 SQL 注释存在等等;
- 集成了 JIRA、GitLab 等协作工具。
- Archery
- 内置的 SQL 管理系统支持 SQL 审核功能;
- 提供了审核日志和帮助文档等记录和备查功能;
- 支持数据某些特定字段和规则的审核,如手机号码、身份证号、密码等;
- 支持自定义审核规则。
- Yearning
- 提供了 SQL 查询优化的框架;
- 支持 SQL 查询分析、慢查询机制、查看 SQL 执行计划;
- 可以根据分析的结果对 SQL 进行优化;
- 支持审核过滤器,可过滤掉某些无用的 SQL。
总体来说,三者的差异在于它们的实现方式和功能重点。Bytebase 致力于代码审查和数据审查的结合,Archery 着重于 SQL 数据管理和自定义规则等审核方面,Yearning 则聚焦于 SQL 查询优化这一点。选择适合自己场景的工具,截获 SQL 问题,优化查询性能,提高操作效率。
本文主要体验Bytebase的SQL审核部分
三、Bytebase部署
1. docker部署
简化起见,这里使用docker-compose方式部署
curl -fsS https://raw.githubusercontent.com/bytebase/bytebase/main/quickstart/getting-started.docker-compose.yml | BB_VERSION=1.16.0 docker-compose -f - up -d
部署完后,启动docker,完成后的情况如下:
root@mytest-1226:~# docker ps
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
78e8a0a8f05d bytebase/bytebase:1.16.0 "bytebase --data /va…" 7 minutes ago Up 7 minutes (health: starting) 0.0.0.0:5678->5678/tcp, :::5678->5678/tcp bytebase
811f037ffc01 bytebase/sample-database:mysql-employee-small "/entrypoint.sh mysq…" 7 minutes ago Up 7 minutes (healthy) 33060-33061/tcp, 0.0.0.0:3307->3306/tcp, :::3307->3306/tcp root-employee-test-1
53e262c73f7b bytebase/sample-database:mysql-employee-small "/entrypoint.sh mysq…" 7 minutes ago Up 7 minutes (healthy) 0.0.0.0:3306->3306/tcp, :::3306->3306/tcp, 33060-33061/tcp root-employee-prod-1
部署完成后,登录Bytebase,配置管理员账号,管理的数据库实例,这些部分参考官方文档 一步一步操作。
2. 配置SQL审核策略
Bytebase默认两个环境: Test, Prod ,可以针对两个环境分别配置SQL审核策略。
实际上在现实环境中,为了提前发现SQL问题,避免把问题带到线上,会要求测试环境和线上环境的配置保持一致,故这里调整SQL审核策略
- 创建基于基础模版的SQL审核策略
先配置Test环境的SQL审核策略
使用模版包括的默认规则,直接点击确认并添加
Prod环境按同样的方法配置,完成后的效果如下
3. 创建项目,并添加数据库导项目中
- 创建项目
- 添加项目包含的数据库
点击转移数据库,将docker-compose中默认包含的两个环境的employee库添加到项目中
四、SQL编辑器查询的SQL审核体验
点击左侧SQL编辑器,进入SQL Editor界面,选择Test 环境下的Employee库。在出现编辑创建,敲入select查询语句,可以看着编辑窗口提供了常见IDE的提示功能
下面进行几个常见的查询:
-
无限制条件查询
-
笛卡尔积查询
-
使用like查询
可以看出以上几个Select查询,
- 对Select语句中未给出Where子句,进行条件限制的,给出了告警
- 对Select语句中使用
select *
,未显示指明查询列,给出了告警 - 对Select语句中where子句,使用
like '%xxx'
左模糊匹配的,给出了告警 - 对Select语句中两表关联,漏写关联条件,造成笛卡尔积的,未给出告警或报错
五、变更Schema的SQL审核体验
1. 建表
- 点击变更Schema,填写ddl语句
可以看到ddl语句提交后,自动进行检查,SQL审核按钮前出现惊叹号,点击查看
按检查审核项目要求,修改调整ddl语句
此时SQL审核中显示的告警错误如下:
第三项索引,属于错误,需要解决。查看规则详情
可以看到,这里定义的主键列类型有误。我这里是MySQL数据库,虽然语法上支持SERIAL/BIGSERIAL,但是不太符合日常使用习惯,这里做下调整。
在SQL审核策略部分,找到需要调整的审核项,点击编辑
添加MySQL中常用的主键类型:INT, BIGINT,点击确认
然后点击最下方的确认更新,更新策略
回到刚才的工单,手动执行运行检查
只剩两个告警项,这里测试就暂时忽略,实际使用时最好根据提示要求修改。
点击发布按钮,填写说明信息后,点击确定。
可以看到,工单在执行阶段,有出现错误。这是因为我这里对自增id定义了错误的默认值,继续调整。
重新发布后,可以看到ddl语句正确通过审核。由于我是使用admin账号提交的SQL,属于所有者用户,不用走审批流程,直接执行了。
执行完成后,可以通过界面直接看到:Test-employee-t1
2. 修改表结构
测试表添加字段,修改现有字段类型
查看SQL审核结果
居然禁止修改列类型,这个不符合实际业务需求,需要调整规则,改成警告级别
对上面的ddl语句进行调整,满足SQL审核的大部分要求
上述两个警告性信息,可以接收,提交工单
六、系统自带SQL审核模版
Bytebase SQL审核中自带了三个模版,包括样例模版,基本模版 和 进阶模版,样例模版过于简单,只能做个人实验环境使用,不能用于业务环境,这里主要看后面两个模版。
1. 基本模版
基本模版中一共包括49条规则,其中15条规则是错误级别的。对这几条规则,我们逐一考察一下:
范围 | 规则描述 | 是否 满足需求 | 是否支持等级定制 | 是否支持检测内容定制 |
---|---|---|---|---|
数据库 | 禁止删除非空数据库 | 是 | 是 | 否 |
列 | 禁止修改列类型 | 否 | 是 | 否 |
列 | 强制 “NOT NULL” 列设置默认值 | 是 | 是 | 否 |
列 | 禁止使用 “CHANGE COLUMN” 语句 | 是 | 是 | 否 |
列 | 禁止修改表中的列顺序 | 是 | 是 | 否 |
列 | 强制自增列使用整数类型 | 是 | 是 | 否 |
列 | 禁止在列属性中定义字符集 | 是 | 是 | 否 |
列 | 强制自增列使用 “UNSIGNED” 类型 | 是 | 是 | 否 |
表 | 强制表包含主键 | 是 | 是 | 否 |
表 | 限制待删除表的命名格式 | 是 | 是 | 是 |
表 | 禁止使用分区表 | 否 | 是 | 否 |
索引 | 禁止索引包含重复列 | 是 | 是 | 否 |
索引 | 禁止对 “BLOB” 与 “TEXT” 类型列创建索引 | 是 | 是 | 否 |
索引 | 允许主键使用的类型列表 | 否 | 是 | 是 |
引擎 | 强制使用 InnoDB 存储引擎 | 是 | 是 | 否 |
存在部分错误级别的规则,不是很符合业务需求,不过由于支持对其级别进行调整的,所以基本上还是能够满足日常业务DDL变更操作
2. 进阶模版
进阶模版中一共包括49条规则,其中31条规则是错误级别的。
对比基础模版可以发现,两个模版的规则条数一致,只是要求严格了些,将其部分警告级别的规则,调整为错误级别。
范围 | 规则描述 | 是否满足需求 | 是否支持等级定制 | 是否支持检测内容定制 |
---|---|---|---|---|
数据库 | 禁止删除非空数据库 | 是 | 是 | 否 |
系统 | 允许使用的字符集(Charset)列表 | 是 | 是 | 是 |
系统 | 允许使用的字符序(Collation)列表 | 是 | 是 | 是 |
列 | 禁止使用的列类型列表 | 是 | 是 | 是 |
列 | 禁止修改列类型 | 否 | 是 | 否 |
列 | 强制 “NOT NULL” 列设置默认值 | 是 | 是 | 否 |
列 | 禁止使用 “CHANGE COLUMN” 语句 | 是 | 是 | 否 |
列 | 禁止修改表中的列顺序 | 是 | 是 | 否 |
列 | 强制自增列使用整数类型 | 是 | 是 | 否 |
列 | 禁止在列属性中定义字符集 | 是 | 是 | 否 |
列 | 强制自增列使用 “UNSIGNED” 类型 | 是 | 是 | 否 |
列 | 强制列增加注释并限制长度 | 是 | 是 | 是 |
表 | 强制表包含主键 | 是 | 是 | 否 |
表 | 禁止使用外键约束 | 是 | 是 | 否 |
表 | 限制待删除表的命名格式 | 是 | 是 | 是 |
表 | 禁止使用分区表 | 否 | 是 | 否 |
表 | 注释检查 | 是 | 是 | 是 |
语句 | 禁止使用 “SELECT *” | 是 | 是 | 否 |
语句 | 强制语句带有 “WHERE” 条件 | 是 | 是 | 否 |
语句 | 禁止过滤条件使用左模糊匹配 | 是 | 是 | 否 |
语句 | 禁止显式 “COMMIT” | 是 | 是 | 否 |
语句 | 禁止在 DML 语句中使用 “LIMIT” | 是 | 是 | 否 |
语句 | 禁止在 “UPDATE”,“DELETE” 语句中使用 “ORDER BY” | 是 | 是 | 否 |
语句 | 禁止对同一张表发起多次独立变更 | 是 | 是 | 否 |
语句 | 强制 “INSERT” 语句显示指定列名 | 是 | 是 | 否 |
语句 | 禁止在 “INSERT” 语句中使用 “ORDER BY RAND()” | 是 | 是 | 否 |
索引 | 禁止索引包含重复列 | 是 | 是 | 否 |
索引 | 禁止对 “BLOB” 与 “TEXT” 类型列创建索引 | 是 | 是 | 否 |
索引 | 主键类型限制 | 是 | 是 | 否 |
索引 | 允许主键使用的类型列表 | 否 | 是 | 是 |
引擎 | 强制使用 InnoDB 存储引擎 | 是 | 是 | 是 |
基本上能够满足业务开发过程中的对SQL语句审核规则要求
七、总结
Bytebase的SQL审核模版中自带的审核规则,针对日常SQL查询、DDL变更中遇到的常见问题进行了梳理,整理出了基础模版和进阶模版,基本上能够满足了日常对SQL审核的需求
- 基础模版,进阶模版包含的审核规则条数一样,只是进阶模版的要求更加严格些,在基础模版中警告级别的规则,在进阶模版中成了错误级别
- 对于现有的,但不符合自身业务需求的审核规则,支持在界面可视化环境下进行调整,比如调整规则的级别(错误、警告),部分规则还支持定制检测的内容,这大大方面了管理员对审核规则的定制。
- 无法自行添加检测规则,满足自身业务需求。比如表连接缺少连接条件,形成笛卡尔积的情况。
- SQL查询语句,对缺少where条件的SQL,虽然有警告级别的检测,但是还是能够执行查询,对于大表能够参考archery的方式,自动加上limit子句,效果更好些
Database CI/CD | Database DevOps | Schema Migration | Bytebase
数据库变更的场景:flyway,bytebase