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中。
(本文不涉密)
责任编辑：

转载：感谢您对网站平台的认可，以及对我们原创作品以及文章的青睐，非常欢迎各位朋友分享到个人站长或者朋友圈，但转载请说明文章出处。