1 需求

解决海量数据的存储，并且能够实现海量数据的秒级查询

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

这里只说是大公司，小公司一个HBASE绝对够用

所以说很多公司在历史遗留问题，最开始数据存储在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 架构设计

3 HBase和MongoDB的区别

Mongodb用于存储非结构化数据，尤其擅长存储json格式的数据或者是一些很难建索引的文本数据,。存储的量大概在10亿级别，再往上性能就下降了，除非另外分库。

Hbase是架构在hdfs上的列式存储，擅长rowkey的快速查询，但模糊匹配查询（其实是前模糊或全模糊）不擅长，但存储的量可以达到百亿甚至以上，比mongodb的存储量大多了。

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

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

Mysql数据量增加到千万的时候，响应时间上升很多和吞吐量下降很多。需要分表或者分片。

（1）从平均响应时间来看，mongodb占据绝对优势。

（2）从吞吐量上来看，mongodb占据绝对优势。

（3）对于千万或者更大的数据量，应该是要分区或分片，同时考虑分区容错性。如下图，mongodb属于CP，同时满足一致性(C，Consistency)、分区容错性(P，Partition Tolerance)。MySQL属于CA，同时满足一致性(C，Consistency)、可用性（A， Availability）。

其实后期很多公司都不选用Mongodb因为一旦数据量过大，再去改结构很复杂

京东已经做了替换