数据库-1-几种NoSQL数据库和流行的开源OLAP引擎或数据库

1 引子

当SQL满足不了你的需求或者SQL 已经不是必须的或者最佳的选择时，就是你考虑这类NoSQL 的时候了。

当你的内存大于你的数据时，schema也不是太确定时，mongodb在这里静静地等待；当你唯一追求的就是速度，又对memcached的过于简单心存芥蒂，刚好内存也比数据多时，redis俏生生站在那里；数据太大了，估计就没有选择综合症了，HBase成了唯一或者唯二选择了。

所以呢，不严谨地讲，Redis定位在"快"，HBase定位于"大",mongodb定位在"灵活"。NoSQL的优点正好就是SQL的软肋，而其弱点正好也就是SQL的杀手锏。

1.1 web应用DB伸缩性

对于web应用，无法预测系统何时会被多少人访问，用户到底有多少，今天少或许明天就变多了。本质上，这些就是事先没有确认对于web应用来说什么才是最重要的。从系统架构的角度，web应用更加看重系统性能以及伸缩性，而传统企业级应用都是比较看重数据完整性和数据安全性。回顾一下一个慢慢变大的web应用如何应对DB的伸缩。
(1)单台DB
最初人少，压力小,一台DB服务器完全可以满足要求，此时所有的应用都在一个Server里，包括web server,app server,db server。

但是随着人数增长，系统压力越来越大，此时会把web server,app server和db server分离。

(2)主从复制
随着用户量的继续增加，发现DB速度越来越慢，有时还会宕掉，此时需要给DB分担压力，Master-Salve结构应运而生。一个Master Server专门负责写操作，另外的几个Salve Server专门负责读操作，读写分离。这个时候其实主要是对读操作进行了水平扩张，通过增加多个Salve来克服查询时CPU瓶颈。

(3)垂直分区
随着用户量的爆发增长，发现Master server的写操作压力越来越大。此时只能分库，即常说的数据库“垂直切分”。比如将一些不关联的数据存放到不同的库中，分开部署，可以带走一部分的读取和写入压力。

(4)水平分区
随着数据的不断增多，数据库表中的数据变的非常大，查询效率非常低，此时需要进行“水平分区”，比如将表中的数据按照10W来划分，这样每张表不会超过10W。

综上所述，一般一个流行的web应用都会经历从单台DB，到主从复制，到垂直分区再到水平分区的过程。数据库存储水平扩张是很痛苦的一件事情，不过技术在进步，出现了非常多的NoSQL数据库，这些数据库多数都会对非结构化的数据提供透明的水平扩张能力。

1.2 几个NoSQL数据库

1.2.1 mongoDB

(1)mongodb


定位是取代关系型数据库，想当一个主流数据库。因为具有非结构化、方便扩充字段、写性能优于mysql。万事万物有利有弊，mongodb的内存型缓存内容，让其速度飞快，带来内存率多，掉电数据问题等，加上自身代码还有很多bug带来不如老牌关系型数据库稳定，特别是在主从等分布式环境，其设计也带来诸多问题。

1.2.2 redis

(2)redis


是一个小而美的数据库，主要用在key-value 的内存缓存，读写性能极佳，list，set，hash等几种简单结构使得使用也很简单。缓存与简单是其定位，分布式redis架构的出现，让redis更加广泛的使用，稳坐缓存第一把交椅。

1.2.3 HBase

(3)hbase
定位非结构化大数据，可伸缩性好，并不是完全高可用，底层依靠hadoop提供的HDFS，使用时有一整套zookeeper，pig，hive的生态系统。Cassandra可以算一个竞争对手，但Cassandra去中心化的自适应结构又跟Hbase中心化的生态系统完全不同。

总结一句：在一般使用情况下，mongodb可以当作简单场景下的但是性能高数倍的MySQL, Redis基本只会用来做缓存，HBase用来做离线计算。

2 hbase

面向行存储，RDBMS即此种类型，面向行存储的数据库主要适合于事务性要求严格场合，或者说面向行存储的存储系统适合OLTP。根据CAP理论，传统的RDBMS，为了实现强一致性，通过严格的ACID事务来进行同步，这就造成了系统的可用性和伸缩性大大折扣。

