SAP对阵老牌巨头
请不要误会：甲骨文、IBM以及微软所给出的承诺与SAP的宏伟理想可谓大相径庭。正如前面所说，三大巨头的原则性立场就是避免中断现象，因为他们的愿望是在挽留现有数据库客户的同时实现业务扩展。
SAP并不打算保护原有数据库以及数据管理基础设施，因此他们鼓励企业用户通过摆脱数据库以及其它“多余”基础设施的方式实现“彻底简化”。SAP方案的定位在于，通过在HANA内存内机制中同时运行事务型以及分析型应用程序，帮助企业用户摆脱数据仓库、中间件、应用程序服务器基础设施等传统方案，同时告别数据聚集以及其它与磁盘I/O瓶颈紧密相关的数据副本机制。
IBM、微软与甲骨文则不主张用户脱离任何数据库或者数据仓库机制——我们只需升级至其最新产品版本，即可享受到新增的内置内存技术。更重要的是，他们还针对事务型及分析型工作负载推出了多种独立产品，这就迫使用户不得不持有更多数据副本并购买更多相关许可。
IBM的BLU加速方案专门针对分析工作，但IBM同时也推出了全闪存存储阵列、旨在消除磁盘I/O瓶颈给传统应用程序及数据库性能带来的局限。虽然闪存在速度上无法与内存比肩，但至少比磁盘快得多。IBM表示这些阵列的使用成本要远低于购置额外的内存数据库技术，而且其事务处理时间缩减效果也能达到最高九成的水平。
微软为Excel带来了PowerPivot与PowerView两款插件，作为对内存内分析方案的回应;不过这类客户端方案由于采用独立的数据模型与用户间彼此不同的信息版本而有可能产生分离孤岛。
甲骨文在内存内分析性能提升问题上给出的答案是Exalytics，但这款缓存设备与其Exadata产品存在功能交集，不仅会带来更多数据副本、同时也迫使用户必须购买TimesTen或者Essbase内存数据库许可。Oracle Database 12c所提供的内存内选项可能要到明年年初才会正式与广大用户见面。
SAP的HANA平台从理论角度看更纯粹也更简洁，但我们目前还没有看到关于“彻底简化”效果的更多有力证据。据我们了解，SAP是惟一一家几乎将其全部应用程序运行在该平台上的厂商。除SAP之外，我们在采访以及相关资料阅读中发现其它厂商都只挑选了一部分应用来支持HANA。
举例来说，Avon Cycles将其Business Suite运行在HANA之上;但他们同时表示不会着手进行Business Warehouse迁移，除非确保其能够复制所有商务智能查询与报告数据——毕竟这些数据是多年经营积累所得。可以看到，查询与报告机制往往需要与聚集、物化视图、多维数据集以及其它历史遗留机制相结合，因此用户不可能在实现报表与查询数据重构之前就以“彻底简化”的方式转向内存内平台。
Maple Leaf Foods目前正在将分析型业务规划及合并应用程序从甲骨文环境迁移至HANA平台，但他们也还没有作好将整套SAP数据仓库转向HANA的打算。目前相对数据仓库这一主体，HANA平台扮演的仍然只是摩托车上的跨斗角色、属于附加机制。“我们只会对能够创造价值的数据进行加速处理，因此我们精心挑选了能够交给跨斗打理的对应数据——具体数据量可能是一年、两年或者三年，”Maple Leaf Foods公司信息解决方案副总裁Michael Correa表示。“我们也审视了将CRM运行在HANA之上的可行性，并对把整套Business Suite迁移到HANA平台很有兴趣——但至少在未来几年内，对这些机制进行加速或者简化还不是我们的首要技术目标。”
大部分企业用户都将遵循上述思路，他们提出的问题也相当尖锐：高速流程会带来哪些成本与风险?这种变更又是否能切实带来更低的使用成本与更高的运营收益?IT部门需要用一个又一个实例、一项又一项功能来回答这些问题。请注意，这些内存内方案往往要求用户将供应商软件升级至最新版本，无论SAP BW或者Business Suite、IBM DB2、微软SQL Server还是Oracle Database皆是如此。单单升级这一笔开销就会逼退很多跃跃欲试的企业客户。因此，预计内置内存技术市场的份额之争将在2014年持续升温，但真正的大决战恐怕要在几年之后才会真正打响。
