olap的mysql现状

之前,在逛CU的MySQL和pgsql版时，看到有人辛辛苦苦地把二者的特性进行了对比，笔者觉得，其实我们或许应该从应用场景上进行比较。在数据库的应用场景上，无非要解决两类问题：OLAP和OLTP。

目前，在国内使用开源数据库方面走得比较靠前的就是淘宝了。淘宝在轰轰烈烈的去IOE活动中，一举消灭了三座大山，以低廉的硬件成本和稳定的mysql分支，以及TDDL这样的sharding工具做支撑，获得了OLTP上几乎无限的扩展能力。个人认为，其中的主要原因，从业务的角度看，很多业务之涉及简单的单表操作，业务相对简单，采用TDDL路由来访问单表表，就可以解决大部分问题；从mysql自身特点看来，采用线程这样的轻量级单位作为服务，可以能高并发的解决简单的业务；另外，需要指出的是，之所以采用mysql，一个很重要的原因是，在国内，mysql远远比pgsql或是其他开源数据库普及，形成了比较完整的生态链，从数据库kernel开发（少量），开发众多，DBA也不少，都很齐全，做到几乎全方位的技术支持。

但是，话说回来，在OLAP领域，其实，pgsql会占据较大的主动。首先，从目前前沿的数据仓库技术方案看来，很多都采用了pgsql的技术，（当然，不是直接拿来做DW）。例如，greenplum，采用了层次的架构，底层采用了pgsql作为数据节点，存储表的水平分片；而上层将sql作为输入，分解之后下推到各个数据节点，在各个节点完成子sql之后，将结果返回给上层，最终上层经过进一步的汇总处理后，返回结果给用户。（是不是感觉很像mapreduce的框架？）和greenplum类似，其中aster data 以及hadoopDB都采用了类似的方案，来构建PB级别的数据仓库。而从性能上看来，见（http://www.slideshare.net/miguelinlas3/hadoopdb）,这类架构的并行分布式数据仓库，从扩展能力和Hadoop相当，但是但节点上效率保持了原有数据库的高效率，所以处理大量结构化的数据时，效率会远胜过hadoop之类粗糙的数据处理工具。正是看到了这种方案的强大潜力，aster data被老牌的teradata收购；而hadoopDB的作者直接创业，估计还是围着hadoopDB来转。

从这些前沿的数据处理平台的技术方案看来，统一选择了pgsql而不是mysql，主要的原因，或许pgsql的确在某些地方胜过了mysql。从技术的先进性上看，pgsql实现了众多的查询优化处理，例如对复杂子查询的处理能力，而在mysql中，经常DBA需要去调节涉及到子查询的SQL，因为mysql的处理子查询在某些方面太弱，很多时候涉及到子查询时，会选择错误的子结果集作为驱动表，这样无疑会将查询的复杂度增大许多，很多时候会达到一个数量级。

另外，前面提到，pgsql采用了进程来作为服务的单位，而mysql采用了线程，从实现的角度来看，进程比线程更适合处理大数据，因为进程的堆空间更大，而并发的线程直接共享了一个堆，一旦数据库中存在bug（没有人敢保证没有这样的错误），那么数据量越大的时候，越容易出现，一旦出现，就是segment error了，对于线程来说，基本上一个线程出错，整个mysqld进程就只能core dump了。而对于pgsql来说，postgres进程就算出现这种错误,也只是单个postgres崩溃，而postmaster还是可以继续进行服务的。当然，一旦有postgres进程崩溃，会有相应的辅助进程来清理异常，保证数据库的健康。

以上，纯属个人观点，欢迎来拍。