基于MPP数据库的存储分析方案设计

笔者在项目中曾碰到了这么一个场景：随着项目的持续使用及用户快速增长，系统的数据处理能力急剧下降，查询速度及数据计算能力让人无法忍受。原来使用的数据库是开源的mysql数据库。为了解决该问题，经过权衡比较，笔者最后决定采用MPP+ES作为该问题的解决方案。ES笔者就不介绍了，大家应该都比较熟悉。重点介绍一下MPP数据库。
MPP数据库介绍
mpp主要包括以下三种：
Vertica；
Redshift；
Greenplum
这三者其实有非常很多相同点：
1.全部基于PostgreSQL，这使得只使用关系型数据库的朋友们学习成本很低
2.都是基于列的存储(Columnar Storage)
3.操作都是以Scan为基础，依赖Compression来提供性能的优化。下面以Greenplum为例进行讲解。
Greenplum是一个关系型数据库集群，由数个独立的数据库服务组合成的逻辑数据库,采用Shared-Nothing架构，整个集群由很多个数据节点（Segment Host）和控制节点（Master Host）组成，其中每个数据节点上可以运行多个数据库。简单来说，Shared-Nothing是一个分布式的架构，每个节点相对独立。在典型的Shared-Nothing中，每一个节点上所有的资源（CPU，内存，磁盘）都是独立的，每个节点都只有全部数据的一部分，也只能使用本节点的资源。
在Greenplum中，需要存储的数据在进入数据库时，将先进行数据分布的处理工作，将一个表中的数据平均分布到每个节点上，并为每个表指定一个分发列（distribute Column），之后便根据Hash来分布数据。基于Shared-Nothing的原则，Greenplum这样处理可以充分发挥每个节点处I/O的处理能力。在这一过程中，控制节点（Master Host）将不再承担计算任务，而只负责必要的逻辑控制和客户端交互。I/O瓶颈的解决为并行计算能力的提升创造了良好的环境，所有节点服务器组成一个强大的计算平台，实现快速的海量并行运算。Greenplum在数据仓库、商业智能的应用上，尤其是在海量数据的处理方面性能极其优异。

但是，在极短的时间处理大量的并发小任务并非MPP数据库所长。Greenplum目前无法替代OLTP数据库，MPP数据库是为了解决大问题而设计的并行计算技术，而不是大量的小问题的高并发请求。

数据存储架构

各相关组件说明：
MySQL：使用MySQL存储业务基础数据、计算结果数据等规模不大的数据。
ES集群：从ES中建立索引，以提供快速全文检索功能
ETL服务：将MySQL中的原始数据按照特定业务规则模型转化为标准化数据，并存入MPP数据库
Kafka集群：当外部系统的数据量比较多，并发较大时，数据接收速度可能会受影响，使用Kafka来解决数据的高并发写入问题。
MPP数据库（Greenplum）集群：解决海量数据的存储与计算问题（ES的计算能力确实有限）。
Greenplum、MySQL、ES互为补充，Greenplum解决OLAP场景下的存储与分析需求，MySQL解决OLTP场景下的高并发写入需求，ES提供全文检索从MySQL中同步数据，三个组件协同解决业务中的不同痛点。
OK，读者朋友们，如果您遇到了数据量大、查询慢、计算慢而又不想使用Hadoop那种非关系型数据库，本方案也不失您的一个选择哦。