论oracle不适合做数仓的N个理由

不可否认oracle是数据库界的老大，但在olap分析领域，尽管有大量的分析函数，然而并不适合做数仓，诸君莫急听我慢慢道来：

1、没有schema

准确说oracle有schema的概念，但并非真正的schema，其与用户是一一绑定的。众所周知，数仓是需要分层设计的，用不同的schema来标识ods、edw、rst等层是极其清晰的。而在oracle中放由于没有真正意义上的schema，3层用三个不同的用户总是不太方便，若放在同一用户下则无法区分，加ods_前缀又受到表面名不得超过30个字符的限制。

2、存储过程中不能ddl

olap数据分析会比较复杂，很难通过简单的几步予以实现，通过创建临时表，一步一步加工出数据不仅清晰，更有利于调试和维护，大大提升了开发效率。然而，oracle存过中不允许ddl，没法create table，只能用with结构写成很大的一团，给开发调试以及维护带来了极大的挑战。如能临时表，清晰的思路指导，每个独立步骤的简单足以让未毕业的实习生轻松hold住大项目。(尽管也能通过拼一堆字符串的动态sql绕过oracle的建表限制，但一堆字符串的拼接其可读性和可维护性可想而知)

3、性能

oracle是为oltp业务处理设计的，适合按行的业务存储和查询。对于olap这种仅需少量列大量数据量的数据分析并不适合。按列存储、按列分析，列存数据库才是olap的绝配。同时，大量的查询需要并行，这时候就该mpp数据库登场了，而greenplum是其中的佼佼者。

4、索引

像oracle等行式数据库最重要的一个优化手段就是索引，然而索引是柄双刃剑，所有的泛滥不仅带来空间的占用更影响数据的插入速度。亲眼见到业务库里单表有30到40个索引，索引人所占据的空间更是达到原表的4到5倍。设置合适的索引是需要一定技术含量的。而这些在列式数据库里通通都不是问题。列式数据库中不需要建索引，但有着每列都是索引的效果。开放难度降低，开发速度加快，更节省了索引所占据的磁盘空间。这还没有考虑列数据库强大的压缩功能，通常选择5倍的压缩率，这极大节省了数据仓库的磁盘空间，也就是节省了大量的费用。

(未完待续)