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

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