原文链接： http://www.experiencesaphana.com/community/blogs/blog/2012/05/03/the-sap-hana-effect
在最近的一次公开网络研讨会上，某位竞争对手由于缺乏对SAP HANA的了解，而对产业和金融分析师发表了有限的和不准确的理解。在SAP我们通常不对这种事情做出回应。但是这个戏剧化的事情的发生，让我不禁思考：我们一定是做了很正确的事情！我是指，一个数据库的领先和卓越的建设者怎么可能根本不知道下一代数据库技术呢？或者，仅仅因为他们不愿意承认现实，所以才以讹传讹？
HANA团队对三件事有着同样的激情--HANA客户的成功，寓乐于工作，对现状质疑。本着这一精神，我想代表HANA团队，将我们的记录设置在我们的竞争对手的一些不准确的信息上，这样做本身也是十分有趣的。
SAP HANA 优势
一开始，我想指出的是：(A). 对过去的技术方法进行比较是完全没有意义的。(B). HANA的客户都享受着不间断的现代技术所带来的非凡好处。(C). HANA代表了企业计算环境中、特别是在数据库技术的全新一代。这是一个为实时分析和应用而产生的现代的数据平台，它使组织能够根据各种体积大而详细的数据实时分析业务操作，它的存在消除了OLTP和OLAP系统之间的延迟和层，使它们成为 “真正的”实时系统。SAP HANA Advantage是一个紧密集成的系统，不同的完全事务性的组件集成在系统优化器中。所有组件，如OLTP，OLAP（业务以及仓库操作）都能无缝地工作，来进行向上和向外扩展文本、规划和纯应用程序的开发。在没有服务器zoo、没有内部复制、没有物化聚合、更没有堆栈引擎的情况下，它也可以方便地部署！
在我下面的分析中，我会尽量精简一些。我会定期更新这个博客，不断为SAP HANA还原真相。修正如下：
#1 数据库的未来设计中心
错误观点: 内存DBMS无法替代所有或大部分关系型DBMS。
正确观点：内存DBMS是数据库的一个未来的设计中心。它已经取代绝大部分的数据库市场--尤其是分析，规划，仿真和实时应用程序（例如：游戏市场）。基于完善的学术研究，它能支持OLAP和OLTP。它在性能至上的市场中已经成为流行品。就像改变了云以及事务处理的应用程序一样，它将以同样的方式将改变企业的市场。
#2 数据库平台的作用
错误观点：内存数据库只能做一些事情，如MOLAP，运行报告，查询和分析，规划和预算编制，以及发现非结构化信息。
正确观点：SAP HANA在内存中的数据库平台是一个通用的内存数据库平台—它能带来新的数据，捕捉交易与全面的ACID兼容性，当它们发生时分析它们，做数据库处理，下放商业、预测和规划的逻辑，它服务的客户包括分析师、云计算和移动应用程序。它的主流应用远远超过了小众对数据库的理解，你并不需要添加多种技术和或将一个box中的引擎复制为不同的用途。(例： Endeca – text Essbase - planning, Times Ten - caching, analytics)。
#3 数据量增加而向外扩展与NUMA支持
错误观点：SAP HANA对数据市场和数据仓库的支持有限，因而不能向外扩展。
正确观点：SAP HANA可以扩展到无限数量的内核/节点，而硬件价格在不断下降。去年五月，在我们的SAPPHIRE NOW大会，Hasso已经使用SAP HANA展示了32个节点/ 1000+核心（在他讲话的第13分45秒）。顺便说一句，我们在世界各地已经运行了3个像这样的1000 +的核心系统。我们有多节点向外扩展系统的现场客户和几个合作伙伴，包括IBM，HP，应用范围早已向外扩展。
此外，我们最近在100TB的基准上运行了16个节点的IBM的X5服务器。每个服务器都有0.5 TB的主存，并能在业务报告情况下，使用300-500毫秒处理100TB的数据仓库，800毫秒-2秒处理临时分析查询。此外，数据可以被交换成标准的的HANA机制，如过时的查询。HANA也支持 NUMA架构。相反，在Oracle Exalytics上公共文件的限制为1 TB，他们已公开表示这方面的一个重要部分是用于放在一起的所有产品的工作内存（Essbase+Endeca+TimesTen）。
#4 OLTP & OLAP
错误观点：“SAP HANA写入性能有限。”
正确观点：对于OLTP+ OLAP而言，SAP HANA在单一硬件和单一操作系统上是一个单一的基础，它能向上和向外扩展（从小型到1000 +核心的多个节点之间），也会因工作负载而动态地调节。只有我们在内存中的数据库中插入了一个高写入性能和高分析性能的柱状存储。这是SAP HANA的一个关键的差异化。
#5 存储方式 – 行、列、文本
错误观点：SAP HANA不支持非结构化的数据，也不提供行和列的压缩。
正确观点：SAP HANA可以在一个数据库中存储行、列以及文本， 它本身就支持非结构化数据的存储。因为这些都整合在一起了，所以就简化了各个不同的存储器中的事务以及分析操作。事实上，SAP HANA就是在非结构化基础上建立起来的。它能处理在结构数据上的标准搜索、文本挖掘、以及类文本的搜索。SAP HANA中也将包含Inxight技术在语言上的功能，如标签，特征提取，实体提取和情感分析。Inxight在市场上是最好的文本分析软件。SAP HANA支持大量压缩的列存储。行存储并不需要大量压缩，因为它只被用做压缩列和不相关的表格的缓冲器而已。
＃6 数据缓存和查询优化
错误观点：SAP HANA和TimesTen都能做数据缓存。
正确观点：上一代的数据库使用缓存来提高性能。HANA是基于一个新的建筑范式上的一个纯内存数据库。既然整个数据库都在HANA中，你就不用再缓存数据。SAP HAHA有一个世界顶级的查询优化器，本身就允许大规模的平行查询执行，包括内部和外部运营的平行操作。
＃7：ACID性质和交易的完整性
错误观点：SAP HANA不具有“事务完整性/正确性”，缺乏“多版本并发控制（MVCC）”。
正确观点：SAP HANA是完全符合ACID的，我们使用永久性存储系统来保证备份和持久性。SAP HABA的并发性很完整，它有着例如语句级和快照隔离的常规功能的。
＃8：聚合和物化视图
错误观点：你需要聚合数据的物化视图取得高性能。
正确观点：又是一个！就像电动车不需要火花塞一样，内存中详细数据瞬时聚合性能高得多。聚合是过时的技术，因为需要耗费大量精力来创建，存储冗余和管理变化。 SAP HANA并不需要像传统数据库那样上性能指标，鉴于它所有的部分都存在在内存中，面对所有尺寸的数据，它能将自己的行为设置成就像一个索引一样。
＃9：商业智能客户端
错误观点：SAP HANA只对一些BI客户端提供有限的支持。
正确观点：SAP HANASAP已经优化 Business Objects的运行。此外_如今众多_第三方客户端已成为可能（如Tableau，TIbco Spotfire），我们将继续在SAP HANA上向第三方BI客户端完全开放。
#10：规划应用程序和分析功能
错误观点：SAP HANA为规划和预算编制程序提供了很有限的支持。
正确观点：SAP HANA为规划程序提供了完整的支持，有相当多的SAP企业绩效管理程序可以运行在SAP HANA上。SAP HANA在数据库中有本地规划支持 与规划引擎。类似于分解聚合、复制和其他的操作符是SAP HANA中关系代数的一部分。此外，我们支持SAP 数据库内自带的规划语言FOX。
规划是SAP HANA一个巨大的参数—而不是其他方式。SAP HANA不需要标准多维立方体（cube）操作，因为我们都是瞬时计算。SAP HANA的库包含了主要的分析和商业功能，例如数学函数、货币转换、单位转换、异动加权、时间序列分析、层次处理和预测函数，并且还对其他库提供了扩展支持。有了运行在HANA上的SAP BW，我们没有层；我们把规划计算下放到HANA数据库层来实现高性能。SAP HANA将支持所有事务应用、商业仓库、BI和所有SAP 云应用程序。我们也有第三方合作伙伴开发内置于SAP HANA中的规划应用程序。
#11：运营报表和数据源
错误观点：SAP HANA对使用复制和ETL技术的运营报表能力有限，由于“有限的数据源”。
正确观点：SAP拥有非常好的对于不同数据源（如SAP CO-PA加速器）的实时运行报表解决方案；其中很多都是非SAP程序数据源。SAP数据服务和SAP Sybase复制服务器是市场领先的ETL和复制技术，可以从非SAP和SAP数据源加载数据。HANA具有极高的插入率，由于大规模并行的批量机制，它支持所有的数据源，并且测试表明数据传入SAP HANA的速度为每小时2TB。
#12：价格
错误观点：“SAP HANA比Exalytics贵上5至50倍”。1TB HANA H/W价格为36.2万美元，SAP HANA软件收费375万美元。
正确观点：对于1TB存储，我们对H/W期望价格为40至60万美元（并非36.2万），而软件也远没有这里说的那么贵。SAP HANA也针对不同市场提供了不同的价格。
价格范围从小型业务（例如，单个H/W节点为1.2万美元+2万美元的SAP B1 Analytics ON HANA）到大于100TB内存的超大型业务场景。客户也可以为单个应用程序(BW, BPC, CO-PA, Smart Meter Analytics等) 购买SAP HANA，或者数据集市和数据仓库。对于40TB的数据仓库，BW on HANA是很有竞争力的。另外，HANA价格也包括了客户所需要的一切 – 测试、开发和QA环境环境和支持。无需为数据加载和移动、存储加速（如Exadata）购买其他软件。综上这些- 对于一个512GB使用配置，SAP HANA总价比对手产品的价格大约低50%。
#13：标准和开放性
错误观点：“HANA只能同SAP工具使用，只有有限的甚至非标准的SQL。”
正确观点：大多数客户使用HANA处理非SAP数据和用例 – 同时是SAP和非SAP应用程序的用例。工作在标准的SQL和MDX，并且对每个应用都有标准接口，对每一层都是开放的：
· 开放选择H/W供应商，在竞争对手前选择为市场带来新的芯片级的创新。
· 开放选择BI客户端。
· 开放选择所有应用程序和平台。
· 有数以百计的在SAP HANA上的自定义（非SAP）应用程序正在开发。
举个例子，Oracle应用程序和Oracle BI无需做任何改变，即可运行在SAP HANA上。已有的Oracle存储过程将因知识产权原因翻译成SQLScript，展示了SAP HANA的完全开放性。
#14：磁盘中的SAP HANA
错误观点：SAP HANA不支持数据存储至磁盘中。
正确观点：SAP HANA通过使用优先级技术，例如最近最少使用（LRU）支持数据存储磁盘。SAP HANA可以将相关数据放在内存中，而来自磁盘的数据则根据需要加载。
#15：查询速度
错误观点：SAP HAN执行查询的速度不比其他数据库快。
正确观点：SAP HANA将所有数据以整数格式列式存储，并且利用了最新的intel创新技术，如向量运算的CPU开发优化。SAP HANA下一代架构以及芯片级的创新使其快于市场上任何一家竞争对手数据库。举个例子，我们有4个客户使用了SAP HANA后，业务流程提升了10万倍。领先的是MKI，其零售、物流数据分析提升了40.8万倍。
#16：SAP HANA运行比Exadata 和 Exalytics慢。
错误观点：“SAP HANA跑的没有Exadata快，更别提Exalytics”。
正确观点：在一个客户架构的例子中，SAP HANA对信用检查和信用额度验证业务流程，使用同样数据和查询语句比Oracle Exadata快1.5万倍。该实时性能是比较了事务中多个冗余沙箱、分析、内存加速和文本处理得出的，由于在他们架构中有固有延迟。我们已经在几个客户发现了这个现象，这里只举出一个作为例子。
目前市场上的方式：
SAP HANA使用的新方式：
#17：安装和实施经历
错误观点：SAP HANA需要几天去安装，而实施则需要几月甚至几年。
正确观点：SAP HANA在数据中心安装只需几分钟至一小时。事实上，很快你就能从我们合作伙伴或者云上安装。Provimi的利润分析仅用了3个星期就上线了。
#18：考勤和差旅
错误观点：如果没有显著系统开销，数据库很难展示基于时间的报表。
正确观点：你可以使用SAP HANA对你的报表时间遍历（例如，比较实际天数和预测天数），以及比如使用滑动浏览时间轴，而报表则瞬时生成，无需存储另外的指标或者视图。
总结
我列举了这些事实，以期你能了解SAP HANA背后的真相。SAP HANA的表现打乱了原本安静的传统数据库市场，开创了集OLTP+OLAP于一个硬件和一个操作系统，可以运行在小至微型机，大至1000+内核的服务器集群中的先河。其技术定义和我们真正关心的属性交叉在一起，例如，
1. 1. 爆炸式数据量（是的，随着你的发展而调节、与磁盘存储一起工作）。
2. 2. 多结构数据（是的，包括文本和机器数据）。
3. 3. 对新鲜数据的实时分析（是的，实时）。
4. 4. 高速互动（是的，以人类思考的速度）。
5. 5. 无需调优数据库（是的，更简单更便宜）。
以上这些提供了性能上进行改进的顺序。SAP HANA通过重新改革公司的客户互动、财务和供应链性能，为全世界的公司带来了巨大商业贸易以及竞争优势。农夫山泉（Oracle数据库提升了2.2万倍性能）正在停用Oracle。
我们也在开创新的领域，例如医药行业中，重新改革基因组分析或者为全世界带来贸易和实时银行分析，以及我们这个时代的其他一些大挑战。时间正召唤我们追赶新的地平线，世界不只是过去的增加，更是我们可以创造的更美好的事物。人生苦短，我们不应被这些谣传阻止前进步伐。
- SAP Managed Tags:
1 Comment
