search 2013 adfgs

接前面一篇,这里再将之前在“中国系统架构师大会”5周年的时候发布的纪念册“IT架构实录”上的一篇文章发出来,也算是前面博文中PPT的一个文字版解读吧。

——————————————————————————————-

Oracle,MySQL 还是 NoSQL?

前言
随着阿里系的“去IOE”运动在社区的宣传声越来越大,国内正在掀起一股“去xxx”的技术潮。不仅仅是互联网企业,包括运营商以及金融机构都已经开始加入到这个潮流之中。作为运动中的这个“O”的Oracle数据库,自然就成为了众矢之的,众多CIO及CTO们都展示出一副欲除之而后快的表情。那在实际的应用场景中,我们到底该如何去选择数据的存取软件呢?

大概在09到10年左右,突然一夜之间满世界都在谈论 NoSQL,到处是关系型数据库要被 NoSQL 替代的声音,几乎所有人都在鼓吹NoSQL的各种好,但到目前为止也没有看到哪个数据库软件的市场受到了NoSQL的大冲击,当初红极一时的Cassandra也从老东家 Facebook的最初应用场景中退出舞台而改用了HBase。当初从关系型数据库 MySQL 转投 NoSQL 怀抱的 Twitter 经历了各种“痛”之后,又回到了MySQL的怀抱…

作为一个架构师,面对如此众多选择的时候,到底该依据什么来作出正确的决定呢?下面是笔者经验中常用的3步决策思路,希望对大家稍有启发。

一、 系统对比
 功能差异
Oracle无疑是功能最为全面一个,无论是用于OLTP场景还是OLAP场景,都有很好的技术手段支撑;MySQL作为开源数据库软件的代表,对于关系型数据库常用的功能也都全面覆盖到了,但作为 OLAP场景所不可或缺的 Hash Join这一特性确实给 MySQL 的 OLAP之路造成了较大阻碍;而各 NoSQL 产品大多都不能进行非 K/V 式的数据存取,能支持多维度条件过滤的产品选择较少。
所以从功能角度来比较: Oracle > MySQL > NoSQL

 性能强弱
根据过去的一些测试及实际应用场景的经验,基于同等硬件资源,可以从以下3个角度来对比性能:
 写入:由于 NoSQL 在数据存储及日志记录方面的架构及实现优化,相对 Oracle 及MySQL来说都有不小的优势。而 MySQL 和 Oracle 二者差异并不是特别大,暂且认为二者并列吧。
所以从写入性能角度来比较:NoSQL > Oracle = MySQL

 简单查询
关于简单查询性能的争议一直很大,有人测试出 Oracle 不如 MySQL 的结果,也有人测试出 MySQL 比 Oracle 差的结果。其实可能二者的测试都没有问题,真正的问题在于各自的测试场景的差异,尤其是并发数的差异可能会对测试结果造成非常大的影响。在高并量不断增加的时候(如到达128),MySQL就会逐渐显示出力不从心的状况了。至于 NoSQL,至少在笔者的测试场景下大部分时候都是比前面二者性能要差。当然肯定会有大量的 NoSQL 粉丝们会跳出来反对,但请记住我们要的不是一个 Cache 产品,也不是比较大规模集群下的能力。
所以从简单查询性能角度来比较:Oracle > MySQL > NoSQL

 复杂查询(至少含有 Join)
NoSQL 产品不支持 Join,所以无疑垫底,MySQL 的查询优化器由于所基于的统计信息相对少很多,当Query 复杂度很高的时候容易出现执行计划不是最优选择的问题,而 Oracle 由于大量的统计信息支持,使得其查询优化器更为智能,对复杂查询有更优的表现。
所以复杂查询的性能角度:Oracle > MySQL > NoSQL

 扩展能力
扩展能力或者说扩展方便程度,一直是影响架构师选型的一个重要因素,毕竟我们的数据产生速度越来越快,很多时候都难以通过单机来解决问题。
单纯从扩展便利性角度来看,大部分 NoSQL 产品都有较好的分布式支持方案,无疑是最佳选择,而 Oracle 由于其对数据一致性的严格要求,以及架构的一些限制,扩展便利程度较 MySQL 要稍微弱一些。
所以在扩展能力方面:NoSQL > MySQL > Oracle

 可维护性