目前很多NoSQL产品，包括Hbase，它们都是一种最终一致性的系统，它们为了高的可用性牺牲了一部分的一致性。Hbase,Casandra,Bigtable都属于面向列存储的分布式存储系统。Hbase是一个面向列存储的分布式存储系统，它的优点在于可以实现高性能的并发读写操作，同时Hbase还会对数据进行透明的切分，这样就使得存储本身具有了水平伸缩性。

Hbase的优点
(1)列的可以动态增加，并且列为空就不存储数据,节省存储空间;
(2) Hbase自动切分数据，使得数据存储自动具有水平scalability;HBase中的数据表会自动分裂，存入合适的RegionServer上。
(3) Hbase可以提供高并发读写操作的支持。
Hbase的缺点
(1)不能支持条件查询，只支持按照Row key来查询;
(2)暂时不能支持Master server的故障切换,当Master宕机后,整个存储系统就会挂掉。

2.1 Hbase数据模型

在Hbase里面有两个主要的概念：Row key,Column Family。
(1)Column family
Column family中文又名“列族”，Column family是在系统启动之前预先定义好的，每一个Column Family都可以根据“限定符”有多个column。

假如系统中有一个student表，若按传统的RDBMS，student表中的列是固定的，比如schema 定义了name,age,sex等属性，student的属性是不能动态增加的。但是如果采用列存储系统，比如Hbase，那么我们可以定义student表，然后定义info 列族，student的数据可以分为：info:name = zhangsan,info:age=30,info:sex=male等，如果以后又想增加另外的属性，这样很方便只需要info:newProperty就可以了。

关系数据库会造成一些为null的单元浪费，而列存储就不会出现这个问题。在Hbase里，如果每一个column 单元没有值，为空的列是不存储的，那么是不占用空间的。

采用Hbase的这种方式，还有一个非常重要的好处就是表会自动切分，当表中的数据超过某一个阀值以后，Hbase会自动切分数据，如此查询就具有了伸缩性，而再加上Hbase的弱事务性的特性，对Hbase的写入操作也将变得非常快。

(2)Row key
可以理解row key为RDBMS中的某一个行的主键，但是因为Hbase不支持条件查询以及Order by等查询，因此Row key的设计就要根据个人系统的查询需求来设计，同时因为Hbase中的记录是按照rowkey来排序的，这样就使得查询变得非常快。

2.2 Hbase与RDBMS区别

(1)关系型数据库
传统关系型数据库(mysql，oracle)数据存储方式主要如下：把每条记录分成3部分: 主键、记录属性、索引字段。会对索引字段建立索引，达到二级索引的效果。随着业务的发展，查询条件越来越复杂，需要更多的索引字段，且很多值都不存在，查询性能越来越低，甚至无法满足查询要求。
(2)列族数据库
把数据从mysql迁到hbase。
(2-1)最初的方式
存储的方式还是跟上图一样，主键作为rowkey，其他各个字段的数据，存储在一个列族下的不同列。但是想对索引字段筛选查询就没有办法。
(2-2)升级的方式
把各个索引字段的值作为rowkey，然后把记录的主键和属性值按照一定顺序存在对应rowkey的value里。
但是上面只适合单个索引字段的查询。如果要同时对多个索引字段查询，上图的方式需要求取出所有value值。比如查询“浙江”and“手机”，需要取出两个value，再解析出各自的主键求交。如果每条记录的属性有上百个，对性能影响很大。
(2-3)进化的方式
解决多索引字段查询的问题。将主键字段和属性字段分开存储，储存在不同的列族下，多索引查询只需要取出列族1下的数据，再去最小集合的列族2里取得想要的值。

为什么是不同列族，而不是一个列族下的两个列？
列族数据库数据文件是按照列族分的。在取数据时，都会把一个列族的所有列数据都取出来，事实上我们并不需要把记录明细取出来，所以把这部分数据放到了另一个列族下。接下来是对列族2扩展，列族2储存更多的列，用来做各种刷选、计算处理。

3 流行的开源OLAP引擎或数据库

Impala,Presto,SparkSQL,HAWQ都是内存式引擎，本身不存储数据。GreenPlum,ClickHouse都是DBMS，有自己的数据存储机制。

3.1 Impala

(1)Impala
Impala: 目前我们正在使用的内存引擎，CDH力推，与hive共享metadata。
优点是快，
缺点是容易爆内存，不支持update/delete（OLAP的通病），不支持ORC格式，UDF不支持SQL编写。不支持PLSQL(hive2后有hplsql)但默认是MR引擎，在impala中不能用。

