当前位置: 首页 > >

MySQL、HBase、ES的特点和区别

发布时间:

MySQL、HBase、ES的特点和区别
MySQL:关系型数据库,主要面向OLTP,支持事务,支持二级索引,支持sql,支持主从、Group Replication架构模型(本文全部以Innodb为例,不涉及别的存储引擎)。


HBase:基于HDFS,支持海量数据读写(尤其是写),支持上亿行、*偻蛄械模嫦蛄械姆植际絅oSql数据库。天然分布式,主从架构,不支持事务,不支持二级索引,不支持sql。


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


数据存储方式
假设有这样一张人员信息表:



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


不一样的ES
说完MySQL、HBase,这里要重点说一下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业务。列存储的方式比较适合OLAP业务,而HBase采用了列族的方式*衡了OLTP和OLAP,支持水*扩展,如果数据量比较大、对性能要求没有那么高、并且对事务没有要求的话,HBase也是个不错的考虑。ES默认对所有字段都建了索引,所以比较适合复杂的检索或全文检索。


容灾

数据库系统,数据的完整性和一致性是非常重要的问题,数据库进程挂了,可以恢复,但是数据丢了,就再也找不回来了。下面说说各个系统的容灾方式。


MySQL

单节点:


现在的数据库普遍采用write ahead log策略来避免数据丢失,wal机制简单的解释就是:在提交CUD操作,数据写入内存的同时,也要写一份到log文件中,而且要保证log数据落盘成功后才能向client返回操作成功,假如此时数据库宕机,已经提交到内存的数据还没来得及刷回磁盘,*羰菘夂罂梢酝ü胤舕og文件来恢复内存中的数据。


问题又来了:写log的话,对性能影响会不会很大?其实多少还是有点影响的,不过log文件是顺序写入,相对来说为了保证数据完整性,这点性能损失还是可以接受的。


单机情况下,MySQL的innodb通过redo log和checkpoint机制来保证数据的完整性。因为怕log越写越大,占用过多磁盘,而且当log特别大的时候,恢复起来也比较耗时。而checkpoint的出现就是为了解决这些问题。


checkpoint机制保证了之前的log数据一定已经刷回磁盘,当数据库宕机时,只需要将checkpoint之后的log回放即可,数据库会定时做checkpoint,这样就保证了数据库恢复的效率。


但是考虑到如果硬件故障时机器无法启动,或者磁盘故障时数据无法恢复,checkpoint+redo log方案也就不起作用了,为了防止这种故障,MySQL还提供了master-slave和group replication 集群级别的容灾方案。


Master-Slave架构主要思路是:master负责业务的读写请求,然后通过binlog复制到slave节点,这样如果主库因为不可抗拒因素无法恢复时,从库可以提供服务,这里我们用了“复制“这个词,而不是”同步“,因为基于binlog复制的方案并不能做到主从数据强一致,这种主从同步方式会导致主库挂掉之后从库有可能丢失少量的数据。


正是因为主从架构存在数据不一致的问题,所以MySQL5.7出现了Mysql Group Replication方案,mgr采用paxos协议实现了数据节点的强同步,保证了所有节点都可以写数据,并且所有节点读到的也是最新的数据。(原谅本人水*有限,说不清楚主从架构为什么会丢数据,也讲不清楚mgr是怎么实现的,但是这里强烈推荐一本前司同事的书:《MySQL运维内参》,里面详细解释了Master-Slave和Group Replication 的架构,是深入理解Mysql的不二之选,据说本书的出现拉低了DBA的门槛,没有任何打广告的嫌疑^ ^)