这一点一直是运维人最为关注的因素,毕竟任何一个软件系统都是需要后期维护的。
NoSQL 产品由于发展时间相对较短,对于可维护性角度的支持相对要少很多,虽然大多提供了一些相应的小工具,但总体来说都还是过于简单了些,所以这方面和相对成熟的 MySQL 以及Oracle相比较要弱。而Oracle为后期维护所做的工作无疑是最为全面,无论是运行状态的跟踪,还是基础的备份恢复等,都很完善。
所以在可维护性角度方面:Oracle > MySQL > NoSQL

 商业支持
NoSQL 产品目前有商业支持的很少,MySQL 的本地化商业支持选择并不多,Oracle方面的商业支持无论是大型公司还是初创团队,选择性相对比较广泛
所以在商业支持方面:Oracle > MySQL > NoSQL

 软件成本
这方面没有太多争议:Oracle > MySQL = NoSQL

 人才环境
这是很多人会忽略的一个因素,但实际上可能会给后续的使用及维护带来非常大的影响。Oracle作为发展了多年的数据库领域的龙头,所以整个 Oracle DBA 行业相对比较成熟,人才体系也相对稳定。MySQL 数据库作为后起新秀,已经有不少人投入其怀抱,但总体来说无论从数量还是质量角度来看,都远不如 Oracle DBA 这一群体。NoSQL 方面的人才就更为匮乏了。
所以从人才环境角度:Oracle > MySQL > NoSQL
二、 场景分析
 一致性要求
虽然无论你什么时候去问任何一个业务方,都会告诉你他系统的数据是不能有任何一条丢失的,任何时候都需要实时反馈变化。但实际上是当你换一个提问方式,告诉他们如果在极端情况下(比如断电)也要确保数据不会有任何丢失,会增加几十上百万的成本,那这个时候得到的回答可能就会完全不一样了。所以我们在了解业务方对数据一致性要求的需求时候,一定要明确厉害关系,分清数据级别,并且做到最大化的信息透明,才能挖出最清晰的需求。对于数据一致性的保护,Oracle 无疑是做的最可靠的一个。
 并发规模
并发规模会考验我们的扩展能力,如果并发规模很大,那我们就需要很好的扩展能力以保证后续并发增长的需求。选用一个难以扩展的系统,会导致后续并发规模增长过程中无论是时间成本还是经济成本都很高。
 逻辑复杂度
很显然,如果业务逻辑过于复杂,至少 NoSQL 肯定不是合适的选择,至于 MySQL 还是 Oracle,那就是考验二者功能及性能的时候了。
 总容量规模
我们的系统数据容量规模自然也会影响到软件选型,规模非常大的,肯定要用分布式系统支持,至少也得分库分表吧,这时候的扩展能力就会充分显示出其优势。
三、 平衡决策
经过了第一步的“系统对比”,以及第二步的“场景分析”,我们已经为系统选型积累到相对充分的信息了,那是不是就可以比较明确的选择出合适的系统了呢?
这时候我们可能会发现我们的数量规模很大,但是又希望能够维护方便容易控制。这时候我们就面临如下问题:数据量规模大选NoSQL更合适,便于维护又是Oracle的优势,怎么办? 又或者如果我们有这样一个场景:某交易系统,并发量很大,对于数据一致性要求很高,业务逻辑也并不简单,怎么办?Oracle可以为我们提供很好的数据保护,面对复杂逻辑的时候也能有最好的性能,但在扩展的时候会面临成本压力。MySQL可以提供较好的扩展方案,而且成本相对会较低,NoSQL 无法解决复杂逻辑的业务场景。
类似问题可能会频繁出现在我们的架构师面前,需要大家根据各种利弊进行权衡,做好平衡决策,在尽可能满足业务需求的前提下,选择一个更合适的系统。有些时候可能也不得不作出牺牲极少数业务需求来换取系统更大的发展,而不要为了保全某些极端场景的需求而影响整个选型。

总结
数据存储软件的多样化趋势势不可当,不管是传统龙头的 Oracle,还是开源典范的 MySQL,以及 NoSQL 这一新秀,各有其特色,但同样也都有其短板。没有谁是万能的,同样也没有哪一种架构能应对所有问题。

