成为一个“Real-Time Enterprise”并不需要将整个数据库放在内存当中，如果你是Oracle Database的用户，并且购买了最新的Oracle Database In-Memory Option(甲骨文数据库内存计算选件)。

具体来说，实现的步骤有三步：

1、配置内存中列存储的容量;

2、将表或分区加入列存储中;

3、删除分析型索引，提升OLTP性能

按照甲骨文公司数据库技术产品执行副总裁Andrew Mendelsohn的说法，甲骨文数据库内存计算选件避免了企业用户及开发者的“选择性牺牲”和“硬件成本的提升”。他很直接的表示，对于其他的数据库供应商来说，内存计算的成本和复杂度都较高，而且会造成用户在不同业务领域使用数据库时的锁定。

很显然，Andrew Mendelsohn的矛头直指在内存计算(In-Memory Computing)市场风头强劲的竞争友商SAP及其SAP HANA内存计算解决方案。他认为，在内存计算市场，或者说在内存计算技术解决方案的应用上，“企业用户存在着一定的误区”，只有甲骨文公司能够改变这一切。

TB级内存的内存计算无法普及

在“Wintel(Windows+Intel)”时代，软件开发商和硬件供应商被认为是“沆瀣一气”的，随着软件功能的多样化以及特性的提升，需要更好的硬件来支持，似乎是一条必然的定理。

同样的思路也存在于内存计算领域。2014年初，英特尔发布最新一代面向关键业务及实时计算的至强E7 v2处理器，四插槽和八插槽系统的内存容量高达6TB及12TB，成为当今单一系统内Scale-up最高的内存容量，这被认为是为了顺应内存计算这一重要的实时计算实现方式，特别是在大数据时代。

问题在于，实现这一大容量单一系统内存硬件架构的成本十分昂贵，甚至是不现实的：内存的价格十分昂贵，尤其是面向关键业务服务器平台的内存，为了达到最大的内存容量，单条32GB内存是必须的，但其价格并不是16GB内存的2倍或8GB内存条的4倍，而是更高。

即便是为了关键业务系统或是实时的大数据内存计算，企业CIO也无法承受四路或八路服务器平台通过32GB单条内存满配的成本。

因此，在相当长的一段时间内，内存计算被认为是“昂贵且无法普遍使用的”。虽然SAP HANA在市场上的声音很多，IBM、惠普、戴尔相继认证了SAP HANA系统平台，但整体来看，内存计算市场更像是一个阳春白雪的“金字塔尖”：要知道，2012年3月前的6个月中，SAP HANA In-Memory系统虽然从200个客户手中获得了两亿美元的营收，但平均每个客户的成本高达100万美元。

甲骨文也同样推出了Exalytics In-Memory系统，并行执行TimesTen和Essbase数据库，是一个类似SAP HANA的“将整个数据库全部放入内存”的内存计算系统，但价格同样高昂：根据2012年媒体披露的信息，Exalytics硬件价格为13.5万美元。

对于用户遍布全球各行各业的Oracle Database来说，在其上实现通用性更强、价格更加便宜、易用性更好以及与现有系统融合更充分的内存计算系统，如果采取类似的实现方式，“内存计算可能永远也无法普及”。

内存计算应保持轻量级和普适性

“我们看到许多其他的内存数据库的产品，都需要购买很多内存，(但甲骨文的内存计算)可以选择在表、分区等不同的级别容量上购买内存。”Andrew Mendelsohn表示，内存计算不应成为企业的硬件负担，甲骨文认为，它应当能够基于现有的IT基础设施和投资具备内存计算的能力，适应所有的工业化的、主流的标准硬件设备。

“你不需要选择或是等待需要经过(内存计算方案)认证的硬件平台。” Andrew Mendelsohn此言直指不断发布“XXX服务器经过SAP HANA认证”的竞争对手解决方案。

“适应所有主流硬件平台”的Oracle Database In-Memory Option并非也只能运行在标准硬件上(在采访时，甲骨文公司验证了其在双插槽服务器上的惊人效率)——企业间也存在着“贫富差距”——Oracle M6-32 大内存机(Oracle M6-32 Big Memory Machine)是适合Oracle Database In-Memory的、最强大的纵向扩展平台，提供多达32TB DRAM内存和3TB/秒内存带宽，最大限度地提高了内存性能。

此外，Oracle Database In-Memory Option可以在大型SMP服务器上纵向扩展、跨服务器集群的横向扩展以及存储分层(将内存访问、闪存优化以及磁盘存储进行分层，将活跃度较低的数据转移到闪存和磁盘中)，来进一步提高系统的运行效率、降低成本。

列式数据库非常重要 但只在内存里即可

列式数据库——或者说是数据库格式——是内存计技术的另一个关键点，但在一般场景中，传统的行式数据库和列式数据库是不能够共存的：“对于企业用户或开发者来说，必须做出选择，或者说是牺牲。” Andrew Mendelsohn表示。

“过去从来没有人尝试过混合两种格式进行应用，它们都是在独立的(环境中)应用。甲骨文则把列式数据库引入了传统的甲骨文行式数据库，进一步引入了Oracle Database In-Memory Option。对于其他的数据库产品，在你写(创建)一个表时，就要决定是行式还是列式，也就是决定了把这个表用来做什么，应用开发者必须要在最初做出决定：为交易型应用优化还是分析型应用。”

在企业应用中，行式数据库和列式数据库有着不同的用途：

