登录 / 注册
IT168技术开发频道
IT168首页 > 技术开发 > 技术开发评论 > 正文

性能神化,聊聊Exadata一体机的“七宗罪”

2018-05-02 23:46    it168网站 原创  作者: 投稿 编辑: 覃里

  【IT168 评论】本文是一位战斗在一线,并经常接触到Exadata的DBA个人观点总结,您是否认同?对Exadata,您又怎么看?

性能神化,聊聊Exadata 的“七宗罪”

  什么是Exadata?它跟国内的一些oracle数据库一体机品牌一样,是一套专为Oracle数据库打造的软硬一体化的数据库平台,俗称“数据库一体机”,你可以简单理解成,它们是一个平台,只要把Oracle数据库跑在这个平台上面,就可以跑的又快又稳又安全。

  接下我来跟大家聊下Exadata的“七宗罪”,用“罪”这个词当然是夸张的,主要的目的还是让大家了解到Exadata那些可能还不为人知的一些缺陷,有些缺陷甚至是巨大的,甚至会让你感觉Exadata的这些专有技术非常地鸡肋。如果Oracle公司可以看到这篇文章,能够对产品加以改进,那为写这篇文章花费的数个小时也就不白费了。

  性能,吾将上下而求索

  说“罪”之前,先说说性能的事,因为性能很重要。

  自然和自然的法则在黑夜中隐藏;上帝说,让牛顿去吧!于是一切都被照亮。

  在性能方面很多人把Exadata神化了,Exadata不是牛顿。

  造成这一局面,很大程度来自于Oracle收服了大量技术人员的心,这些人对Exadata的专有技术津津乐道。至于这些技术是不是容易应用,以及应用的条件,技术人员很多时候是不关心的,如果不经过训练,他们很多时候缺乏产品思维。

  人类在历史上有三个问题一直未曾解决,饥饿,战争和瘟疫,未来简史的作者尤瓦尔.赫拉利说,人类直到21世纪,才总算解决了这三大难题。

  数据库领域也一直被一个问题困扰着,那就是性能。特别是,互联网来了,性能的问题更是捉襟见肘。

  很多老人的记忆里都有着吃不饱的经历,一旦浪费一些粮食,就会遭遇巨大的心理谴责,不过根据我的观察,如果他们浪费了一些衣服(买了几乎不穿)这种谴责会非常少。其实不管是衣服和粮食,都是人类劳动的产物,本质没有任何区别,都不应该浪费。

  性能犹如粮食,在数据库的历史上,一直就不够用,当年在阿里从事应用DBA的那会儿,数据库都是要精细化调优的。到了现在,借助于技术进步,各种高性能的架构其实已经让性能不再成为问题了,但是,还是会发现,这种担心性能不够的心理还在影响着非常多的人。

  此外,用户特别在意性能还有一些其他的原因,在此也一并列举:

  · 性能指标好量化。性能作为一个好度量的指标,用户容易把各个供应商的产品区分开。就像我们的高考一样,它的目的并不是为了培养人才,而是为了区分人才,通过一个非常简单的标准也就是分数把人区分开。性能的道理也是一样的,它非常容易测量。当然,我自己不是非常认可这种区分的方法,对于产品的选择,性能只是一个小的方面,就像你选择一辆车,不能只看跑得快不快,你一定还关注它的内饰、安全性等等因素。

  · 性能如果是无限的,那么就可以充分解放业务的想象力。某证券的涨乐财富通的APP可以做到5秒自动刷新账户信息,要知道每秒有几百万客户在线,这个在传统的IOE架构下是不可想象的,有了数据库一体机,就可以释放业务的想象力。

  好了,说完性能,我们来谈谈Exadata的“七宗罪”。

  1、第一杀手锏功能无法在真实环境中落地

  那么Exadata的性能怎么样呢?花开两朵,各表一枝。

  1.OLTP,杀手锏毫无用处

  在OLTP方面,相对于国产的数据库一体机品牌,Exadata并没有优势。主要都是通过利用SSD,以及高效的存储层协议来最大程度提高IOPS,降低IO延迟,毕竟对于OLTP系统延迟是关键。对于IOPS来说,IOPS的值越大,越能保证并发量。这里还需要提一下serversan,传统的集中式存储,机头控制器还有存储的前端口很容易成为性能瓶颈,但是一体机都是使用的serversan,相当于每一个serversan的节点都是一个个可以单独提供动力的节点,保证了IOPS和带宽的可扩展性。可以把集中式存储想象成绿皮火车,火车跑得快全靠车头带,而serversan是动车,每个动车组都单独提供动力。

  可能有Exadata的技术极客会提到Exadata的RDS协议,这个协议是用来集群间传递数据块的,那什么时候需要传递数据块?在多个节点都需要修改这个块时。所以如果去设定一些极端场景,例如多个集群节点对少量的热点数据频繁做更新,那么数据块需要不断的在集群间传递,在这种极端场景下,RDS协议可能会比IPoIB协议会有优势,例如用HammerDB或者Swingbench这种压测工具去做性能测试把压力开到最大(CPU跑满),两者可能会有5%左右的差异。RDS并不是银弹,锦上添花而已。

  2.OLAP,镜中花,水中月

  OLAP方面呢?要知道Exadata本来就是为数据仓库开发的。它的杀手武器就是它的存储卸载。存储卸载做到了:

  1)可以把大量的操作offload到存储层完成,节省计算节点的资源

  2)第二点也是最重要的一点,可以快速地过滤掉那些不需要扫描的数据,这样不但提高了扫描的效率,还变相的提高了存储到计算的带宽。也就是说,Exadata不用在物理设备上做文章,例如把互联层从40GB升级到100GB,通过卸载功能,它就能达到56GB甚至100GB的效果,甚至更高。因此,理论上它比国产的一体机品牌在OLAP方面要强。

  真的强吗?让我这个圈内人爆点料给你听一听。

  先思考一个问题,这个杀手锏也就是卸载功能什么时候能够被用到?

  答:天时地利人和,不比集齐七颗龙珠召唤神龙的难度小。Exadata的销售人员是不会告诉你这一点的。接下来,我们来具体说一说。

  (1)索引的痛

  要启用卸载或者说smart scan,第一个限制的条件是,SQL语句的执行计划必须是全表扫描(全索引扫描也可以认为是全表扫描)。

  也就是,如果你的系统是OLTP类的访问,这个杀手级特性对你是毫无作用的,因为OLTP的特点是查询短小精干,要走索引。卸载功能只能用于偏分析类的系统(例如OLAP),但是请注意,重点来了,在这种分析型场景下,表上不能有相关的索引,否则,按照Oracle的CBO算法有极大可能执行计划不能满足走全表扫描这个前提。

  你可能会说,那不建索引不就完了吗?事实的情况是,每个DBA都或多或少有些“索引情结”,搞一堆索引在表上。这也就是你为什么能够听到很多Exadata的工程师去帮客户优化SQL给出的建议是:“删掉索引”。甚至这句话被传的还神乎其神,说“Exadata太神奇了,没索引才跑得快”。

  然而,删掉索引真的可以解决所有的问题吗?答案是,当然不能。删掉索引不但可能解决不了问题,而且离系统崩溃也不远了。大多数客户的环境,都不是那么的纯粹,不是纯OLTP或者纯OLAP,这些索引可能在OLTP业务下是需要的,如果为了让分析型的任务跑得快,把索引删掉,那么就会影响那些OLTP型业务的服务质量了,而OLTP型的任务对延迟又是最为敏感的。试想,如果每次查询淘宝订单都要十几秒,你一定要疯掉,十几秒的时间都可以看一个抖音短视频了。

  至此,死循环产生了。索引是删还是不删?我遭遇过的大多数客户,都选择了不删,就让卸载功能岁月静好在那美美的呆着,无为而治。更为痛心的是,客户买的Exadata有1/3的钱都是为了这个功能付费。接触的某证券客户,经过统计,只有不到1%的SQL可以用到卸载功能,其他99%的没有特意经过优化的SQL都走了索引扫描。

  (2)必须打开direct path read读取方式

  能用上卸载的第二个条件是,查询必须要走direct path read方式,也就是读取的数据不经过buffer cache,直接放入到数据读取进程自己的私有内存(PGA)中,现实的情况是,不少用户把这个直接路径“读”是关闭掉的,因为这些全表扫描的SQL导致了过多的物理IO。

  所以这对客户来说又是一个巨大的挑战。

  曾经遇到一个案例,某银行的Exadata上,某个表上有频繁的增删改操作,奇怪的是,这个“写入多”的行为导致表上的其它查询操作变得非常慢,最后经过分析是由于很多查询选择了direct path read的读取方式,导致每次读取前都要先把 buffer cache中的脏数据刷到磁盘,等待刷盘的过程中,查询会被阻塞,直到刷盘完成,一旦这种读取操作比较多,就会有大量的查询被阻塞。

  2、上,下,都是折磨

  (一)中说了启用卸载,这个超级杀手锏的功能,所要满足的前置条件,都很难满足!

  此外,你的应用需要做大量的测试验证,中间DBA需要高度配合,而且这个DBA得是个高级专家,review每一个SQL,看是不是要加hint,还是删索引,这个工作量无疑是巨大的,是个系统工程,需要多个角色的配合才能完成。如果为了省事,把所有的索引都删掉,那么你的系统离崩溃也不远了,因为OLTP类型的SQL一定还是通过buffer cache这种内存读的方式查询的快。

  卸载功能,在OLTP场景下,根本无法发挥作用。

  退一万步讲,即使你的团队有大量的Oracle顶级专家,这些工作你都认,认为还是要上,就完了吗?

  并没有。到了某一天,你接受了天启,感觉到Exadata并没有想象中那么好,想换掉它,悲剧又会重演,因为,你还需要把当初review过的所有的SQL重新review一遍,哪些加过的hint可能要去掉,或者把当初删掉的索引再加回来,这又是一个极为漫长痛苦的过程。这个过程,我亲身经历过,而且现在还正在经历(某银行客户)。

  我非常认可一句话,

  “人类技术的发展有一个很重要的概念,不断地让一个难被驾驭的技术,越来越容易地被普通人操纵。”

  就像美图秀秀战胜PS,一个技术能被越多的人驾驭,价值才越大,从这一点上来说,Exadata在钻牛角尖了,客户去落地使用这个产品是非常困难的。技术本身可以很复杂,但是对客户而言,界面要足够的简单。

  3、上帝的归上帝,凯撒的归凯撒

  Exadata有一个EHCC的压缩功能,这也是他的第二大杀手锏功能。毕竟Exadata这个产品主要是面向数据仓库系统的,压缩功能被提到这样的地位并不为过。

  不过,在这里,我负责任地告诉大家,该功能只能在Exadata上使用,意味着你的容灾也得用Exadata来搭建,不能使用通用平台来做Exadata的容灾,这是巨大的成本啊,即便是银行,面对如此高昂的成本,也得思量思量吧。

  如果你选择了用通用平台来搭建Exadata的容灾,使用EHCC压缩过的数据将不能被访问,除非使用特定的办法花大量的时间去做解压才行。此外,压缩还会让数据的备份和迁移同样变得头痛万分。再有,数据的压缩本身就如硬币的两面,节省了空间,消耗了CPU资源,更为重要的是,对于Exadata来说,压缩是必须在计算节点完成的,不能卸载到存储节点,如果要压缩的数据量比较大,那就得思考一下,毕竟客户是要为计算节点的CPU付大量的license费用的。

  这里提一下,我接触到的很多客户其实是把压缩功能关闭掉的,做这样的牺牲,就是为了能够使用通用平台来搭建容灾,不过可惜的是客户是为了这个功能支付了大量的费用的。

  以上介绍了这么多都说明了Exadata是一个封闭的系统,上了这个船,你就得一直在船上,这个船可不是诺亚方舟。它让用户产生了巨大的沉没成本,被沉没成本绑架后,用户只能老老实实呆在船上。很多人只是买了一张40块的电影票,看到烂片,也得坚持把片看完,更别说是一个几百万上千万的设备。

  4、技术门槛太高

  从市面上很难招聘到一个懂Exadata的DBA,而Exadata要想用的好,恰恰需要一个非常懂行的人。如果用户的DBA技能不达标,那就只能“无为而治”了,我经常参加一些oracle圈子里的活动,接触过的很多第三方数据库服务公司的专家都说,对于Exadata,绝大多数客户也都是“无为而治“的。可是,客户为了那些杀手锏的功能是支付了几百上千万费用的,就像是买了匹汗血宝马,结果没人能够骑,骑的门槛很高。

  5、Exadata并不包含license

  给大家纠正一下:不要觉得买了Oracle Exadata就理所当然的包括了Oracle数据库的license,Oracle Exadata是个Oracle数据库的硬件运行平台,它本身不包括Oracle License,各位买过Exadata的可以看一下,是否Exadata的软件清单里包括了Oracle 的数据库许可,还是客户需要重新购买?

  6、万年不变的40G

  我们都知道计算机硬件基本上按照摩尔定律在发展,Exadata 自从2008年推出至今,在近10年的时间里,核心网络一直初心未改运行在40Gb的IB上的,而国内的一体机早都有100Gb以上的产品了,带宽的效率提高了3倍。可能有人要说,它有卸载功能,40Gb 够用了,不需要提升带宽,但是前提是要有专家DBA对SQL做精细化的调优,这将带来巨大的系统管理成本,数据库系统也越来越复杂。大家为什么不接受简单高效的方式,升级到100Gb-200Gb的网络呢?

  我想最大的可能是因为,如果它升级了网络,它存在的合法性就不存在了。Exadata最大的卖点就是通过卸载功能来最大化提升自己的价值,如果通过提升硬件来达到提升性能的目的,它岂不是没有面子?这从一定程度上来说,还是以“产品为王”的思路来做产品,而不是以用户的需求和痛点来做产品。国产的一体机品牌在这个方面更愿意采用更简单、对DBA和业务更透明的的方式来释放数据库的性能。

  7、维保 & 扩容

  第七点就不详写了,谁用谁知道,好像没遇到过对Exadata 维保、扩容满意的用户,可能是高额利润赚习惯了吧,没办法说!另外维保、扩容,升级都极其复杂,服务响应也非常地不及时。其余内容,大家自行脑补就好。

  Exadata的未来

  说说Exadata的未来,我有点咸吃萝卜淡操心了,我曾经发朋友圈说既然Exadata这么复杂,如果可以结合人工智能,深度学习技术,那么它的前景还是非常不错的,但是最近又反思了这个问题,可能答案并没有这么简单。(事实上,oracle公司从18C起已经开始搞自治数据库了)

  就像上面提到的,Exadata有一个非常大的问题,是不容易使用,感觉上就像是一堆热爱技术的极客搞了一个使用门槛很高的产品,如何才能降低它的使用门槛呢?我以前认为的答案是,借助于深度学习的人工智能技术,让Exadata通过自治来达到降低使用门槛的目的。

  但是我这个想法现在想想不太接地气了。大多数客户选择使用Exadata,会把比较重要的业务放上面,只要是重要的业务系统,都有一个显性的需求——“我要稳稳的幸福”,客户一定不希望看到,今天自治系统决定加个索引,明天又决定删个索引,这会带来不确定性,而核心系统最需要的属性就是确定性。

  你可能会认为我是一个技术悲观派,但是我要说明的是,我非常看好人工智能在数据库领域的价值,但是它最大的应用场景是在非核心的数据库场景上,这些数据库,不需要DBA操心,哪怕慢,慢就慢点,只要省事就好了,这些非重要的业务系统对于企业来说数量上也是非常多的,因此自治数据库是非常有前景的,但是核心数据库还有的搞,路还很长,等自治数据库可以提供确定性了,才能去考虑。

  • IT168企业级IT168企业级
  • IT168文库IT168文库

扫一扫关注

行车视线文章推荐

首页 评论 返回顶部