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

在做网站、成都网站建设过程中，需要针对客户的行业特点、产品特性、目标受众和市场情况进行定位分析，以确定网站的风格、色彩、版式、交互等方面的设计方向。创新互联建站还需要根据客户的需求进行功能模块的开发和设计，包括内容管理、前台展示、用户权限管理、数据统计和安全保护等功能。

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

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

性能，吾将上下而求索

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

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

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

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

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

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

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

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

此外，用户特别在意性能还有其他的一些原因，也一并列在这里：

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

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

Exadata第一罪，第一杀手锏功能无法在真实环境中落地

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

OLTP，杀手锏毫无用处

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

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

OLAP，镜中花，水中月

• OLAP方面呢？要知道Exadata本来就是为数据仓库开发的。它的杀手武器就是它的存储卸载。存储卸载做到了 1）可以把大量的操作offload到存储层完成，节省计算节点的资源 2）第二点也是最重要的一点，可以快速的过滤掉那些不需要扫描的数据，这样不但提高了扫描的效率，还变相的提高了存储到计算的带宽。也就是说，Exadata不用在物理设备上做文章，例如把互联层从40GB升级到100GB，通过卸载功能，它就能达到56GB甚至100GB的效果，甚至更高。因此，理论上它比国产的一体机品牌在OLAP方面要强。

真强吗？让我这个圈子里的人爆一点料给你听一听。

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

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

索引的痛

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

smart scan是卸载的一个类型，用于SQL语句，卸载还可以对数据库文件的快速创建，RMAN增量备份等有效果，不过这篇文章并不是做技术的深入探讨，简单的把卸载和smart scan做了等同。

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

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

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

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

必须打开direct path read读取方式

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

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

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

Exadata第二罪，上，下，都是折磨

以上说了启用卸载，这个超级杀手锏的功能，所要满足的前置条件，都很难满足！

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

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

即使退一万步，你觉得自己团队有大量的Oracle顶级专家，这些工作你都认，认为还是要上，就完了吗？

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

我非常认可一句话,

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

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

Exadata第三罪，上帝的归上帝，凯撒的归凯撒

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

不过这里我负责任的告诉大家，该功能只能在Exadata上使用，意味着你的容灾也得用Exadata来搭建，不能使用通用平台来做Exadata的容灾，这是巨大的成本啊，相信就是银行，面对这样的成本，也得思量思量吧？

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

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

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

Exadata第四罪，技术门槛太高

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

Exadata第五罪，Exadata并不包含license

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

Exadata第六罪，万年不变的40G

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

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

Exadata第七罪，维保 & 扩容 & 服务

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

Exadata的未来

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

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

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

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

当前名称：性能神化，聊聊Exadata的“七宗罪”
标题路径：http://scyanting.com/article/jgjspd.html