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内容，如何实现呢，数据是否连续？后面介绍读写流程会解释。

3、不一样的ES

ES的存储方式和上面两个都不一样，MySQL和HBase是将数据按不同的方式进行存储，好歹它们存的还是数据，而ES则存的是倒排索引。我们先来了解一下什么是倒排索引，以及为什么需要倒排索引（Inverted Index）：

我们肯定都会这样的经历：偶然看到一段很好的文字，但是却不知道出处，这时候去图书馆，一个一个翻找，无疑是大海捞针，这个时候便有了全文检索这项技术，而它最核心的就是倒排索引。假如有如下文档：

我们想要知道有哪些文档含有you这个关键字，首先可以创建一个倒排索引，格式如下：

前面的部分叫做dictionary（字典），里面的每个单词叫做term，后面的文档列表叫做psoting-list，list中记录了所有含有该term的文档id，两个组合起来就是一个完成的倒排索引（Inverted Index）。能够看出，假如需要查找含有“you”的文档时，根据dictionary然后找到对应的posting-list即可。

而全文检索中，创建Inverted Index是最关键也是最耗时的过程，而且真正的Inverted Index结构也远比图中展示的复杂，不仅需要对文档进行分词（ES里中文可以自定义分词器），还要计算TF-IDF，方便评分排序（当查找you时，评分决定哪个doc显示在前面，也就是所谓的搜索排名），压缩等操作。每接收一个document，ES就会将其信息更新在倒排索引中。

可以看出ES和MySQL、HBase的存储还是有很大的区别。而且ES不仅包含倒排索引，默认同时还会把文档doc存储起来，所以当我们使用ES时，也能拿到完整的文档信息，所以某种程度上，感觉就像在使用数据库一样，但是也可以配置不存储文档信息，这时只能根据查询条件得到文档id，并不能拿到完整的文档内容。

总结：

MySQL：行存储的方式比较适合OLTP业务。

HBase：列存储的方式比较适合OLAP业务，而HBase采用了列族的方式平衡了OLTP和OLAP，支持水平扩展，如果数据量比较大、对性能要求没有那么高、并且对事务没有要求的话，HBase可以考虑。

ES：ES默认对所有字段都建了索引，所以比较适合复杂的检索或全文检索。