MySQL、HBase、ElasticSearch 数据库比对
1、概念介绍
MySQL：关系型数据库，主要面向OLTP，支持事务，支持二级索引，支持sql，支持主从、Group Replication架构模型（本文全部以Innodb为例，不涉及别的存储引擎）。
HBase：基于HDFS，支持海量数据读写（尤其是写），支持上亿行、上百万列的，面向列的分布式NoSql数据库。天然分布式，主从架构，不支持事务，不支持二级索引，不支持sql。
ElasticSearch：简称ES是一款分布式的全文检索框架，底层基于Lucene技术实现，虽然ES也提供存储，检索功能，但我一直不认为ES是一款数据库，但是随着ES功能越来越强大，与数据库的界限也越来越模糊。分布式，P2P架构，但不支持事务，采用倒排索引提供全文检索。
2、数据存储方式
假设有这样一张人员信息表：
MySQL数据库要提前定义表结构，数据表共有多少列（属性）需要提前定义好，并且同时需要定义好每个列所占用的存储空间。数据以行为单位组织在一起的，假如某一行的某一列没有数据，也需要占用存储空间。
HBase则是以列为单位存储数据，每一列就是一个key-value，HBase的表列（属性）不需要提前定义，而且列可以动态扩展，比如人员信息表中需要添加一个新的“address”字段，MySQL需要提前alter表增加字段，HBase可以直接插入即可。
ES比较灵活，索引中的field类型可以提前定义（定义mapping），也可以不定义，如果不定义，会有一个默认类型，不过出于可控性考虑，关键字段建议提前定义好。（Solr中必须提前定义好schema.xml文件）
上图展示了数据在MySQL和HBase中存储差异（和真实的情况还有差距），可以看到即使第二条记录的sex字段为空，MySQL依然会为该字段保留空间，因为后续有可能会有update语句来更新该记录，补上sex内容。而HBase则是把每一列都看做是一条记录，row+列名作为key，data作为value，依次存放。假如某一行的某一个列没有数据，则直接跳过该列。针对稀疏矩阵的大表，HBase能大大节省存储空间。
看到这里，大家是否会有一个疑问：使用HBase存储时，假如此时需要添加第二行的sex内容，如何实现呢，数据是否连续？后面介绍读写流程会解释。