作为一个架构师,我们的选型工作需要做到下面几点:
1. 在平时的工作中做好积累,以获得上面的第一步“系统对比”中的信息。
2. 在面对具体业务需求的时候,充分挖掘最真实的需求,并将各种利弊信息透明化
3. 在最终决策的时候做好平衡,从需求实现,成本控制以及维护管理多个角度权衡利弊
4. 对新技术学习的渴求不能影响选型结果,同样也不能对新技术的使用带有恐惧。

Oracle,MySQL 以及 NoSQL,都只是一个软件而已,实际使用效果更多的取决于使用者的能力。一个优秀的使用者能够充分利用其优势避开其软肋,最终获得最大化的价值。

最后,在选型的过程中既要充分吸收业内经验,又不能人云亦云。不要看到别人的“去O”运动声势浩大,就一棍子打死 Oracle,你只看到了别人希望你看到的内容。

作为阿里引入 MySQL 数据库的第一批践行者之一,我经历了从Oracle的“一统天下”到被 MySQL 从周边应用逐步“蚕食”,直至核心系统都被替换成 MySQL的多个阶段。最初这是一个令人振奋的过程,虽然也伴随着DBA团队的不安,但总体都非常顺利。但随着这个过程的不断推进,痛苦慢慢袭来,尤其是对开发团队的影响越来越大。再后来…(再后来的事情就不便细说了)

现在回过头来仔细思考,方向决策没有任何问题,但实际执行过程及执行策略还是存在不少可以商榷的地方。比如成本比较的核算方式,执行范围的一刀切等等。

正是因为有这些“前因”,所以在2013年 OTN嘉年华上做了下面这样一个颇具争议的分享,针对目前吵得比较火热的“去IOE”中的“O”所涉及到的数据库领域的产品选择问题聊了下自己的看法。

 

Oracle my sql-or-nosql from Sky Jian
分享之后很多人都说还少了最后的一个收尾,那就是:到底什么系统该用 Oracle?什么系统该用 MySQL?什么系统该用 NoSQL?
首先这个选择确实和业务场景有非常大的关系,其次有些背景让我不能把话说得太清楚了,最后就是还有想法我们可以线下随时沟通。

从 OOW2013@旧金山回来半个月了,简单记录一下这次会议中 Oracle 的几个大事。

  • In-Memory Option:
    可以设置某些表的数据在内存中以列的方式再存放一份,用来解决OLTP与OLAP混用的场景下性能互扰的问题。
    列式数据存储的需求趋势越来越明显,SAP的HANA已经做的风生水起,Oracle也来凑热闹了,呵呵。
    实际的效果暂时还不得而知,期待正式场景下的效果反馈。
  • M6:Big Memory Machine
    又一个大家伙,32TB 内存。虽然没有实际体验,但想想就觉得“可怕” :)
    Oracle正在软硬一体机的路线上坚定不移的向前迈进,M6的发布又是一次大跨步前进

    M6 样机现场演示中:

  • Database As Service
    Amazon 早在几年前就已经对外提供商业的在线关系型数据库服务了,国内的阿里云同样也提供了多种关系型数据库服务,现在这一阵营又将多出更为重量级的选手,Oracle正式宣布将进入这样一个市场,提供 Oracle 数据库在线服务。

最后,还有这次OOW期间的另外一件大事就是美洲杯(America CUP)帆船赛, Oracle 代表的美国队来了次大逆转,在 1:8 落后的前提下居然连扳回8场最终9:8获胜,不知道是奇迹还是之前故意放水,哈哈。下面是借用eygle的一张图片,美洲杯颁奖礼上 Larry 手举奖杯额度镜头:

上周在北京参加了 OTN China Tour 2012(Oracle技术嘉年华)的活动,在会上有个简单的分享,主要是当 CPU 成为瓶颈的时候,我们改如何来优化数据库,分享的文档如下:

MySQL Tuning For CPU Bottleneck from Sky Jian

接着上一篇 MySQL 数据库性能优化之SQL优化,这是 MySQL数据库性能优化专题 系列的第五篇文章:MySQL数据库性能优化之存储引擎选择

离上一篇文章已经有很长时间没有更新这个MySQL数据库性能优化专题了,时间太紧加上人之惰性,今天这里将之前就规划好的关于存储引擎选择方面的内容更新出来,希望对大家有所帮助吧

MySQL 的存储引擎可能是所有关系型数据库产品中最具有特色的了,不仅可以同时使用多种存储引擎,而且每种存储引擎和MySQL之间使用插件方式这种非常松的耦合关系。

