1.Mongodb bson文档型数据库，整个数据都存在磁盘中，hbase是列式数据库，集群部署时每个familycolumn保存在单独的hdfs文件中。

2.Mongodb 主键是“_id”,主键上面可以不建索引,记录插入的顺序和存放的顺序一样，hbase的主键就是row key，可以是任意字符串(最大长度是 64KB，实际应用中长度一般为 10-100bytes)，在hbase内部，row key保存为字节数组。存储时，数据按照Row key的字典序(byte order)排序存储。设计key时，要充分排序存储这个特性，将经常一起读取的行存储放到一起。

字典序对int排序的结果是1,10,100,11,12,13,14,15,16,17,18,19,2,20,21,…,9,91,92,93,94,95,96,97,98,99。要保持整形的自然序，行键必须用0作左填充。

3.Mongodb支持二级索引，而hbase本身不支持二级索引

4.Mongodb支持集合查找，正则查找，范围查找，支持skip和limit等等，是最像mysql的nosql数据库，而hbase只支持三种查找：通过单个row key访问，通过row key的range，全表扫描

5.mongodb的update是update-in-place，也就是原地更新，除非原地容纳不下更新后的数据记录。而hbase的修改和添加都是同一个命令：put，如果put传入的row key已经存在就更新原记录,实际上hbase内部也不是更新，它只是将这一份数据已不同的版本保存下来而已，hbase默认的保存版本的历史数量是3。

6.mongodb的delete会将该行的数据标示为已删除，因为mongodb在删除记录时并不是真把记录从内存或文件中remove，而是将该删除记录数据置空（写0或特殊数字加以标识）同时将该记录所在地址放到一个list列表“释放列表”中，这样做的好就是就是如果有用户要执行插入记录操作时，mongodb会首先从该“释放列表”中获取size合适的“已删除记录”地址返回，这种方法会提升性能（避免了malloc内存操作），同时mongodb也使用了bucket size数组来定义多个大小size不同的列表，用于将要删除的记录根据其size大小放到合适的“释放列表”中。Hbase的delete是先新建一个tombstonemarkers，然后读的时候会和tombstonemarkers做merge，在 发生major compaction时delete的数据记录才会真真删除。

7.mongodb和hbase都支持mapreduce，不过mongodb的mapreduce支持不够强大，如果没有使用mongodb分片，mapreduce实际上不是并行执行的

8.mongodb支持shard分片，hbase根据row key自动负载均衡，这里shard key和row key的选取尽量用非递增的字段，尽量用分布均衡的字段，因为分片都是根据范围来选择对应的存取server的，如果用递增字段很容易热点server的产生，由于是根据key的范围来自动分片的，如果key分布不均衡就会导致有些key根本就没法切分，从而产生负载不均衡。

9.mongodb的读效率比写高，hbase默认适合写多读少的情况，可以通过hfile.block.cache.size配置，该配置storefile的读缓存占用Heap的大小百分比，0.2表示20%。该值直接影响数据读的性能。如果写比读少很多，开到0.4-0.5也没问题。如果读写较均衡，0.3左右。如果写比读多，果断默认0.2吧。设置这个值的时候，你同时要参考hbase.regionserver.global.memstore.upperLimit，该值是memstore占heap的最大百分比，两个参数一个影响读，一个影响写。如果两值加起来超过80-90%，会有OOM的风险，谨慎设置。

10.hbase采用的LSM思想(Log-Structured Merge-Tree)，就是将对数据的更改hold在内存中，达到指定的threadhold后将该批更改merge后批量写入到磁盘，这样将单个写变成了批量写，大大提高了写入速度，不过这样的话读的时候就费劲了，需要merge disk上的数据和memory中的修改数据，这显然降低了读的性能。mongodb采用的是mapfile+Journal思想，如果记录不在内存，先加载到内存，然后在内存中更改后记录日志，然后隔一段时间批量的写入data文件，这样对内存的要求较高，至少需要容纳下热点数据和索引。

HBase特点
优点：

