ColumnStore应用实践分析

　　整体架构分为计算层和存储层，都是可扩展的，计算层需由以下几项主要进程构成：

　　MariaDB（mysqld）：收集用户请求的一个SQL入口，存储元数据信息；

　　Execution Manager：解析语法树，转化成任务列表（JOB LIST），包括优化、取数据、（HASH）JOIN、汇总、分组；

　　DMLProc／DDLProc：将DML／DDL语句发送到指定的PM执行；

　　Performance Module：接受Execution Manager发送过来的任务调度，分布式扫描，（HASH）JOIN与汇总。

　　由此，我们能清晰地理解整个处理流程：MariaDB收到用户的SQL请求后，通过执行管理器将SQL转化为任务列表，再由DMLProc／DDLProc发送任务给PM，最后PM将结果返回给UM进行汇总，返回结果给客户端。

　　优势

　　存储、性能、兼容、扩展

　　为了解决在大数据统计性能上的问题，对比了Infobright和ColumnStore两种解决方案，最终选取了ColumnStore，对比如下：

　　表1 数仓方案对比表

　　1. 对于存储而言，InnoDB本身的压缩率并不高，有1倍左右。相比之下，Infobright的压缩率相对最高，有20倍之多；而ColumnStore则比较适中，为5倍左右。如果为了追求高压缩比的历史数据存档，很明显使用Infobright社区版是很好的方案。

　　2. InnoDB自身的扩展性并不高，需要外部中间件来实现分库分表，因此给予扩展性低的评价；Infobright也可以部署集群，因此扩展性给予高评分；同样ColumnStore也是易于扩展的分布式方案。

　　3. 在性能方面，InnoDB的OLTP性能远高于后两者，在数据仓库中提供在线服务，可以考虑用InnoDB来存储，但统计性能则相差甚远；由于Infobright中存在Knowledge Grid（知识网格），又使用了列式存储来压缩数据，在数据量超过内存容量的情况下，对单列的统计表现卓越，100倍性能提升就成了极轻松的事，但如果统计字段增加或多表查询，性能也就极速下降；ColumnStore不仅拥有单列高速统计的优势，而且在多表连接的场景下也表现不俗，当然字段越多性能同样会下降，但下降后的速度仍可以接受。

　　4. Infobright的社区版不支持DML，因此语法兼容性存在很大问题，对查询的支持尚佳；ColumnStore本身开源，但语法也略有不同，例如多表连接时，不能对同一个表进行多次连接，分组查询字段（SELECT COLUMN LIST）必须要在分组列表（GROUP BY LIST）中。