SAP HANA与甲骨文Exalytics

引言：

SAP邀请了我从分析师的角度，来评论一下“HANA与Exalytics”之间存在的争论。这个比较很有趣，所以我也欣然从命。这篇文章会让你们了解我对它们的看法。你们会看到，我不会把两者分得很清晰(而不看到文章最后，我和SAP之间关系也不会完全披露)。

Exalytics：

首先，来说说每个分析师都知道的事吧：Oracle生产了好些我们在零售业中称为山寨货的产品。

他们认为这是一个好行当，我觉得这也没错。这个模式很简单。当有人创造了一个产品，并证明了市场，Oracle(或者拿SAP打比方也无妨)就会开发出一个类似的产品。所以，一有 了VMWare (或其他厂商) 的 vSphere，就出现了Oracle的Oracle VM;Red Hat建立了一个围绕Linux的商业模式, Oracle 就创建了 “Oracle Linux –坚不可摧的商业核心”。

分析师们也深谙此道，并从此获利不菲。那些山寨产品——说得好听点就是“Oracle的紧跟潮流的产品”——在性能上与它们的效仿对象都能兼容。但在某些方面，或者某些边缘，Oracle声称自己的产品更胜一筹。

这些话让听到的人很困惑。他们一困惑，就会打电话给我们。作为一名分析师，我接到的这样的电话也不在少数，我也仔仔细细地研究过Oracle的一些产品。一直以来，我都认为Oracle能提供的产品，与你能在Pennys或者Target上看到的差不多，它们对于付不起或者不想付溢价的人来说是合适的替代品。这些人往往会限制自己的供应商数目，对产品也没什么太高的期望。

我这么想，是因为你对当今的市场只能抱有这种观感。毕竟就像在下雨前你匆忙从路边摊买到的一把伞一样，你会觉得这真好，因为它可以遮雨。但是你也不会指望这把伞能耐用到陪你走过多年的风风雨雨。

软件当然比一把伞更复杂。软件行业并不十分透明化，有时候要分辨出各种声明背后真实的含义是件很困难的事。你要一直、一直往下挖得很深——就像有时候我的客户会指责我——“挖到了杂草的根部”，这时候也许你就能得到真相，但是也会失去一部分说服力。

这一点让我想到了现在这个争论。这对我来说又是个熟悉的循环。SAP创造了HANA, Oracle紧接着生产了Exalytics，两者都是储存在内存中的数据库应用。于是我又接到了很多的电话。

HANA： 重要的特性

我会带你们过一遍两者的区别，与此同时希望我不要“挖到杂草根部”。在这个过程中我会引入一些比喻，如果你们觉得我说的没有说服力，请不要客气马上联系我。

要进行说明的话，我就要避开那些像是“内存中”或是“分析”的术语。鉴于SAP和Oracle现在正在用同样的词语，我们要关注的是“内存中”或是“分析”等术语要解决的更深层的问题。

而这些问题其实并不单一。问题1：传统的行式数据库能很好地存储数据，但在输出上则欠缺了一点。问题2，为了解决 问题1而诞生的众多“分析数据库”——包括但不限于SAP在使用的列式数据库——性能刚好相反。

我们需要的，往往是一个能很好地存储数据的列式数据库，或是一个能很好地输出数据的行式数据库。

HANA处理这个问题的方式就十分有意思。在它们的数据库中，你可以选择处理数据的方式：要么行式要么列式。(如果你想的话，你可以在脑中模拟出一个控制切换的开关。)所以，如果你需要优化只读，然后让列式数据库达到其设计目的——一份快速灵活的分析报告的话，你可以拨动开关，告诉HANA： “我要运行报告。”。如果需要优化写入，使行式数据库达成所愿——完成事务行为，你可以拨动开关，告诉HANA：“我正在进入一个事务。”

其实数据都是一样的，拨动开关决定的只是你的访问模式。

我以前的同行、现在的一名SAP主管Adam Their曾经向我解释道：“其实这是一个反分析的数据库。”(这应该不是SAP的官方说法，但是我很能理解。)他们是怎么让数据库“反分析”的呢?这个时候就要快速钻入杂草底部了。他们使用在内存中的功能来做缓存和索引,其速度远远超过原本内存价格下跌之前可能达到的速度。

[空谈警报：Hasso看了我这篇博客的未删减版后，拦住我说：“David，你那个拨动开关的说法不对啊。你以为是挥舞什么魔法棒吗?HANA要复杂的多。”你们也可以看到之前的评论，网友大多对“开关”这个词很感冒。好吧，我承认，我在这里完全是在空谈。那些想要知道的更详细的网友可以关注我的下一篇博客：“行与列的故事”。]

内存中的处理方式还解决了另外一个很大的问题。在传统的SQL数据库中，你可以进行的唯一的一种操作就是SQL——对行和行内字段的操作。问题就在于，在传统的数据库中数据上进行的策略操作：比如一个数据统计功能(一个回归分析、或者更加简单的数目计算等)，有时候也会变得复杂而又困难。

然而在HANA中，商业功能(非市场营销从业人员称之为统计分析程序)是被植入进数据库的。如果你想做一个预报，你可以仅运行一个合适的数据功能。那就不像纯SQL数据库那么笨重了。而且它非常，非常的快。我亲眼看到过三个数量级的速度提升。

Exalytics： 重要的特性

我指出了HANA可以行式(对事务)也可以列式(作为一个良好的分析数据库)的特点;我也提到了HANA中植入的商业功能。提到以上内容的时候，我并不是在比较HANA和Exalytics之间关联的优点。

为什么呢?这个。。。因为在Exalytics中，你也可以在事务中心的数据库中输入数据，或是在分析数据库上的数据上运行报告。在Exalytics中，你也能有一个业务功能库。

但是完成这一切的方式大为不同。

在Exalytics中，内存中的数据库(Oracle在十余年前购买的一个旧的Times10产品)衍生出事务能力。分析能力则由Essbase(Oracle5年前购买的产品)而来。业务能力库则是R统计编程语言开放源代码的实现。

所以Oracle一定会辩称重要的特性它都有;甚至它有一个边缘，使得产品明显优于他家。如果你购买了Oracle 的Exalytics，你会得到经过测试、久经考验非常好用的数据库与功能库。因为Times10自从成立以来就成为了Salesforce.com的核心;Essbase是Hyperion的心脏，全球2000强大多数都用它;而国内每一所大学都使用R语言。

困惑了吧?这是应该的，是时候打电话给分析师了。

HANA 与 Exalytics

到底两者区别何在，区别又有什么意义呢?如果你是一个很一本正经的数据库学究，你马上就能明白了：

在HANA中，数据都存储在一块儿;在Exalytics里，数据被分开存放。

所以在HANA里，如果你想在数据上运行报告，拨动那个虚拟的开关吧;在Exalytics里，你需要从Times10数据库中抽离出数据，转换他们，然后再导入Essbase。在HANA中，如果你要运行一个数据项目并存储结果，直接照做便是;在Exalytics中，你要从，比方说是 Times10的数据库中抽出数据，将它们挤到R语言能够操作的地方，运行项目，然后再将数据挤回Times10中。

这又有什么大不了的?所以说，如果你是一个一本正经的数据库学究，你就能领悟了。(为这篇文章做研究的时候，我问了一位学究为什么这个很重要，然后他给了我一个经典的耸肩和大白眼儿。)

我想我能明白。。我猜移动数据也花时间。既然牵涉到的数据库并不能完美兼容，移动数据之前就要先将其转换。(Essbase是出了名的不处理特殊字符的，至少它不习惯这么做。)因为每个数据库中的数据都不同，时间和版本就必须卡得很准。当你在移动很大容量的数据时(比如以兆字节计数的)，你就得为空间问题担忧了。而我确定1TB Exalytics 只有 300 GB 的实际内存空间。

关于Oracle，有一件事是肯定的：他们对以上这些缺陷了如指掌。在他们的市场文化中，他们尽可能地批评了这些观点。"Exalytics," Oracle 宣称, “它的通道有无线带宽，这些通道能使数据能在数据库之间飞速地流动。Exalytics有统一管理工具，让你能对数据进行追踪。”的确，移动数据时也许会发生一些问题，但是 Oracle一直努力让你专心于“久经考验非常好用”的理论。 所以它的意思是，如果你非要在数据库之间移动数据的话，既然这些数据库这么好，这么靠谱，基础设施都这么齐全了，还怕什么呢，走你!

只要几个数据库在一个盒子里就行啦，他们会这么说，而且他们的工具更好用更可靠。

还困惑吗?只要你不是学究应该就没问题了。否则，我觉得你可能是。而且我觉得你可能会被激怒了。“这篇文章写了几百行，都没解释清楚这两样产品有什么区别!”我能听到你这么说哦。

[警告升级了：在评论中，一名Exalytics砖家说我对于客户如何使用他们产品所做的标明是错误的。如果他说对了(我觉得他是对的)，那么跟Oracle的市场营销说的完全不同的是：Exalytics与HANA在事实上根本就不可比。现在你更加应该读完这篇文章剩下的部分——关于HANA 到底是个什么。读的时候就理所当然的认为HANA是自成一派的好了。]

微信扫一扫实时了解行业动态

微信扫一扫分享本文给好友