Hbase+ES和MongoDB存储大数据的选用

1 需求

解决海量数据的存储,并且能够实现海量数据的秒级查询
Hbase是典型的nosql,是一种构建在HDFS之上的分布式、面向列的存储系统,在需要的时候可以进行实时的大规模数据集的读写操作;但是hbase的语法非常固话,即便在hbase之上嫁接了phoneix在应对复杂查询的时候,仍然力不从心;

所以说很多公司在历史遗留问题,最开始数据存储在hbase上,当业务越来越复杂,数据量越来越大的时候,使用hbase构建复杂的查询就很吃力了,甚至很多指标无法完成;

这个时候,我们就是用elasticsearch架构在hbase之上;

海量的数据存储使用hbase,数据的即席查询(快速检索)使用elasticsearch

通过elasticsearch+hbase就可以做到海量数据的复杂查询;

在操作之前,我们还要考虑:一批数据在elasticsearch中构建索引的时候,针对每一个字段要分析是否存储和是否构建索引

ES+Hbase的话,公司的使用是将ES的索引就行和实体类就行一个索引映射,然后用一个封装好的服务之后推入索引库中数据,具体还没研究不是很清楚,这种框架类的东西会用就行了,问题也不大,因为以前写的话,是自己从数据库查询数据做一个批量导入,应该原理上是一样的,之后就是通过es的索引支持然后查询Hbase,这里我想应该是es充当hbase的索引进行查询,我们以前的是用的mongodb是支持10亿级别数据再往上就不行了,hbase支持百亿数据,这里hbase并且能够实现海量数据的秒级查询,我查询了一下hbase的语法非常固话,即便在hbase之上嫁接了phoneix在应对复杂查询的时候,仍然力不从心,当业务越来越复杂,数据量越来越大的时候,使用hbase构建复杂的查询就很吃力了,甚至很多指标无法完成,所以这个es起了关键性因素

实际应用:先ES根据条件查询到分页数据,或者是list里面封装的是那个所有实体类、然后遍历,通过遍历到的id去查hbase,之后就可以封装Dto,然后返回List

2 架构设计

img

3 HBase和MongoDB的区别

Mongodb用于存储非结构化数据,尤其擅长存储json格式的数据。存储的量大概在10亿级别,再往上性能就下降了,除非另外分库。
Hbase是架构在hdfs上的列式存储,擅长rowkey的快速查询,但模糊匹配查询(其实是前模糊或全模糊)不擅长,但存储的量可以达到百亿甚至以上,比mongodb的存储量大多了。

原因就在于写入的速度,hbase由于只维护一个主键,写入的速度要比mongodb这种要维护所有索引的数据库快多了。hbase占用两台机器能完成的事情,mongodb要占用更多的机器,每台机器按一年20000的费用,几百台下来就是一笔很大的费用。但是代价就是hbase记录下东西以后,只能事后通过全表检索或按照索引范围的方式进行整体分析,而不能对具体每个人的数据进行实时分析,更强调数据分析能力而不是实时数据查询能力,因此各有千秋吧。像用户行为分析的这种,一开始产品经理可能会具体看某一个人的数据,但是新鲜过后,只会看程序的分析结果了。因此从经济的角度出发,对于用户行为分析这种不需要实时数据的需求来说,hbase+mysql就可以用最经济的方式解决了。mongodb比较适合需要实时返回数据的大数据应用。

总结:MongoDB更像传统的关系型数据库,更善于做查询。Hbase更偏向非关系型数据库,扩展储存能力强.

猜你喜欢

转载自blog.csdn.net/ZGL_cyy/article/details/114906152