海量存储：适合存储PB级别的海量数据，采用廉价PC存储的情况下，能在几十到百毫秒内返回数据。
列式存储（半结构化或非结构化数据）：即列族存储，对于数据结构字段不够确定或杂乱无章非常难按一个概念去进行抽取的数据适合用。
极易扩展：一个是基于上层处理能力（RegionServer）的扩展，提升Hbsae服务更多Region的能力。一个是基于存储的扩展（HDFS），通过横向添加Datanode的机器，进行存储层扩容，提升Hbase的数据存储能力和提升后端存储的读写能力。
高并发：采用廉价PC，能获得高并发、低延迟、高性能的服务。
稀疏：列族中，可以指定任意多的列，列数据为空不会占用存储空间的，也提高了读性能。
多版本号数据：依据Row key和Column key定位到的Value能够有随意数量的版本号值，版本号默认是单元格插入时的时间戳。
适用于插入比查询操作更频繁的情况：比如，对于历史记录表和日志文件。
数据类型单一：HBase中数据类型都是字符串。
无模式：每一行都有一个可以排序的rowKey和任意多的截然不同的列。
缺点：

单一RowKey固有的局限性决定了它不可能有效地支持多条件查询。
不适合于大范围扫描查询。
不直接支持 SQL 的语句查询。
仅支持行级（单行）事务（HBase的事务是行级事务，可以保证行级数据的原子性、一致性、隔离性以及持久性）。
HBase的配置非常麻烦，最低的限度都需要包括Zookeeper ensemble、primary HMaster、secondary HMaster、RegionServers、active NameNode、standby NameNode、HDFS quorum journal manager及DataNodes。使用HBase需求大量的专业知识——甚至是最简单的监视。RegionServer存在单点故障，当它发生故障时，一个新的RegionServer必须被选举出，而在可以投入之前，必须重新完成write-ahead日志里的内容，即故障恢复较慢，WAL回放较慢。HBase的API非常笨拙并且具有太强的Java特色，非Java客户端只能委托给Thrit或者REST。

HBase使用场景
Hbase是一个通过廉价PC机器集群来存储海量数据的分布式数据库解决方案。它比较适合的场景概括如下：

是巨量大（百T、PB级别）
查询简单（基于rowkey或者rowkey范围查询）
不涉及到复杂的关联
有几个典型的场景特别适合使用Hbase来存储：

海量订单流水数据（长久保存）
交易记录
数据库历史数据

如何使用HBase
三种模式：单机模式，伪分布式模式，分布式模式

一般生产环境用的是分布式模式，如果是学习的话，可以用单机模式和伪分布式模式。

什么是MongoDB
MongoDB是一个介于关系数据库和非关系数据库之间，基于分布式文件存储，由C 语言编写的数据库。

MongoDB特点
优点

高性能、易部署、易使用、高写负载，存储数据非常方便。

面向文档存储(类JSON数据模式简单而强大)
动态查询

全索引支持,扩展到内部对象和内嵌数组

查询记录分析

快速,就地更新

高效存储二进制大对象 (比如照片和视频)

复制和故障切换支持

Auto- Sharding自动分片支持云级扩展性

支持RUBY，PYTHON，JAVA，C ，PHP，C#等多种语言。
MapReduce 支持复杂聚合

商业支持,培训和咨询

缺点

不支持事务（进行开发时需要注意，哪些功能需要使用数据库提供的事务支持）
MongoDB占用空间过大 （不过这个确定对于目前快速下跌的硬盘价格来说，也不算什么缺点了）
2.1、空间的预分配:
当MongoDB的空间不足时它就会申请生成一大块硬盘空间，而且申请的量都是有64M、128M、256M来增加直到2G为单个文件的较大体积，并且随着数量叠增，可以在数据目录下看到整块生成而且不断递增的文件。

2.2、删除记录不释放空间：

这很容易理解，为避免记录删除后的数据的大规模挪动，原记录空间不删除，只标记“已删除”即可，以后还可以重复利用。

MongoDB没有如MySQL那样成熟的维护工具，这对于开发和IT运营都是个值得注意的地方
在32位系统上，不支持大于2.5G的数据(很多操作系统都已经抛弃了32位版本，所以这个也算不上什么缺点了，3.4版本已经放弃支持32 位 x86平台)

景适用

