UDN-企业互联网技术人气社区

板块导航

浏览  : 663
回复  : 2

[讨论交流] 新浪微博MySQL管理规范小结

[复制链接]
舞操的头像 楼主
发表于 2016-6-12 20:59:23 | 显示全部楼层 |阅读模式
  主题简介

  在数据库管理中必不可缺但是又经常被忽略的东西,那就是数据库使用管理规范。Spark 各自的定位和用途。

  今天的话题主从要三个方面展开,1、数据库使用管理规范引入的时机。2、规范如何落地。3、执行的力度

  数据库使用管理规范引入的时机

  在和很多圈里的朋友沟通交流的时候发现,在集群规模较小或者公司初创的时候是没有专职DBA的,这时候的数据库集群大部分都是开发自行维护,或者是SA兼职维护,在这种情况下,基本谈不上什么规范可言。

  但是,在集群规模小的时候就可以随意来吗? 或者说功能就真的是第一位,为了满足线上功能点的开发,可以写出那种非常“牛B”的SQL吗?

  我个人的观点是不认同的,因为发生了太多“前人挖坑后人埋”的事情,而且填坑的人是非常痛苦的。

  举个例子,我们曾经有一段时间业务上线非常的频繁,有些时候新上的SQL添加一个index就可以有10倍的性能提高,于是在一些着急的情况下,我们会选择现在slave上添加index来解决读的问题,后期才会在master上增加对应的index。

  结果有一个业务,,,由于主从结构不一致最终导致数据不一致了。

  然后我以为做好在线系统优化就可以了,接着发现开发人员太可怕:如果不去开发阶段介入,我打不赢一场1对100人数悬殊的战争。你是一个人在抢救,开发一百人在挖坑,永远追不上。

  有数据库权限的朋友可以简单的试验一下:

  create table bbb (x int,y int,z int);

  insert into bbb values (1,1,1),(3,3,3),(2,2,2),(4,4,4),(5,6,5),(6,5,6);

  select y from bbb;

  这个时候结果如下:

a.webp.jpg


  如果添加一条索引:alter table bbb add index idx_y(y);

  在执行同样的SQL,select y from bbb;

  结果会变得不一样了:

b.webp.jpg


  眼尖的朋友已经看出来了,虽然执行的sql一致,但是结果集的顺序已经发生了变化

  在这种情况下,另外一些不符合规范的DML语句就会出现问题,比如update table limit 1;

  所以我个人认为,有一些规范越早建立越好,否则后期修正付出的成本将是百倍的。

  规范如何落地?

  首先,规范会带来一些好处:

  可控,再有规范的前提下,就不会出现一些稀奇古怪的SQL和使用方法。

  降低运维风险,没有那些稀奇古怪的事情,我们就可以针对在规范内的各种情况制定对应的应急元和优化方案,不会被打个措手不及。

  提高DBA的互通性,在一个规范体系下,支持A业务的DBA同样可以处理B业务的主库故障,因为除了存储的内容不一样外,其他都是一样的。

  其次,这些规范如何落地。

  个人认为,规范要和流程紧密,以新业务托管为例,新浪这边会有规范要求读写分离,账号权限仅有增删改查,库表的命名方式,部署结构上的最小单元,如果预估是个大型业务还要提前进行pre sharding。只有这些要求都符合规范了,需求方才会拿到这个DB的资源,在这个过程中DBA会和需求方紧密沟通。

  如果达不到我们的规范要求,我们DBA是有权拒绝这个业务的托管的。

  不过虽然看着很多,但是如果是一个已经熟知我们规范的开发人员,其实一个新托管也就是半天的事情就能搞定了,并么有想象中那么的复杂。

  说一下我们为什么要定这些规范。

  读写分离可以解决后期读压力横向扩展的问题;

  授权限制可以避免drop table之类的悲剧;

  库表命名有助于直观辨别表中的内容和归属业务;

  部署结构可以保障业务的高可用以及故障恢复;

  pre sharding可以保障后期整个集群的扩展性。

  如果没有这些提前的“规划”,后期遇到任何一个瓶颈点都需要花费10倍以上的精力去解决。

  以我们的实际惨痛经验为例,由于前期没有做好pre sharding的规划,后期遇到容量问题后,我们曾经花费了整个3个月对一个核心系统进行拆分,花费了大量的人力和成本,仅仅解决的是存不存的下的问题,价值产出极低。

  总结:规范要和流程绑在一起,要不有,要不没有。

  执行力度

  规范虽然带来很多的好处,但是也带来了很多的问题。

  比如说,不够灵活,有一些特殊需求和规范冲突。比如会和开发人员产生矛盾,对方设计好的东西被改来改去,这些问题怎么解决呢?

  个人认为,规范一旦设定,就不能妥协,不能因为一些特殊情况就退缩了。这样就要求我们在设计规范的时候考虑周全,想好了会发生什么,绝对不打自己的脸,一定要抗住。在这种情况下,部门经理就需要有一颗比较强大的内心和抗压能力。

  但是,并不是说面对需求我们就简单粗暴的拒绝,毕竟最终是为业务提供服务的,业务的问题还是要解决,这就需要一些变通。

  比如,之前我们曾经遇到过授权限制的问题,业务由于使用特殊的软件,一定需要create权限,但是我们的线上账号只给增删改查,这个问题如何解决呢?

  后来我们同业务沟通了一下,又专门给他们授权了一个有create的权限的账号,但是以admin开头并且只针对某几个特殊ip进行授权,这样即没有破坏线上账号的规范,也满足了业务方面的需求,虽然增加了一些风险,但是总体上还是可控的。

  至于和开发人员的设计讨论,我们一向坚持的是“数据说话”的原则,所有的改动都是基于测试数据上的提升来做的,在这些数字面前,开发人员还是很容易被说服的。

  最后,总结一下今天我分享的观点:

  数据库使用管理规范越早建立越好,前人栽树后人乘凉。

  规范要和流程绑定在一起,养成业务方的习惯。

  规范不可轻易妥协,有些可以变通,但有些就要坚持到底。

  最最后,广告一下,最近我们开源我们的异构数据复制组件MyBus。

  问答环节

  Q1:有时候开发,为了应付建表,不根据最新需求来创建DML,导致QA上建立的DML和线上库的DML不一致。导致的结果是部分所建索引不能使用,这个如何规范? 开发根据产品的需求变动的太快,DML变动太快,导致最新的DML和当初设计的时候已经差别很多,而这些DBA都是后续上线后才发觉的。

  A1:这个我们是有一套同步线上表结构的系统提供给QA使用,我们给QA和开发的建议是每次有修改之前,都和线上同步一次,然后在这个基础上去做开发和调整,这个页比较难,目前做的比较好的都上SQL审核了,强制开发使用统一入口,我们自己还没做到这步,主要靠慢查询系统去捕捉问题SQL,然后DBA进行后期优化。

  Q2:开发dba和开发人员人数比例几比几配备比较理想?

  A2:如果纯算比例的化我们这边基本是1:50了,但是我们做了一些要求,每个业务组制定一名数据库的接口人,开发组内的所有需求都汇总到这个接口人身上,然后在由接口人联系DBA,这样我们实际的比例大改控制在1:5左右,目前感觉还ok。

  Q3:请问一下,数据库管理的时候例如权限分配,你们是自己开发工具或者平台来搞的吗?

  A3:权限我们是自己开发了一套系统,用户申请后会按照我们的规范,分别给读账号和写账号,然后密码是根据算法随即生成的

  主要曾经都是一个密码,后来泄露了,然后把线上n多数据库都改了一遍,后来就改成随机生成了。

原文作者:肖鹏 来源:开发者头条

相关帖子

发表于 2016-6-12 23:25:27 | 显示全部楼层
支持楼主
使用道具 举报

回复

发表于 2016-6-22 17:52:18 | 显示全部楼层
顶           
使用道具 举报

回复

您需要登录后才可以回帖 登录 | 立即注册

本版积分规则

关于我们
联系我们
  • 电话:010-86393388
  • 邮件:udn@yonyou.com
  • 地址:北京市海淀区北清路68号
移动客户端下载
关注我们
  • 微信公众号:yonyouudn
  • 扫描右侧二维码关注我们
  • 专注企业互联网的技术社区
版权所有:用友网络科技股份有限公司82041 京ICP备05007539号-11 京公网网备安1101080209224 Powered by Discuz!
快速回复 返回列表 返回顶部