SAP HANA的优势

首先，我想这么开始：

(a) 对昨天完全没抓住重点的技术方法的比较

在下文分析中，我将试着简单扼要地沟通所有观点。并且我会一直更新这个博客，以期持续提供SAP HANA的真相。下面是对部份错误观点的纠正。

#1 未来的数据库设计走向

错误: “内存数据库(In-Memory DBMS) 将不会完全取代关系型数据库(relational DBMS)”.

正确: 内存数据库（In-Memory DBMS）是未来数据库设计的主流。它已经占据了绝大部分的数据库市场－尤其是在分析，计划，模拟和实时应用领域（比如游戏市场）。它的设计基于完整详尽的学术研究，支持OLAP和OLTP。内存数据库已在性能至上的需求市场广受欢迎，另外在云计算和交互式应用的影响下，企业级市场也将逐渐向内存数据库转变。

#2. 数据库平台的作用Role of the Database Platform

错误: 内存数据库（In-memory database）只能做像MOLAP, 业务报告， 查询 & 分析，计划 & 预算, 非结构化信息处理等一小部分事情。

正确: SAP HANA 是一个通用的内存数据库平台－ 带来全新的数据，捕捉符合ACID的交互，在发生时同步分析，做数据库处理，推动业务，预测和规划到数据库中的逻辑，同时还能够支持分析终端，云端和移动运用终端等各种客户端。内存数据库的运用远不止在很小范围的使用案例中所描述的那样，它拥有更多的超越想象的主流应用。你不用为了满足不同需要而在一个盒子内加入多种技术和重复的引擎， (比如，Endeca – text Essbase - planning, TimesTen - caching, analytics).

#3. 日益增长数据量的延展 & NUMA 支持

错误: SAP HANA 对数据集市和数据仓库的支持非常有限，并不能向外扩展

正确: SAP HANA 能向外扩展无限的内核／节点，并减少硬件开销。在我们去年五月召开的SAPPHIRE NOW会议上， Hasso 已经展示了32个节点／1000多内核32 在SAP HANA 上运行的场景。(大约在他演讲的13.45 分).  另外我们在全球运行着3个这样超过1000个内核的系统。我们有客户和一些合作伙伴正在多节点可扩展系统上使用HANA，包括IBM和HP，已在生产扩展设备。

不仅如此，近期在IBM16节点的 X5服务器（ 16 nodes of IBM’s X5 servers）上运行我们的100TB标准检查程序（ benchmark），每个占用主要内存的1／2TB，同时就操作报告场景能在300毫秒－500毫秒内处理100TB的BW数据； 随机分析查询（ ad-hoc analytical queries）场景下则为800毫秒－2秒。（our recent 100TB benchmark runs on 16 nodes of IBM’s X5 servers each with ½ TB of main memory and processes 100TB of BW data in 300ms-500ms for operational reporting scenarios and 800ms-2s for ad-hoc analytical queries. ）

更进一步说，类似过期标准（ aging criteria）等标准的HANA机制能置换掉相应数据。HANA支持NUMA结构。 与之相反，公开出版文献强调 Oracle Exalytics 存在1TB的限制，并且他们曾经公开表示，对他们所有放在一起的产品 (Essbase+Endeca+TimesTen)来说，这1TB在很大程度上会被用于工作所需内存。

#4: OLTP & OLAP

错误: 据传SAP HANA的“写入性能有限”。

正错: 在一套硬件和一套操作系统上，SAP HANA 对OLTP+OLAP是单一基础。它可以向上和向外扩展（通过不同的节点能从最小单位一直到1000＋的内核），并且它能动态地调整工作负载。 我们是唯一的带有列存储（columnar store）插入的高写入性能和高分析性能的内存数据库。这是SAP HANA和其他数据库的关键区别。

#5: 存储－行，列，和文本Stores – Row, Column, and Text

错误:  SAP HANA 是“不支持非结构化数据”，并且不提供“行和列的压缩”。

正确: SAP HANA 将行，列和文本存储在一个数据库里，自然会支持非结构化数据。再者这些都被集成从而简化了所有存储间的交互和分析操作。实际上，非结构化搜索是SAP HANA的基础。它能像处理标准搜索和文本挖掘一样处理结构化数据上的搜索文本。 借助 Inxight 技术，类似标记，特征提取，单位提取或者情绪分析之类的语言学特征也能被纳入SAP HANA。 Inxight是当下市面上最好的语言分析软件。