适用场景
MongoDB 的主要目标是在键/值存储方式（提供了高性能和高度伸缩性）和传统的RDBMS 系统（具有丰富的功能）之间架起一座桥梁，它集两者的优势于一身。根据官方网站的描述，Mongo 适用于以下场景。
● 网站数据：Mongo 非常适合实时的插入，更新与查询，并具备网站实时数据存储所需的复制及高度伸缩性。
● 缓存：由于性能很高，Mongo 也适合作为信息基础设施的缓存层。在系统重启之后，由Mongo 搭建的持久化缓存层可以避免下层的数据源过载。
● 大尺寸、低价值的数据：使用传统的关系型数据库存储一些数据时可能会比较昂贵，在此之前，很多时候程序员往往会选择传统的文件进行存储。
● 高伸缩性的场景：Mongo 非常适合由数十或数百台服务器组成的数据库，Mongo 的路线图中已经包含对MapReduce 引擎的内置支持。
● 用于对象及JSON 数据的存储：Mongo 的BSON 数据格式非常适合文档化格式的存储及查询。
不适场景
● 高度事务性的系统：例如，银行或会计系统。传统的关系型数据库目前还是更适用于需要大量原子性复杂事务的应用程序。
● 传统的商业智能应用：针对特定问题的BI 数据库会产生高度优化的查询方式。对于此类应用，数据仓库可能是更合适的选择。
● 需要SQL 的问题

MySQL：关系型数据库，可视化好，但是SQL语句不想写，pass；

Redis：Key-Value 数据库，根本没有通过值查询的途径，pass；

MongoDB：面向文档数据库，数据存储的最小单位是文档，可以使用 XML、JSON 或者 JSONB 等多种形式存储，考虑；

HBase：列存储数据库，将数据储存在列族（column family）中，一个列族存储经常被一起查询的相关数据，

但是在模型设计之初，我们根本不可能去预测它的查询方式，而一旦查询方式改变，我们就必须重新设计列族，

3.HBase（列存储）

两大用途：

特别适用于简单数据写入（如“消息类”应用）和海量、结构简单数据的查询（如“详单类”应用）。特别地，适合稀疏表。（个人觉得存个网页内容是极好极好的）
作为MapReduce的后台数据源，以支撑离线分析型应用。
4.MongoDB

是一个介于关系型和非关系型之间的一个产品吧，类SQL语言，支持索引
MongoDb在类SQL语句操作方面目前比HBase具备更多一些优势，有二级索引，支持相比于HBase更复杂的集合查找等。
BSON的数据结构使得处理文档型数据更为直接。支持复杂的数据结构
MongoDb也支持mapreduce，但由于HBase跟Hadoop的结合更为紧密，Mongo在数据分片等mapreduce必须的属性上不如HBase这么直接，需要额外处理。
5.Redis

Redis为内存型KV系统，处理的数据量要小于HBase与MongoDB
Redis很适合用来做缓存，但除此之外，它实际上还可以在一些“读写分离”的场景下作为“读库”来用，特别是用来存放Hadoop或Spark的分析结果。
Redis的读写性能在100,000 ops/s左右，时延一般为10～70微妙左右；而HBase的单机读写性能一般不会超过1,000ops/s，时延则在1～5毫秒之间。
Redis的魅力还在于它不像HBase只支持简单的字符串，他还支持集合set，有序集合zset和哈希hash
MongoDB做高性能数据库，Redis做缓存，HBase做大数据分析。MongoDB还无法取代关系型数据库。

MongoDB是高性能、无模式的文档型数据库，支持二级索引，非常适合文档化格式的存储及查询。MongoDB的官方定位是通用数据库，确实和MySQL有些像，现在也很流行，但它还是有事务、join等短板，在事务、复杂查询应用下无法取代关系型数据库。

Redis是内存型Key/Value系统，读写性能非常好，支持操作原子性，很适合用来做高速缓存。

HBase存储容量大，一个表可以容纳上亿行、上百万列，可应对超大数据量要求扩展简单的需求。Hadoop的无缝集成，让HBase的数据可靠性和海量数据分析性能（MapReduce）值得期待。

所以说，关系型数据库和NoSQL各有优劣，两者结合，可以覆盖更多的业务场景。

https://www.zhihu.com/question/45440393