MySQL、HBase、ElasticSearch三者对比

MySQL&＃xff1a;关系型数据库&＃xff0c;主要面向OLTP&＃xff0c;支持事务&＃xff0c;支持二级索引&＃xff0c;支持sql&＃xff0c;支持主从、Group Replication架构模型&＃xff08;本文全部以Innodb为例&＃xff0c;不涉及别的存储引擎&＃xff09;。

HBase&＃xff1a;基于HDFS&＃xff0c;支持海量数据读写&＃xff08;尤其是写&＃xff09;&＃xff0c;支持上亿行、上百万列的&＃xff0c;面向列的分布式NoSql数据库。天然分布式&＃xff0c;主从架构&＃xff0c;不支持事务&＃xff0c;不支持二级索引&＃xff0c;不支持sql。

ElasticSearch&＃xff1a;简称ES是一款分布式的全文检索框架&＃xff0c;底层基于Lucene技术实现&＃xff0c;虽然ES也提供存储&＃xff0c;检索功能&＃xff0c;但我一直不认为ES是一款数据库&＃xff0c;但是随着ES功能越来越强大&＃xff0c;与数据库的界限也越来越模糊。分布式&＃xff0c;P2P架构&＃xff0c;但不支持事务&＃xff0c;采用倒排索引提供全文检索。

假设有这样一张人员信息表&＃xff1a;

MySQL数据库要提前定义表结构&＃xff0c;数据表共有多少列&＃xff08;属性&＃xff09;需要提前定义好&＃xff0c;并且同时需要定义好每个列所占用的存储空间。数据以行为单位组织在一起的&＃xff0c;假如某一行的某一列没有数据&＃xff0c;也需要占用存储空间。

HBase则是以列为单位存储数据&＃xff0c;每一列就是一个key-value&＃xff0c;HBase的表列&＃xff08;属性&＃xff09;不需要提前定义&＃xff0c;而且列可以动态扩展&＃xff0c;比如人员信息表中需要添加一个新的“address”字段&＃xff0c;MySQL需要提前alter表增加字段&＃xff0c;HBase可以直接插入即可。

ES比较灵活&＃xff0c;索引中的field类型可以提前定义&＃xff08;定义mapping&＃xff09;&＃xff0c;也可以不定义&＃xff0c;如果不定义&＃xff0c;会有一个默认类型&＃xff0c;不过出于可控性考虑&＃xff0c;关键字段建议提前定义好。&＃xff08;Solr中必须提前定义好schema.xml文件&＃xff09;

上图展示了数据在MySQL和HBase中存储差异&＃xff08;和真实的情况还有差距&＃xff09;&＃xff0c;可以看到即使第二条记录的sex字段为空&＃xff0c;MySQL依然会为该字段保留空间&＃xff0c;因为后续有可能会有update语句来更新该记录&＃xff0c;补上sex内容。而HBase则是把每一列都看做是一条记录&＃xff0c;row&＃43;列名作为key&＃xff0c;data作为value&＃xff0c;依次存放。假如某一行的某一个列没有数据&＃xff0c;则直接跳过该列。针对稀疏矩阵的大表&＃xff0c;HBase能大大节省存储空间。

看到这里&＃xff0c;大家是否会有一个疑问&＃xff1a;使用HBase存储时&＃xff0c;假如此时需要添加第二行的sex内容&＃xff0c;如何实现呢&＃xff0c;数据是否连续&＃xff1f;后面介绍读写流程会解释。

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

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

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

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

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

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

总结&＃xff1a;

MySQL&＃xff1a;行存储的方式比较适合OLTP业务。

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

ES&＃xff1a;ES默认对所有字段都建了索引&＃xff0c;所以比较适合复杂的检索或全文检索。