SAP HANA 支持列存储内的大数据量压缩。行存储不需要大数据量压缩，因为它仅用于列存储的缓冲和压缩无关表格。SAP HANA 的优势在于和应用程序堆栈之间的智能集成，这使得行存储压缩变得无关紧要。

#6. 数据缓存 & 查询优化

错误: SAP HANA 和 TimesTen 都有数据缓存.

正确: 过去的数据库版本会使用缓存来提升性能。 HANA 是建立在新架构典范上的纯内存数据库。考虑到所有的数据库都是在内存中，所以HANA不缓存数据。具备世界级的查询优化器，能轻易实现大规模并行查询的操作，包括运算符内部和运算符之间的并行查询（ inter and intra-operator parallelism）。

#7: ACID 属性和事务的完整性

错误: SAP HANA 没有“没有事务完整性／正确性并且在多版本并发（ lacks multi-version concurrency ） (MVCC) 上有所欠缺”。

正确: SAP HANA 完全遵照ACID，考虑到备份和持久性，我们采用永久的存储系统。它是完全多版本并发并带有类似语句级和快照隔离之类的常规功能。

#8: 聚集和物化视图

错误: 高性能需要聚集数据的物化视图

正确: 又一个 Ha! 电动车不需要火花塞。内存中处理的每一数据的实时聚集比性能里的聚集高得多。聚集已经是过时的技术了，因为它需要花太多气力去做一些根本不必要的创建，存储，同时还要管理更改。SAP HANA 并不像传统数据库一样为系能而需要索引；无论从那一种维度的数据设置来看，这内存数据库自身就是索引。

#9: 商务智能终端

错误: SAP HANA 几乎不对任何商务智能终端提供支持provides limited support to few BI clients.

正确: 经过优化，SAP Business Objects 已经能在 SAP HANA上运行。外加现在有超多可用的第三方终端(e.g. Tableau, Tibco Spotfire) ，所以在 SAP HANA 上，我们将持续对第三方商务智能终端的完全开放态度。

#10: 规划申请和分析功能

错误: SAP HANA 不支持规划和预算编制应用程序。

正确: SAP HANA 完全支持规划应用程序。许多SAP企业性能管理程序都能在SAP HANA上运行。SAP HANA在数据库中有本地规划支持 与规划引擎。在SAP HANA中，类似分列，复制等运算符都是关系代数的一部分。除此之外，我们支持SAP 数据库内自带的规划语言FOX。

规划，而不是其他方式，对 SAP HANA 来说是一个超级大的参数（huge argument）。因为采用即时运算的缘故，SAP HANA 不需要标准多维操作（standard cube operations）。 SAP HANA 的库不仅涵盖了主要的分析和业务功能，例如汇率转换，单位换算，异动加权（ exceptional aggregation），时序分析，层次处理和预测功能，还扩展支持其他库。在HANA上的SAP BW 是不需要层的；我们将规划计算（ planning calculations）推下至HANA的数据库，提供更高的性能。SAP HANA 将支持所有的交互应用，企业仓库，BI和所有的云应用。我们也有第三方合作伙伴开发内置SAP HANA的规划软件。

#11. 操作报告 & 数据源

错误: 由于“受数据类型限制”，SAP在同步和ETL技术方面的操作报告能力有限

正确: SAP 有一套超赞的应对多源实时操作报告的解决方案（例如 SAP CO-PA Accelerator）；它们中许多是非SAP应用数据类型。SAP数据服务（ SAP Data Services）和 SAP Sybase 同步服务器（ Replication server）有市场领先的 ETL & 同步技术，能传导非SAP和SAP的数据类型。由于巨量平行架构（ massive parallelism），HANA 有非常高的批量行插入率（ bulk inserts）。实验结果显示，它不仅支持所有数据类型，传输率还能达到每小时2TB以上。

#12. 价格

错误: “SAP HANA 比Exalytics贵5－50X。” 1 TB HANA 硬件大概要支出 $362K, 另外SAP HANA 软件需要支出$3.75 M.

正确: 如果是1 TB，我们预期的硬件开销在 $40-$60K (不是$362K) 软件更不可能有吹的那么贵。当然，SAP HANA在不同市场有不同价位。

从HANA自身来看，范围从合理价位的小业务（例如$12K单节点硬件＋ $2K HANA和在HANA上运行的 SAP B1 Analytics）到非常大的，可能需要超过100TB内存的业务场景。客户不仅能针对某一应用（ BW, BPC, CO-PA, Smart Meter Analytics, etc.），也能针对数据集市和数据仓库购买HANA。 对40 TB 的数据仓库，BW 在 HANA上是非常有竞争优势的。同时，HANA的售价另含了顾客需要的一切－测试，开发和质检环境（ QA environments）和支持。 因此也不需要多一笔开支在购买数据上载，迁移，存储加速等软件 (比如Exadata) 上。综合上述因素，拿512 GB使用配置随便举例， SAP HANA比同类竞争产品节约近一半的总成本。

