OSC 第 85 期高手问答精华汇总 —— 数据库架构选型和运维

原创
2015/09/07 18:37
阅读数 1.5K

OSCHINA 第 85 期高手问答(8月4日- 8月10日)我们请来了 @grassbell陈栋)为大家解答关于 数据库架构选型和运维 方面的问题。

原文地址:http://www.oschina.net/question/865233_245337 

陈栋@grassbell ,杭州沃趣网络科技有限公司 CEO,2004.12~2012.5 年就职于阿里巴巴。从应用数据库支持,到产品数据库运维,经历了 Oracle 从 PC Server+ 磁盘阵列 到 IBM 小型机+高端存储的升级,也经历了从集中式 Oracle 到分布式MySQL 的变迁。2009 年开始带领 DBA 团队,负责所有 DB 相关项目的开发、测试、上线、日常优化工作,及所有线上Oracle、MySQL、Greenplum 数据库的运维,并包括主机、存储的规划和日常管理。期间形成了一套成熟的数据库运维理念,能为各种场景提供合理的数据库架构,并对各种疑难紧急情况进行有效处理。 

2012.6 月离开阿里,组建沃趣科技,期望凭借在互联网行业积累的多年的运维经验,为传统行业客户提供最专业的数据库产品及服务。

在 去“IOE”的大背景下,Oracle、MySQL、PgSQL、x86、flash、自动化运维.....我们该如何选择应对?各种数据库又应该选用怎 样的架构呢?从数据库运维的角度,都载过哪些跟头该如何避免呢?我们说没有最好的技术,只有最适合的技术。大家都结合自己实际的业务场景,来聊聊这些话题吧。

精彩问答

@茶壶:你好,在系统中,数据查询性能低下时(表里的记录件数很大),除了按照画面的检索条件建立索引外,还有什么好方法。

@grassbell:这个问题犹如在问一条SQL该如何优化一样。之前运维过一套CRM系统,很多大表关 联,除了基本的index和表关联调整优化外,更多是从应用需求入手,是否可以默认增加一些条件限制,是否可以build结果表,是否可以通过搜索引 擎......另外SSD和Flash硬件技术的引入,可以让IO性能提升一个数量级,也是一种方式。

@茶壶:对于24小时服务在线的系统来说,数据库怎样搞比较好(表结构可能发生表更)?是个移动项目,业务总在更新,表结构就经常有变化。java服务是二十四小时在线的,也就是服务不能挺的情况下,表结构要修改。

@grassbell:数据库在线修改表结构,只要是向后兼容的都没什么问题,不要有删除字段之类的操作就好。现在的应用框架都支持的

@hzh62:分布式 mysql ,是支持 分布式事务XA 形式的吗,还是采取分库分表后,不支持跨表事务的模型。

@grassbell:阿里巴巴主要有两个分库分表的中间件:cobar和TDDL。目前绝大部分的分库分表中间件都是不支持跨表事务的。在生产环境下,要做这个的代价比较大。阿里的这两个在分库分表的情况下都没有做分布式事务。

@永远在一起:我想请问,目前我的了解,现在数据库大概有两种运用方式,一种是把数据库当作数据的桶,仅仅是负责放入数据,需要时取出数据。另外一种情况,是把数据库 当作数据库系统,将尽可能多的运算放入数据库中。目前只接触过第一种方式,但是有书认为,第二种方式的效率更高,对数据库的使用更加充分。不知道陈总对此 怎么看?是否对这两种方式有所偏重。

@grassbell:这是个两难的问题,系统初期,为了快速满足业务需求,数据库可以承担部分业务运算,随 着业务量的增加,数据库集中资源瓶颈的问题开始凸显,这个时候需要将数据库用的简单,尽可能将业务计算剥离出去。如果你将数据库用的太重,这个剥离的过程 将很痛苦。我建议项目初期还是要对业务主线有个简单预估,应用开发与数据库找到个平衡点,这是一个权衡的过程。

@永远在一起:那看来陈总是比较倾向于将数据库作为数据桶的方式使用。那数据库设计的过程中,一般人 都知道有范式的概念,我所在的公司对此并不上心,陈总对此又如何看待,是否要求数据库设计时必须达到某一范式(如果确实有此要求,能透漏一下是那一层次的 范式么?)?又或者陈总认为数据库设计中范式并不十分在实际项目中使用呢?

@grassbell:数据库范式确实有助于应用梳理业务逻辑,整理数据流。但是绝对的范式在数据库系统中并不是最佳选择。有时候,做一些字段的冗余反而会使数据库响应更直观,快速。关键还在于怎么让业务有效,快速的提供服务。

@GKTest:我想请教,以订单数据库结构为例,单台服务器(假设是2CPU、64G内存),对于Oracle、MySql、PgSql,单表数据记录达到多少会出现明显 的性能瓶颈(假设是已经最优化的),因为我没做过大数据高并发,希望知道这个临界点,能更好的根据实际情况用不同的方案。