3.2 Presto

(2)Presto
Presto: 优点是快，跨数据源查询，支持标准SQL。

3.3 SparkSQL

(3)SparkSQL
SparkSQL: 优点是稳定，适合跑批，对ORC，parquet格式有原生支持，UDF使用方便。缺点是对JVM的实际使用内存过高，且不同的spark app之间缺乏有效的共享内存机制， 之前调查过Tachyon 和ignite，都是可以实现spark的共享式RDD。

3.4 HAWQ

(4)HAWQ
HAWQ: 全名(hadoop with query)hadoop自家出的大数据平台MPP架构的内存式分布式引擎，设计之初参考Greenplum，早期叫GOH(greenplum on hadoop)，对Hive/hbase/hdfs有原生的支持，速度快，支持全语言的UDF编写(包含SQL)，符合TPC-DS规格(完全兼容SQL标准)，支持窗口函数和高级聚合函数，支持kerberos对表级别的权限控制。线性扩展。但现在CDH和HDP合并之后对HAWQ兼容性不能保证，因此未来不太看好。

3.5 GreenPlum-MPP架构

(5)GreenPlum
GreenPlum: MPP架构的开源产品。

3.6 ClickHouse-MPP架构

(6)ClickHouse
ClickHouse: MPP架构开源产品。

4 MPP架构

MPP (Massively Parallel Processing)，即大规模并行处理，在数据库非共享集群中，每个节点都有独立的磁盘存储系统和内存系统，业务数据根据数据库模型和应用特点划分到各个节点上，每台数据节点通过专用网络或者商业通用网络互相连接，彼此协同计算，作为整体提供数据库服务。非共享数据库集群有完全的可伸缩性、高可用、高性能、优秀的性价比、资源共享等优势。

简单来说，MPP是将任务并行的分散到多个服务器和节点上，在每个节点上计算完成后，将各自部分的结果汇总在一起得到最终的结果(与Hadoop相似)。

MPP本质上是（基于）数据库，基于传数据库并区别于传统单节点数据库，支持多节点分布式存储和计算。

（传统的单节点不属于集群，双机热备或Oracle RAC等，均是基于共享存储的）

4.1 MPP与Oracle RAC

(1)Oracle RAC是基于(网络)共享存储的。

RAC是real application clusters的缩写，译为“实时应用集群”， 是Oracle新版数据库中采用的一项新技术，是高可用性的一种，也是Oracle数据库支持网格计算环境的核心技术。

(2)MPP是各节点分别带计算(有cpu和内存)和存储(有磁盘)的。

4.2 MPP与Hadoop

谈到MPP，就要提及Hadoop。
MPPDB与Hadoop都是将运算分布到节点中独立运算后进行结果合并(分布式计算)，但由于依据的理论和采用的技术路线不同而有各自的优缺点和适用范围。

MPP应该是传统数据库方案/厂商升级转型的产物；
Hadoop是Google开源后形成的另一条技术路线的产物。

两种技术以及传统数据库技术的对比如下：

4.3 OLTP和OLAP

数据处理大致可以分成两大类：
OLTP（On-line transaction processing）：在线事务处理/联机事务处理。
OLAP（On-Line Analytical Processing）: 在线分析处理/联机分析处理。

OLTP是传统的关系型数据库的主要应用，主要是基本的、日常的事务处理，例如银行交易。

OLAP是数据仓库系统的主要应用，支持复杂的分析操作，侧重决策支持，并且提供直观易懂的查询结果。

OLTP 系统强调数据库内存效率，强调内存各种指标的命令率，强调绑定变量，强调并发操作；

OLAP 系统则强调数据分析，强调SQL执行市场，强调磁盘I/O，强调分区等。

OLTP与OLAP之间的比较：

OLTP和OLAP在实际场景中的应用：
传统的INSERT、Update、DELETE等都属于OLTP，主要是涉及事务处理；
SELECT中的count(*)、MAX()、MIN()、Group By、Order By等函数都属于OLAP的范畴。

总的来说，先有OLTP，然后才发展OLAP。目前主流的关系型数据库（Oracle、SQLServer、MySQL等均同时具有两者的特征。