由于各存储引擎功能特性差异较大,这篇文章主要是介绍如何来选择合适的存储引擎来应对不同的业务场景。

  • MyISAM
    • 特性
      1. 不支持事务:MyISAM存储引擎不支持事务,所以对事务有要求的业务场景不能使用
      2. 表级锁定:其锁定机制是表级索引,这虽然可以让锁定的实现成本很小但是也同时大大降低了其并发性能
      3. 读写互相阻塞:不仅会在写入的时候阻塞读取,MyISAM还会在读取的时候阻塞写入,但读本身并不会阻塞另外的读
      4. 只会缓存索引:MyISAM可以通过key_buffer缓存以大大提高访问性能减少磁盘IO,但是这个缓存区只会缓存索引,而不会缓存数据
    • 适用场景
      1. 不需要事务支持(不支持)
      2. 并发相对较低(锁定机制问题)
      3. 数据修改相对较少(阻塞问题)
      4. 以读为主
      5. 数据一致性要求不是非常高
    • 最佳实践
      1. 尽量索引(缓存机制)
      2. 调整读写优先级,根据实际需求确保重要操作更优先
      3. 启用延迟插入改善大批量写入性能
      4. 尽量顺序操作让insert数据都写入到尾部,减少阻塞
      5. 分解大的操作,降低单个操作的阻塞时间
      6. 降低并发数,某些高并发场景通过应用来进行排队机制
      7. 对于相对静态的数据,充分利用Query Cache可以极大的提高访问效率
      8. MyISAM的Count只有在全表扫描的时候特别高效,带有其他条件的count都需要进行实际的数据访问
  • InnoDB
    • 特性
      1. 具有较好的事务支持:支持4个事务隔离级别,支持多版本读
      2. 行级锁定:通过索引实现,全表扫描仍然会是表锁,注意间隙锁的影响
      3. 读写阻塞与事务隔离级别相关
      4. 具有非常高效的缓存特性:能缓存索引,也能缓存数据
      5. 整个表和主键以Cluster方式存储,组成一颗平衡树
      6. 所有Secondary Index都会保存主键信息
    • 适用场景
      1. 需要事务支持(具有较好的事务特性)
      2. 行级锁定对高并发有很好的适应能力,但需要确保查询是通过索引完成
      3. 数据更新较为频繁的场景
      4. 数据一致性要求较高
      5. 硬件设备内存较大,可以利用InnoDB较好的缓存能力来提高内存利用率,尽可能减少磁盘 IO
    • 最佳实践
      1. 主键尽可能小,避免给Secondary index带来过大的空间负担
      2. 避免全表扫描,因为会使用表锁
      3. 尽可能缓存所有的索引和数据,提高响应速度
      4. 在大批量小插入的时候,尽量自己控制事务而不要使用autocommit自动提交
      5. 合理设置innodb_flush_log_at_trx_commit参数值,不要过度追求安全性
      6. 避免主键更新,因为这会带来大量的数据移动
  • NDBCluster
    • 特性
      1. 分布式:分布式存储引擎,可以由多个NDBCluster存储引擎组成集群分别存放整体数据的一部分
      2. 支持事务:和Innodb一样,支持事务
      3. 可与mysqld不在一台主机:可以和mysqld分开存在于独立的主机上,然后通过网络和mysqld通信交互
      4. 内存需求量巨大:新版本索引以及被索引的数据必须存放在内存中,老版本所有数据和索引必须存在与内存中
    • 适用场景
      1. 具有非常高的并发需求
      2. 对单个请求的响应并不是非常的critical
      3. 查询简单,过滤条件较为固定,每次请求数据量较少,又不希望自己进行水平Sharding
    • 最佳实践
      1. 尽可能让查询简单,避免数据的跨节点传输
      2. 尽可能满足SQL节点的计算性能,大一点的集群SQL节点会明显多余Data节点
      3. 在各节点之间尽可能使用万兆网络环境互联,以减少数据在网络层传输过程中的延时

注:以上三个存储引擎是目前相对主流的存储引擎,还有其他类似如:Memory,Merge,CSV,Archive等存储引擎的使用场景都相对较少,这里就不一一分析了,如果有朋友感兴趣,后面再补充吧。

, , ,