@grassbell:目前这几种数据库,单表数据量在1亿条以下时都不会出现明显的性能变差的情况。所以通 常做分区表或拆表的原因并不是因为单表不能支撑这么大的数据,而是当单表的数据量太大,比较难维护。如你做一个表结构变更,如果单表太大,会做很久的时 间。如你想删除一部分历史数据,如果所有的数据都是在一个单表中,操作会比较慢,但如果你是按时间分区的,只要删除分区表就可以了。所以通常单表的数据量 都保持在几千万条以下。

@施家奇:前段时间,公司的领导说要搞个高可用的MySQL集群,当时有人提出用MySQL Cluster。我极力反对。反对原因是在我印象中,NDB不支持事务(貌似现在支持),占用内存高,运维经验少。请问陈总,MySQL Cluster靠谱吗?国内有公司在用吗?所谓的分布式MySQL,到底是个怎样的东西?

@grassbell:目前主流的分布式MySQL,说简单一点就是把多个MySQL资源集中起来提供给一个 应用使用,方便数据库压力大了以后,数据库可以水平扩展。举个例子:淘宝上的商品有百亿级别,如果都放在一个MySQL数据库里面,压力很大,不可能支 撑。这样的话,我们想了一个办法,按照卖家来拆分:七格格放在A库,GAP放在B库,格力放在C库,用多个MySQL来承载商品这个应用的访问压力。这个 就是水平拆分的分布式。

实际应用的分布式MySQL,不是通过MySQL本身实现分布式,而是通过应用实现数据分布。

@DeanHere:你好,咨询小型MySQL集群解决方案

@grassbell:这个要看您具体业务的压力和需求了。 初创企业可以直接用一个单机的MySQL承载业务。 如果您担心MySQL数据库挂了以后,应用无法提供服务,您需要搭建一个Slave,或者做成双master的MySQL架构,以便一个MySQL出现了故障,另外一台MySQL能够及时提供服务。 如果您只是读的压力比较大,可以多加几个Slave,组成一主多从的架构,将读的压力分离到多个读库上,主提供写的服务。

@hylent:你好,请问你对mongodb怎么看?

@grassbell:mongodb目前在游戏产业用的比较广泛。如果你的业务数据都能抽象成json的格式,那么mongodb是一个好的选择。但目前mongodb在一些数据高可靠(零数据丢失)、高一致性的场景上还不太适用。

@lixin3811:你好,能否简单介绍一下“成熟的数据库运维理念”和其运用的场景,谢谢。

@grassbell:这样说吧,这十几年有些积累,但基本还是围绕关系型数据库。沃趣科技团队,无论是Oracle、MySQL还是PGSQL数据库,每个领域都有领先的技术人才。我们非常了解这些主流数据库的优缺点以及相应的应用场景,提供根据用户的需求提供最合适的定制化架构。

在Linux和x86硬件平台上,我们融入了Oracle、MySQL、PGSQL数 据库,同时引入Flash和Infiniband技术,能够彻底解决性能和扩展性等问题。我们可以满足用户对资源池的需求,实现资源隔离和有效利用,我们 还可以解决用户非常关心的容灾系统数据库零丢失的问题,甚至具备同城40~80公里的零丢失容灾方案。

未来,我们将推出基于OpenStack的数据库私有云方案,实现用户本地RDS的需 求。除了上述各种解决方案外,我们还可以为客户提供最贴心的数据库服务,例如数据库优化、巡检、二线支持等等。所以我们为客户提供的不仅仅是一款产品,而 是一整套全栈式的DB服务(FullStack DBaas),这也是我们的竞争力。

@nangzi:你好,对于oltp的数据库系统,数据量大概在多少的时候,单库单节点不在适用了呢?对于olap的数据库,同样也是数据量在多少的时候,会考虑集群呢?Mysql和Oracle。

@grassbell:Oracle的分库分表代价比较大,License的费用比较高。 MySQL分库分表这个主要跟数据量,并发和访问的方式比较有关系。一般的策略是能够接受的话,先不拆分。如果并发不高,或者访问都是最简单的主键查询类似的方式其实都不用分表。分表是需要牺牲跨表join和事务的。

@SimonYe:咨询MySQL 水平分拆分布集群下,事务处理问题。

@grassbell:水平拆分基本上就要牺牲跨库join和事务了

@西夏一品堂:请问单表数据量超过多少就要考虑分表了

@grassbell:这个主要跟数据量,并发和访问的方式比较有关系。如果并发不高,或者访问都是最简单的主键查询类似的方式其实都不用分表。分表对需要牺牲跨表join和事务,对应用的影响比较大。如果单就数据量来说,亿级别的数据是可以分表的。

@magicdoom:能否介绍下贵公司Qdata不丢数据的架构设计,以及是否会对性能有影响