#13: 标准和开放性

错误: “HANA 只适应SAP的工具，仅具有限或非标准SQL”.

正确: 相当大一部分客户使用HANA处理非SAP数据和相关用例－SAP和非SAP应用用例都可以。HANA在标准 SQL 和 MDX上运行，对所有程序采取标准统一界面。在每一层上它都是开放的：

举例来说， Oracle 应用和 Oracle BI 都能在SAP HANA上运行良好，没有任何异常。 Oracle 内现存的程序因IP的因素被翻译成SQL文本，这一点很好体现了SAP HANA的开放性。

#14: SAP HANA 在磁盘上的表现（on disk）

错误: SAP HANA 不支持存储在磁盘上的数据。

正确: SAP HANA 通过类似最近访问过的数据（ Least Recently Used (LRU)）一类的优先级技术支持磁盘存储数据。 SAP HANA 能将相关数据保存在内存中，另外磁盘中的数据能根据需求进行上载。

#15: 查询速度

错误: SAP HANA 在查询执行上不会比其他数据库更快。

正确: SAP HANA 将所有数据以整体形式存储在列中。另外还采取了 发展中的向量运算处理器（CPU developments in vector operations）这类英特尔最新的优势技术进行了优化。SAP HANA的前瞻性架构（ next-generation architecture）和芯片级创新（ chip level innovations）使它远远超越了市场上的任何竞争对手。打给比方，我们有四位客户经历了SAP HANA 在100,000X业务流程速度上的改善。MKI是其中的佼佼者， 显示出408,000X在零售／物流数据分析的改进。（For example we have 4 customers who have crossed 100,000X improvement on the speed of business process with SAP HANA. The leader in the pack is MKI, showing a 408,000X improvement on retail/logistics data analysis.）

#16: SAP HANA 比 Exadata & Exalytics慢

错误: “SAP HANA 连 Exadata的速度都及不上，更不用说 Exalytics”.

正确: 某客户的基础架构上曾出现过这么一个例子，对信用检查和信用额度核查的业务流程，同样的数据，同样的查询方式， SAP HANA 比 Oracle Exadata 快 15,000X 。这种实时性能是和有其固有架构导致内在延迟的多种冗余箱在交互性，分析性，内存加速和文字处理上进行的比较（ Compare this real-time performance to multiple redundant boxes for transactional, analytical, in-memory acceleration and text processing that have inherent latency in their architecture. ）我们在不止一位客户身上发现了这种情况，这里只是举这个作为例子。

现在市面上的主流方式示意图

SAP HANA所采用的新方式示意图

#17: 安装和实施体验

错误: 安装SAP HANA需要好多天，实施则需要数月甚至数年

正确: 在一个数据中心中只要几分钟，最多一个小时就能装好SAP HANA。实际上很快你就可以从我们或我们合作伙伴的云中安装。Provimi 盈利分析3个星期就gone live。

#18: 考勤－差旅（Time-travel ）

错误: 如果没有明显开销，数据库很难展现基于时间的报表。

正确: 借助 SAP HANA，你能做时间报表遍历（ you can do time traversal on your reports ）（例如比较每日实际和预测时间）compare actual vs. predicted by day) 。另外，举个例子，能用滑块来阅览时间轴和实时生成的报告，而不需要另存指标或视图。

总结

我陈述了事实并需要你相信 SAP HANA的真相。 SAP HANA的性能是对传统数据库市场的挑战。它对 OLTP+OLAP 是单一基础，只需一台硬件设备和一套操作系统。 小至mac-mini，大至1000+ 内核的服务群它都能运行。HANA的技术规范，交融了我们真正在意的各种特性：

这些提出的是在性能上大幅改进的命令。 SAP HANA 通过革命化客户互动，财务和供应链性能，为公司创建了巨大的商机和竞争优势。农夫山泉正在关掉 Oracle（ 22k在 Oracle DB的改进）。

我们也在制定新的领域，比如在医疗保健中进行革命性的基因组分析，或在全球实践实时商务银行交易，或者是我们这个时代其他重大的挑战。时代需要我们进入这些新的领域，不要固步自封，而要创建那些我们也许能将其变成现实的美丽可能。时光短暂，生命怎可被流言耽误。