众所周知，ORACLE是行存储数据库。行存储数据库适合oltp系统，早期的数据库(包括ORACLE)就是为了oltp系统而设计。
随着互联网时代的到来，技术的发展，企业并不满足于联机事物处理，需要对历史销售数据进行对比，环比分析，以帮助企业进行战略决策，于是就产生了OLAP系统。
由于传统的数据库是行存储，在不建立索引的情况下，访问表中某一个列，需要扫描所有列，为了解决该问题，我们不得不在该列创建索引，使索引当表用。如果要访问多个列，需要把这些列组合起来，创建组合索引。这样就导致表上索引过多，数据加载变慢，无法实现实时数据分析。于是列存储数据库应运而生。列存储数据库不需要创建额外的索引(其实列存储数据库里面，每个列自己维护了许多索引，如典型的sybase iq)，因为扫描数据本身就是按照列扫描的。列存储是为了OLAP而生，所以它并不支持OLTP，不支持并发DML。要想发挥列存储数据库的优势，需要底层配合SHARE DISK 架构分散IO。基于SHARE DISK 架构，业务设计，表设计必须谨慎，一旦表设计不好，查询SQL的时候，就会引起数据重新分布。比如SELECT ... FROM A,B WHERE A.ID=B.ID，A,B分别根据ID进行数据分布，因为分布键一样，A和B可以在同一个节点进行关联。但是这个时候如果来了一条SELECT ... FROM A,C WHERE A.XX=C.XX，因为A是根据ID进行数据分布的，那么A跟C进行关联，要么A重新进行数据分布，要么C从新进行数据分布。当然了如果A,C其中一个表很小，那么小表可以分发到各个节点，不需要从新分布(这个类似ORACLE的并行hash 技术 broadcast)。如果A或者C都比较大，分发不可行，必须对其中一个表(相对小的表)进行扫描，然后根据连接列进行从新分布，然后再关联。那么意思就是这个表要读2次。随着业务的复杂度提升，如果业务太复杂，列存储+SHARE DISK架构其实并不能解决OLAP性能问题。如果说ORACLE可以解决一切OLTP问题，那么列存储+SHARE DISK不能解决一切的OLAP问题，并且它还不能用于OLTP+OLAP混合型系统。如果非得用列存储+SHARE DISK 解决方案，需要在表设计，业务设计的时候，尽量的融合所有业务到一个表，减少表关联，防止数据从新分布，但是复杂的业务，你懂的，不现实，并且并不是每个设计人员都出类拔萃。或许是看到了列存储+SHARE DISK 架构的不足，甲骨文推出了EXADATA一体机，SAP推出了HANA内存计算一体机。EXADATA起初是为了OLAP而设计，当然了它本来就支持OLTP，但是如果你用EXADATA来做纯OLTP应用，那就是大财小用了，完全可以用相同的价格，实现比EXADATA一体机更好的OLTP性能。个人的理解，EXADATA最适合OLTP+OLAP混合性应用。SAP HANA起初是为了纯OLAP而设计，现在也支持OLTP。EXADATA在于SAP HANA pk 的时候，完全不占优势。为此我们这些ORACLE DBA还是比较郁闷的。
ORACLE 12C 一个新功能， IN MEMORY OPTION ,可以以列存储的格式，在内存缓存表/表分区，并且提供2--10倍的压缩。比如一个表100G，在内存中按照列压缩，耗费内存20G--30G左右。对于OLAP分析型应用，典型的只需要分析最近几个月数据，可以缓存最近几个月数据在内存，而且耗费内存并不多。这大大的提升了ORACLE查询性能。在12c中，如果使用了IN MEMORY OPTION，甚至不需要添加额外的索引，对于某些需要优化的SQL不需要额外的改写，也能获得高性能。比如本人的2个优化案例，如果使用了
IN MEMORY OPTION ，都不需要进行 SQL 改写 ，案例连接如下：
http://blog.csdn.net/robinson1988/article/details/8860026
http://blog.csdn.net/robinson1988/article/details/6953019
一直都认为ORACLE会给出列存储方案，没想到是EXADATA的smart scan ，更没想到是 in memory option，利用in memory option，ORACLE也终于可以跟SAP HANA 正式的pk了，在犹豫是否使用oracle作为olap解决方案的公司也许不会选择列存储+shared disk 架构，ORACLE依然是目前世界上最先进的数据库，而且oltp,olap通吃。