@grassbell:在MySQL的零丢失解决方案中,我们利用Qlink做了一个分布式共享存储的东西。 当主库发生了异常以后,备库可以拿到主库的数据,并补偿到备库上来,之后才对外提供服务。 由于主库上的数据需要同步到备库上来,为了能够及时有效的同步,存储设备,网络设备,网络协议,块设备同步都需要优化和调整,配合起来才能保证对主库的性能没有影响。 由于字数限制,不能说的太详细,如果您有兴趣,可以直接联系我们了解测试一下。

@magicdoom:看起来好像跟oracle rac的架构有点像

@grassbell:简单的说是通过共享redo的方式,保证在备库存储也有一份主库的redo数据。 QData是基于x86架构的,网络互连通过infiniband,存储介质通过ssd或者flash,再配合运维自动化和监控,性能上相比传统IE架构 提升很多。同时我们实现了同城40~80公里的容灾方案的验证,通过对网卡、网络协议的优化,消除了除光速以外的延迟,尽可能保证IO性能的输出。

@邹海彬:cobar和tddl,性能大概会损失百分之多少?

@grassbell:这个相当于是7层协议解析,并转发,性能损耗正常的话,相比直连数据库,大约是25%左右。但是它带来的好处是,性能可以水平扩展,可以把很多个MySQL的性能共同发挥出来。解决了单机无法解决的问题。

@qii:你好,原来公司的事务,都是由程序处理的,这样做的话,事务由程序控制,易于维护和管理,对数据库的运维压力就减少了,如果使用数据库提供的事务,又有哪些优势呢?

@grassbell:数据库来做事务其实就是把应用上的这些事务性操作做掉,能够减轻应用压力,让应用专注于满足业务需求,提升用户体验。如果您没有用分库分表的水平拆分方案,大可以把事务交给数据库来做。它保证的ACID,能够帮助业务原子,高效的处理掉您的事务。

@kobe_gino:mysql分库分表中间件使用哪个好?cobar还是变形虫?

@grassbell:现在的分库分表中间件非常多。功能各有差异,如果是cobar和变形虫而言,建议用cobar,这个在阿里巴巴是经过生产环境验证的,相对稳定一些。但是使用这些中间件,还是建议您深入了解一下它的优缺点和适用场景,才能真正用好它,避免故障

@yagerya:有哪些比较稳定的MySQL高可用方案?

@grassbell:一主多从MySQL可以考虑用MHA。 双Master可以考虑heartbeat,keepalive这种。

@没有女朋友new一个:请教下,msyql中间件哪个比较好,cobar目前不支持主从,TDDL又是半开源,其他各种各样的中间件或多或少有点问题,谢谢了

@grassbell:如果您是主从结构,您可以考虑一下MHA。

@南海船老大:看到有人建议MySQL不要使用分区,你觉得呢?

@grassbell:MySQL分区有一个比较严重的问题:如果你跨分区访问,MySQL给你生成的执行计划会扫描所有的分区。性能损耗比较大。如果你能够保证访问的数据都在一个分区,不会有跨分区的现象,还是可以考虑使用分区表的。

@Booklearn:java怎么实现自动化运维??

@grassbell:这个要看您做哪方面的自动化运维了。 如果您做的是类似于MySQL中间层,数据库同步,监控等工具,可以直接用JAVA实现。 如果您做到是系统资源管理,命令行工具类型的工具,可能python等脚本性的语言比较好

@小B:问下,我了解的分布式mysql,查询都是根据切分键来的,做的比较好的做了反向索引,我想问的是,你了解的分布式mysql,采用的是重客户端模式呢?还是服务器模式,分别是出于什么考虑?

@grassbell:这个其实就是阿里Cobar和TDDL的区别。 cobar是服务端的,应用把Cobar当成一个MySQL来用。TDDL是客户端的,各个应用程序端都有一个TDDL的连接管理程序。 cobar的好处是对应用端简单,直观,坏处是经过了一轮网络转发,定位问题多了一个环节。TDDL的好处是直接连接数据库,坏处是各种语言(java,php)都需要有自己的客户端 

@小B:常用业务的mysql分支的选择?比如今日账务类项目,抢购类,电商类,流水类…

@grassbell:mysql的分支主要有三种:社区版,mariadb,percona。 mariadb主要是功能的修改和优化,比如subquery,新的maria存储引擎等;percona主要是运维方面的增强,更多的是 MySQL,innodb等的内部状态暴露出来,以便诊断和分析问题;社区版加入Oracle以后改动也比较大,而且5.7越来越像Oracle了。您根 据您的需要选择把。

另外,根据您的描述,可能您更需要关注的是底层存储引擎的选择,特别是一些OLAP类型的应用,需要选择一些特殊的存储引擎。

原文地址:http://www.oschina.net/question/865233_245337 

展开阅读全文
打赏
0
3 收藏
分享
加载中
更多评论
打赏
0 评论
3 收藏
0
分享
返回顶部
顶部