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

《Hbase+ES和MongoDB存储大数据的选用.docx》由会员分享，可在线阅读，更多相关《Hbase+ES和MongoDB存储大数据的选用.docx（4页珍藏版）》请在淘文阁 - 分享文档赚钱的网站上搜索。

1、Hbase+ES和MongoDB存储大数据的选用 1 需求 解决海量数据的存储 并且可以实现海量数据的秒级查询 Hbase是典型的nosql 是一种构建在HDFS之上的分布式、面向列的存储系统 在需要的时候可以进展实时的大规模数据集的读写操作 但是hbase的语法非常固话 即便在hbase之上嫁接了phoneix在应对复杂查询的时候 仍然力不从心 这里只讲是大公司 小公司一个HBASE绝对够用 所以讲很多公司在历史遗留问题 最开场数据存储在hbase上 当业务越来越复杂 数据量越来越大的时候 使用hbase构建复杂的查询就很吃力了 甚至很多指标无法完成 这个时候 我们就是用elasticsea

2、rch架构在hbase之上 海量的数据存储使用hbase 数据的即席查询 快速检索 使用elasticsearch 通过elasticsearch hbase就可以做到海量数据的复杂查询 在操作之前 我们还要考虑 一批数据在elasticsearch中构建索引的时候 针对每一个字段要分析是否存储以及是否构建索引 ES Hbase的话,公司的使用是将ES的索引就行以及实体类就行一个索引映射,然后用一个封装好的效劳之后推入索引库中数据,详细还没研究不是很清楚,这种框架类的东西会用就行了,问题也不大,因为以前写的话,是自己从数据库查询数据做一个批量导入,应该原理上是一样的,之后就是通过es的索引支持

3、然后查询Hbase,这里我想应该是es充当hbase的索引进展查询,我们以前的是用的mongodb是支持10亿级别数据再往上就不行了,hbase支持百亿数据,这里hbase并且可以实现海量数据的秒级查询,我查询了一下hbase的语法非常固话 即便在hbase之上嫁接了phoneix在应对复杂查询的时候 仍然力不从心,当业务越来越复杂 数据量越来越大的时候 使用hbase构建复杂的查询就很吃力了 甚至很多指标无法完成,所以这个es起了关键性因素 实际应用 先ES根据条件查询到分页数据 或是list里面封装的是那个所有实体类、然后遍历 通过遍历到的id去查hbase 之后就可以封装Dto 然后返回

4、List 2 架构设计 3 HBase以及MongoDB的区别 Mongodb用于存储非构造化数据 尤其擅长存储json格式的数据或是一些很难建索引的文本数据,。存储的量大概在10亿级别 再往上性能就下降了 除非另外分库。 Hbase是架构在hdfs上的列式存储 擅长rowkey的快速查询 但模糊匹配查询 其实是前模糊或者全模糊 不擅长 但存储的量可以到达百亿甚至以上 比mongodb的存储量大多了。 原因就在于写入的速度 hbase由于只维护一个主键 写入的速度要比mongodb这种要维护所有索引的数据库快多了。hbase占用两台机器能完成的事情 mongodb要占用更多的机器 每台机器按一

5、年度20000的费用 几百台下来就是一笔很大的费用。但是代价就是hbase记录下东西以后 只能事后通过全表检索或者按照索引范围的方式进展整体分析 而不能对详细每个人的数据进展实时分析 更强调数据分析才能而不是实时数据查询才能 因此各有千秋吧。像用户行为分析的这种 一开场产品经理可能会详细看某一个人的数据 但是新颖过后 只会看程序的分析结果了。因此从经济的角度出发 对于用户行为分析这种不需要实时数据的需求来讲 hbase mysql就可以用最经济的方式解决了。mongodb比拟合适需要实时返回数据的大数据应用。 总结 MongoDB更像传统的关系型数据库 更擅长做查询。Hbase更偏向非关系型数

6、据库 扩展储存才能强. Mysql数据量增加到千万的时候 响应时间上升很多以及吞吐量下降很多。需要分表或分片。 1 从平均响应时间来看 mongodb占据绝对优势。 2 从吞吐量上来看 mongodb占据绝对优势。 3 对于千万或更大的数据量 应该是要分区或者分片 同时考虑分区容错性。如下列图 mongodb属于CP 同时知足一致性(C Consistency)、分区容错性(P Partition Tolerance)。MySQL属于CA 同时知足一致性(C Consistency)、可用性 A Availability 。 其实后期很多公司都不选用Mongodb因为一旦数据量过大 再去改构造很复杂 京东已经做了交换