HBase:
HBase的容灾和MySQL的单机容灾有些类似,但具体实现上还是很有自己的特点。在介绍HBase容灾前,我们先来了解一下HBase和HDFS的关系:HBase中的数据都是存放在HDFS上,可以简单理解HBase分为两层:一层为NoSql service(即提供分布式检索服务),一层是分布式文件系统(数据真正存放的位置,目前采用HDFS)。HBase中region分布在不同的regionserver上,client端通过meta表来定位数据在在哪个regionserver的region上,然后获取数据,但是数据有可能并不一定在该regionserver本地保存,每个region都知道自己对应的数据在HDFS的哪些数据块上,最后通过访问HDFS来获取数据,尤其当HBase和HDFS部署在不同的集群上时,数据的读写完全是通过RPC来实现,为了减少RPC的开销,保证服务稳定,往往会将HBase和HDFS部署在同一个集群。同理,当一个regionserver挂了,region可以快速切换到别的regionserver上,因为只涉及到回放Log,并不会移动已经落盘的数据,而且HBase也会控制log的大小,来减少恢复时间。


HBase也是采用写log的方式防止数据丢失,数据写内存的同时,同时也会写入HLog,HLog也是存储在HDFS上,写入HLog后才会认为数据写成功,某个regionserver挂掉之后,master将故障机器上的regions调度到别的regionserver上,regionserver通过回放HLog来恢复region的数据,恢复成功后,region重新上线,由于log是直接写在HDFS上,所以不用担心单个节点挂掉log数据丢失的问题。


这里引出一个问题:回放HLog的时候,正在被恢复的region会短时间不可用,直到HLog回放成功。HBase1.0版本中加入了region replicas功能,也就是提供一个slave region,当主region挂掉的时候,依然可以通过slave replicas来读数据,但是slave不提供write,而且slave replicas和primary region并不是强同步的,并不一定总能读到最新的数据,所以开启该功能时,也要考虑自己业务是否必须要求强一致。


HBase也提供了cluster replication,目的是为了做机房级的容灾,boss说现在cluster replication功能还有些bug,目前也在积极优化改进,相信以后会cluster replication会越来越完善。


ES:
ES的容灾也是采用写log的方式,与HBase不同的是,ES的节点保存各自的log,这点跟MySQL类似,log是存放在本地的,这也就存在和MySQL一样的问题,假如机器宕机或硬盘故障,log数据也会丢失,所以index每个shard也有主备,默认配置是一个primary shard,一个replica shard,当然也可以配置多个replica。


默认情况下:primary shard首先接收client端发送过来的数据,然后将数据同步到replica shard中,当replica shard也写入成功后,才会告知client数据已正确写入,这样就防止数据还没写入replica shard时,primary挂掉导致的数据丢失。


又到了提问环节,如果有一个replica节点出了问题,比如网络故障无法写入,那岂不是数据一直写入不成功了?所以ES的master维护了一个in-sync set,里面保存了目前存活、且与primary同步的replica集合,只要set中的replica同步完成即认为数据写入成功。考虑到一种情况:所有的replica因为网络故障都下线了,in-sync set此时为空,数据只在primary中保留一份,很有可能因primary故障而导致丢数据,所以ES新增了wait_for_active_shards参数,只有当存活的replica数大于该参数时,才能正常写入,若不满足,则停止写服务。


(这是5.X版本的实现,由于ES版本更新过快,这和2.X之前的版本有些差异,5.X中in-sync set的方式和Kafka的容灾模式非常类似,但和Kafka有一点区别:ES的primary负责写服务,但是primary和replica都可以提供读服务,而Kafka只有primary partition提供读写服务,replica只是同步primary上的数据,并不提供读。具体为什么Kafka不用replica提供读服务,大家可以思考一下哈。而ES 2.X之前版本的容灾更像ZK,采用quorum的方式,如果不对请指正)


读写方式
存储方式和读写方式很大程度上决定了系统的吞吐,本节主要介绍MySQL、HBase、ES各自是如何读写数据的。


Mysql
先说说MySQL,MySQL的Innodb中的数据是按主键的顺序依次存放,主键即为聚簇索引(对聚簇索引和非聚簇索引不了解同学可以看看这篇文章),索引采用B+树结构进行组织。


转载自:https://www.jianshu.com/p/4e412f48e820



友情链接: hackchn文档网 营销文档网 爱linux网 爱行业网 时尚网