爱站程序员基地行业解决方案、产品招募中！想赚钱就来传！>>>
都说各行如隔山, 此篇仅献给不要脸的自己,写这个纯属灵感,题目亦是.
DB 本身并非大众思维里面的管管数据库,敲敲数据库命令,看看慢查询, 改改SQL, 审核SQL , 那么简单.其实上都属于 DB的初级级别,DB 的追求的终极水平就是一个系统级别的半仙.
当然当一个半仙也不是那么简单的,99-81渡难到时没有, 但背锅那必然是常有的事情. 成为半仙也是要从背锅开始,例如可能因为莫名的硬件问题, 你的数据库就不稳定了,此时你就的化身为除了DB 层次以外的, 系统级别的专业或非专业认识,将自己从泥潭里面\”择\”清楚, 所谓莲花出污泥而不染.
或者系统本身设计的漏洞百出, 你也要变换角色,从架构的某些层次来看反应在你数据库的问题, 这当然不是简简单单会看个慢SQL能解决的问题, 因为那样太LOW了.
从某个系统设计之初,其实作为DB 就已经大概了解这个系统设计人员的层次和知识水平了. 例如将一堆应用系统,架设在一台 ORACLE 的架构师和应用开发,你就知道他的水平如何了,因为这样的系统,要不就是没数据, 没并发,随便搞搞,糊弄领导, 要比就是在作死,在程序设计初期根本不考虑并发,扩展,只能说明这个设计人员,道航尚浅.
在往深层次去,就是看系统中的表设计和业务的逻辑结构之间的问题, 例如一个系统表完全要根据三范式来设计, 那你就要预想到,很可能因为业务复杂,你的一个查询就会变成 N 个表的 LEFT JOIN , 系统的性能如何.
一个系统设计,尤其复杂系统的设计,在数据库中的体现,表如何分冷热, 某些字段是否要冗余,有些数据存储是否要分库分表, 数据存储的格式,是传统还是JSON.数据库要不要解耦,程序在使用多种数据库时是不是要解耦, 等等. 系统设计初期,到底那个数据库适合这个系统,这个系统到底可能会涉及几种数据库, 那种高可用方式可以被接受,设计的能耗比在哪里,界限在哪里.
此时,DB 要不是一个半仙, 那就只能听命于人, 然后我们就继续背锅.
可能修炼成半仙的路途,一口口大黑锅,就是你修炼的过程,一次次的涨见识,一次次的升级打怪, 认识到一个个曾经踏平的坑,就是成仙的筋斗云.
在认知了这一切后,就可以开始反客为主了,熟悉多种的数据库,以及其功能特性, 哪些数据库适合出现在那个场合, 哪个功能可以解决那个问题, 哪个数据库的弱势在哪里, 为某些数据库扬长避短,在系统成型前就介入到系统的设计当中,而不是为了用数据库而用数据库,最终不是拿着一把剑,从头杀到尾, 就是成仙的领一个境界了.
举例,当你某一耳朵,听到VARCHAR(xxxx) 的设计时,并且还是在一个OLTP系统中频繁调用, 第一个反应是什么及后续的顺序是什么
1 这个设计的需求是什么
2 他为什么要这样设计
3 这个设计在系统中承接了什么,要不要查询,要不要UPDATE
4 是冷数据还是HOT 数据
5 哪种数据库我就可以忍了, 哪种打死都不行
6哪个系统能容忍,哪个系统不能容忍,目前系统的底线是什么
7有没有化解的方法, 例如在本数据库就地解决, 还是利用其他数据库联合解决, 或者,直接上到业务逻辑,看看合理不合理,如果能从需求上就灭绝他,那就再好不过了.
所以何时能将自己练就出火眼金睛,一眼识别出XX的行为, 并且能在利用数据库原理,特殊功能,技巧,规范,加上口吐莲花的辅助功能,等等将一个个 \”牛鬼蛇神\” 挡在门外的时候,可能就开始要成仙了.
本文分享自微信公众号 – AustinDatabases（AustinDatabases）。
如有侵权，请联系 support@oschina.cn 删除。
本文参与“OSC源创计划”，欢迎正在阅读的你也加入，一起分享。