· 交易型应用在行式数据库中更快，比如电子商务类的应用。主要的操作是插入或查询一条信息(比如销售订单)，在访问少量行，大量列时更快。

· 列式数据库则主要被用来进行分析，更适合统计分析型应用，比如按照地域生成销售额报告，与行式数据库相反，其在访问大量行，少量列数据时会更快。

但内存计算的一大重要目的，就是实现在线数据的实时分析，由行式数据库(在线交易系统)到列式数据库(近线分析平台)的路径延迟、复杂度都会减损实时在线分析的效果和响应速度，并意味着应用开发及数据库建立时的双重工作。

Andrew Mendelsohn谈到，甲骨文的创新在于“同一张表在内存中同时支持行和列两种格式，同时激活并保持事务一致性”：分析和报表使用新的内存列格式，OLTP使用久经考验的行格式。但他也表示，甲骨文采用的是“内存列式存储技术”，也就是纯内存中的列格式存储，而非对速度较慢的磁盘也做出改变。

“Oracle内存列式存储技术无需持久化、无需记录日志，能够快速响应数据变化。” Andrew Mendelsohn认为，列式数据格式是为了分析，而不是为了业务运营，需要的是快速响应数据变化而不是将至持久化，“纯内存中的列式存储能够快速响应数据变化，且可达到2倍至20倍的压缩比例，其粒度还支持表级与分区级”。此外，纯内存格式不改变Oracle的存储格式、日志、备份或是恢复。

据甲骨文方面资料显示，在测试当中，列格式的每CPU内核可达到10亿条/秒的扫描速度，而行格式仅能达到百万条，性能的提升高达一百倍以上。不仅如此，通过将多表的连接操作转化为高效的列扫描，表连接速度也加快10倍。

对很多企业来说，内存计算现阶段还不是“一场数据与业务的变革”，更多的是锦上添花——一张报表不需要等待1天、1小时，只需要几分钟——甲骨文必须解决一个问题：不能够对现有的业务产生影响，更要延续原本在甲骨文生态环境上用户熟悉的生态环境。

Andrew Mendelsohn给出了答案。

混合工作负载 延续生态环境

“关键是不用牺牲在线交易型应用的性能，要同时兼顾两种不同的应用。”在Andrew Mendelsohn所给出甲骨文内存计算“三步操作”中最后一步是“删除分析型索引，提升OLTP性能”，这也是Oracle Database In-Memory Option对现有在线业务系统最有利的一部分。

传统OLTP系统为了实现快速查询，往往在数据库中建立分析型索引，在这样的架构下，向表中插入一条记录需要同时更新数十个索引，OLTP系统性能被迫降低。然而，通过用列存储取代分析型索引，新的OLTP系统中可以给予任意一列实现快速分析，OLTP和批处理的速度得到提升。

“关系型数据库中的分析索引只是为了分析，仅仅加速了定制查询和报表，而每次修改或插入数据条目，还都需要同时更新10-20个分析型索引，速度很慢。” Andrew Mendelsohn表示，列式存储可以基于任何一列实现快速分析，让数据库减少甚至删除分析型索引，也就不必在插入和修改时再去顾及索引的修改，这能够帮助OLTP和批处理速度更快。

他认为，与OLTP的速度提升同样关键的是，在同一个关系型数据库中，OLTP的速度和实时分析的速度都加快了，能够实现混合型工作负载，而不是互相分隔、互相独立的系统，在Thales-Raytheon Systems公司，Oracle Database In-Memory Option“允许我们将近一半的索引从支撑混合负载的大型数据库中删除，在提升复杂查询速度的同时，加快了OLTP业务操作的性能。”该公司的软件工程师Andrew Zitelli表示。

此外，Oracle Database In-Memory在任何与Oracle数据库兼容的现有应用环境中，都能够非常简单、快捷地进行部署。测试结果显示，包括Oracle电子商务套件、Oracle JD Edwards、Oracle PeopleSoft、Oracle Siebel和Oracle融合应用等在内的一系列应用都可以获得1000倍以上的性能提升。

与云计算市场的战略一样，Oracle Database In-Memory同样延续了整个甲骨文生态环境上的各项能力，包括Oracle Exadata数据库云服务器和Oracle SuperCluster在内的Oracle集成系统针对Oracle Database In-Memory进行了优化;透明支持所有甲骨文高可用性方案，比如Oracle RAC或是Oracle Data Guard;Oracle集成系统的内存容错功能同样也可以使用，它可以被用来跨多个节点选择性地复制内存数据;Direct-to-Wire Infiniband则提高了内存的横向扩展速度。

Oracle Database In-Memory Option对企业来说是一项不错的技术，从目前掌握的信息来看，它更简单易用、成本较低、系统利用率更好，以对现有系统最小的改造工作量，保证了“即刻”可得的实时(内存)计算。

但不可否认，SAP HANA在市场上的声音更强，前期市场铺垫和现在的业务认知度更高，而从下面的文档可以看出，甲骨文确实将Oracle Database In-Memory Option的主要竞争对手瞄准了SAP HANA。

　　点击下载Oracle与SAP内存计算对比文档

这不会是一场有最终赢家的市场竞争，在不同的企业、不同的环境和不同的需求下，甲骨文和SAP可能一样好，但如果我们将云计算、SaaS、数据库市场、硬件平台等多种因素考虑在一起的话，甲骨文的胜算则高出了SAP。