如何打造属于自己的数据库运维平台-数据查询篇

导读：

作者：知数堂学员-邓志航

本文为《如何打造属于自己的数据库运维平台》系列文章第二篇，本文我们将介绍数据查询功能该如何设计

---

前沿简介

如何一步步构建自己的数据库平台

功能目的: 为了给研发人员提供平台化生产数据查询,我们分析下这个功能,有两个重点

1. 统一平台化 其实在大多数环境下,研发人员是应该不被允许直连数据库进行查询,需要通过一个具有查询日志的统一平台进行查询以及其他功能

2. 生产数据库 我们不建议测试和预发环境接入平台化,因为这可能拖慢整个测试进度,对于非生产环境,还是让他们自己接入吧

一、功能: 查询数据

我们需要考虑以下几个问题:

1、后端数据返回到前端的数据如果过大,就会对前端渲染出现很大压力,这点是第一要考虑的,所以我们拿出来第一来说,我们需要对查询语句本身做几个限制

• 普通的sql查询,这种类型的查询占查询的需要的绝大部分,类似select * from limit n

• 我们加了以下限制: sql语句本身必须以limit n结尾,否则不予通过.通过研发主动添加limit而不是后端进行自动补全,防止造成查询结果错误的判断

2、聚合函数查询的判断, 类似select count()/sum()

3、聚合函数因为只返回总数,所以无需限制,给予放行

• explan 查看sql语句计划树

• explain对前端无影响,所以给予放行

二、功能: 索引查看

• 通过何种方式查看索引并返回结果

• 通过show index from的模式 查看 表的索引

三、功能: csv导出

这里需要考虑两个问题:

1. 是否需要流式方法传递到前端

2. 导出何种文件 我的解决方法

• 设计中间下载服务器,比如nginx提供数据文件下载功能,前端生成nginx下载url链接

• drf设计python方法,由drf调用后端执行sql任务写入csv文件

相关解析：

1. 无需给前端任何压力,直接从nginx下载文件即可

2. sql本身输入也无需任何检测规则

3. 建议后端从库都部署pt-killer针对此数据库平台的查询,防止大查询导致的从库延时问题

四、功能: 主从延时判断

分析功能：

其实这个功能很简单，但是很多平台没有加,我结合我的环境建议加上，原因：

• 我们的环境是当执行完sql工单时,研发要立刻执行查看是否数据已更改或者DDL操作是否成功进行验证,这时候如果从库有延时,就会造成误判,如果执行这个功能,就能进一步确定原因,我强烈建议加入此功能

五、功能: 查询日志记录

分析功能:

用来记载平台操作的日志,这也是不可或缺的一部分

功能补充

1. 对于数据库平台的查询工单,查询并不需要提工单,我认为会严重拖慢进度.有查询日志记录已足够

2. 对于数据库平台的脱敏操作, 我也没有考虑,因为我们环境并不需要,以后可能会考虑添加(PS:本人认为脱敏对研发来说真的意义不大,所以没有第一时间考虑)

3. 对于数据库平台的用户权限, 大概包括(select,replication client, Show view)

4. 对于数据库平台的查询权限, 我会在后续进行讲解是如何规避的

5. 对于数据库平台的日志记录, 我觉得是非常必要的,有这个日志记录对于审计工作是非常必须要的

六、功能界面设计

总结

1. 这是查询功能相关文章,希望为大家起到一个抛砖引玉的作用

2. 本功能设计的不是很完善,如果较真起来,可能会有很多问题,我这一块功能,也是不断的调研,反复的修改,大家见谅

3. 最后再补充一句,功能模块的设计远比开发代码更重要,一旦你拥有了完整优秀的功能模块设计,那么即便你不会代码,你可以交付其他同事进行书写

推荐阅读：

END

---

扫码加入QQ技术交流群

（群号：801428435）