点击蓝色“有关SQL”关注我哟
加个“星标”,天天与10000人一起快乐成长
“埋点”,在前端技术中常用的技术,其实可以变为思维,应用到 SQL 的开发中。
之前做了很多业务系统的开发,架构涵盖 C/S,B/S, C/C/S, 两层,三层,n 层。在这些管理类软件中,最头通的不是界面写的丑,也不是写不出可用的程序,而是出了问题,不知道去哪一层找原因。
在耦合度还没拆分那么细的那个年代,用户追求的根本不是代码的整洁,也不在乎你的代码其他程序员能不能读懂,他们要的很简单,数据一致,数据安全。你的程序要丢了他们的数据,嘿嘿,加班吧。
所以,那个年代最普遍的做法,try…catch… 捕捉到的错误,经常调一个email接口,及时发送给开发者。
久而久之,大家都知道,其实我们做程序,就是在救火而已。
那怎么办呢,天天救火,怎么深入研究自己感兴趣的事情呢?于是有人大胆想出来一个主意,让所有的错误,异常信息,都直接保存到数据库里面去。这就是业务系统最初的 log.
根据这份 log, 我们开始了大量的分析,有段时间,最热衷的事情,就是看 log 跑出来的报表,特别有意思。比如:
1) 今天谁谁谁登录了软件系统,用了什么密码(好像说漏嘴了),看了哪些报表,发表了哪些有意思的帖子;
2) 今天有多少用户使用了我们开发的软件,平均使用时间多少,在哪个地区或办公区登录的人最多;
3) 今天爆了一个不寻常的bug,它的用户行为路径是什么样的,当时数据库服务器的统计快照拉出来分析;
等等。
这些在今天我们依然在做,不过大部分的前端埋点都已经放到了 nosql 数据库中,不再去浪费正儿八经的业务系统核心数据库资源。
就拿淘宝来说,他们业务快速发展的那几年,采用了大量的小机。小机的成本比较高,除了小机的硬件,还要考虑数据库每年的维护费,持续记录这些不核心的数据,显然是不合算的。如果换成正常的 x86 服务器,那么成本会小很多,至少存储可以省掉 一大块。
因此有了 Nosql 的大量应用,比如 MongoDB, ElasticSearch 等等。
虽然埋点已经交给前端处理了,但少量的应用还是要依靠存储过程。对于存储过程成千上百行的sql, 简直就是一个黑盒。要想知道黑盒中发生了什么,埋点思维少不了。因此前端使用的埋点技术,就可以顺利借鉴到存储过程,甚至是平时的 ad-hoc sql 脚本。
如上图,就拿一个数据库的存储过程来说,入口是个简单的 try, 紧跟着埋点记录存储过程执行开始,等待执行完毕,记录下执行完毕的时间。一旦中间有错误,就在 catch 部分加上对异常信息的捕获。
这就是简单的一个存储过程埋点框架。这样做的好处,一来可以定位存储过程的执行时间,监控近期的执行性能是不是够好;二来可以定位是不是有异常发生,以及异常具体信息是什么;三,如果埋的够细,当然更有利于平时故障分析。
这是比较老式的做法,互联网朋友们不要学,你们应当把埋点前移,减少数据库的压力。传统行业的从业者,这一套基础还是要有意识,可以提高对故障的定位效率。
好了,留言说说你们平时,是怎么记录和定位数据库故障的吧?
--完--
往期精彩: