原文：http://www.saphana.com/community/blogs/blog/2012/09/14/hana-and-exalytics-there-is-barely-any-compar...
原作者：Robert Klopp
四月份（2012，译者注）的时候，我开始将HANA当作一个竞争对手。那时候我还是EMC在EMEA的Greenplum分部的区域CTO。关于HANA和Exalytics，我还写了一篇博客。在此，我想重申一下那篇博客里的观点。让我们来想一下Exalytics是什么，以及它不是什么；HANA是什么，不是什么。它们在什么地方重合、竞争。最后，在他们可能竞争的领域，想一想谁在架构上更有优势，而不是市场方面。我希望，你会觉得我说的公平而且有事实依据。
为了说明什么是Exalytics，我将引用Exalytics的主要倡导者、Oracle的合作伙伴，Ritman Mead。它参与了最初发布计划。他们说：“Oracle Exalytics使用Oracle内存数据库Oracle TimesTen的特别改进版，缓存报表中常用的聚合数据、分析数据和其他BI数据。”为了证明我没有断章取义，你可以读一下这篇文章的完整版，或者到Ritman Mead Exalytics的测试中心去看看。你也可以读一读Oracle Exalytics的文档，自己去确认这点。尽管文档中说地比较含糊。需要注意的是，当你在读这篇文档时，你会看到数据库中的数据将会“活”在另外一个DBMS实例中。正是这个实例维护了所谓的“常用的聚合数据”。所以，Exalytics是一个OLAP引擎，将分析数据保存在内存中以便快速访问。
你可能会问为什么需要这些缓存，为什么这些基础的OLAP查询需要辅助？这说明Exadata是有问题的。更多的细节可以在一个主要的Exadata效率专家的博客里找到。这个博客里有两个视频。第一个描述了一个问题，第二个则是用Orcale的一次演示来说明这个问题。对于那些已经在用或者打算用Exadata的人，我强烈建议先看看这两个视频。
HANA是一个先进的，基于内存列式架构的数据库，使用非共享、多线程的机制。我知道，这些听上去有很多营销的意味。但是正是这些架构方面的组件才确立了我们与竞争者的不同之处：
- HANA和Exalytics都是基于内存的。这两个系统都通过降低I/O来提高访问效率
- 列式存储使得HANA能够更好地压缩数据，而这种压缩能力是行式存储难以达到的。Exalytics提供了一种字典式压缩机制，他们称之为列式混合压缩，但是这个名字有点儿误导。Exalytics不是列式DBMS。列式存储也使得HANA可以将数据保存在处理器的内部缓存中。与从主存中读取数据相比，这样做可以将效率提高200多倍（参考）。但我们只是说它给HANA提了速。
- HANA支持大并发操作。这说明HANA可以使用所有的核来执行一个简单的查询。如果运行在一个40核的服务器上，与单一线程的实现相比，HANA可以在上述的加速基础上，再将一个简单的查询提速30到40倍。
- HANA采取非共享机制。这说明你可以通过扩展来解决更大的问题。在一个拥有512GB内存的大服务器上，HANA和Exalytics都可以存储大约256GB的压缩数据（实际上Exalytics存的少一些，参考这里和这里）。如果你要往Exalytics添加更多的数据，你会受挫。你也可以分隔数据，分配查询，但是你不能将Exalytics的实例联合起来。而且每个查询只能使用一个服务器。对于HANA，添加数据十分简单，你只需要在所有处理器的范围内重新分割一下数据。这种改变是透明的，并且每个查询都可以运行在每个服务器的每个处理器上。Exalytics不能扩展。
- HANA是一个DBMS。你可以做任何DBMS可以做的事情，联合查询、存储过程、数据库分析，任何事情。实际上，HANA在查询时动态创建OLAP结构，取消预先聚合或实例化。但是，你也可以在OLAp结构中预先聚合数据，然后执行同Exalytics一样的查询，同时利用列式存储的加速、充分利用CPU、扩展、以及一个DBMS的所有功能。
如果有一个地方HANA和Exalytics可以竞争的，那就是对OLAP查询的处理。任何的有关Exalytics可以解决其他数据库问题的暗示都有误导性。任何有关Exalytics是Oracle对HANA回应的言论也是误导人的。HANA不仅仅“缓存报表中常用聚合”。Exalytics或许在疾呼内存数据库是一个强大的架构，但是基于其他的架构组件，HANA仍然比Exalytics（Oracle的OLAP加速器）快很多，即使是在一个内存这一个狭小的领域内。
