目录

MongoDB

Redis

 

ElasticSearch

Hbase

HBase快速查询原理

总结

 

OLAP：

 

---

1. NOSQL数据库性能对比

  MongoDB

 

优点：

1:MongoDB最大的特点是表结构灵活可变，字段类型可以随时修改。

2:全索引支持，查询非常高效。

3:面向文档（BSON）存储，数据模式简单而强大。

缺点：

1：多表查询、复杂事务等高级操作支持不是很友好。因此，如果数据的逻辑结构非常复杂，经常需要进行复杂的多表查询或者事务操作，那显然还是MySQL这类关系型数据库更合适。

2：单个文档大小限制为16M，32位系统上，不支持大于2.5G的数据

3：对内存要求比较大，至少要保证热数据（索引，数据及系统其它开销）都能装进内存

总结：MongoDB很适合那些表结构经常改变，数据的逻辑结构没又没那么复杂不需要多表查询操作，数据量又比较大的应用场景

Redis

 

Redis的最大特点当然就是key-value存储所带来的简单和高性能了。所谓key-value存储，就是每一条记录只包含一个用于查询数据的Key，以及与之对应的存储数据的value，就如同现实生活中的门牌号与住户，而没有诸如表、字段这些常规数据库中必需有的复杂概念，所有的查询都仅仅依赖于key值

此，key-value数据库可谓是数据库中数据结构最简单的一种

优点：Redis会把所有数据加载到内存中的，Redis能得到远高于MongoDB这类常规数据库的读写性能，可以达到10w/s的频率

 

缺点：

1：由于阉割掉了数据表、字段这样的重要特性，且所有的查询都依赖key，因此Redis无法提供常规数据库所具备的多列查询、区段查询等复杂查询功能。同时，由于Redis需要把数据存在内存中，这也大大限制了Redis可存储的数据量

2：Redis3.0后才出来官方的集群方案，但仍存在一些架构上的问题

 

总结：适合那些

1：读写性能要求极高

2:数据表结构简单（key-value、list、set之类）

3:查询条件也同样简单的应用场景

4:数据变化快且数据库大小可遇见（适合内存容量）的应用程序

 

 

ElasticSearch

 

严格的说，ES不是一个数据库，而是一个搜索引擎

优点：

1:ES通过建立倒排索引实现全文搜索。具体来说，ES会建立一个覆盖表中所有文档、所有字段的庞大的倒排索引，以实现对存入ES中的所有数据进行快速检索。因此只要是存入ES的数据，无论再复杂的聚合查询也可以得到不错的性能

2:ES很好的支持了复杂聚合查询这一特点还使得ES非常适合拿来作数据分析使用

3:配套的ELK套装，给你提供从日志收集到数据可视化分析的一条龙服务

 

缺点：

1：自动建立索引使得ES的写入性能要明显低于MongoDB，并且ES的默认1S的写入延迟，也就是说你的数据在写入后要至少等1S才能被查询到。对于同样的数据ES占用的存储空间也要明显大于MongoDB

2：由于这个Mapping的存在，ES中的字段一但建立就不能再修改类型了，ES在数据结构灵活度上高于MySQL但远不如MongoDB

 

总结：ES的高成本和低写入性能这些缺点也注定了它不适合用在那些数据价值不高、对写入性能有要求、数据量大而成本受限的场景中。

 

Hbase

 

和Redis类似，HBase也需要为每一行数据定义一个key，之后所有的查询都依赖这个key进行。但是不同的地方在于，HBase中的一行数据还可以有非常多的列项（类似MongoDB字段），数据会按照列进行分组和存储，同一列的数据存储在同一个地方，这也是HBase被称为列式存储数据库的原因。其实从本质上来说，HBase相当于是把逻辑上的一张大表按照列族分拆成若干张小表分别进行存储，不仅是列，数据的行数到达一定数量后表也会再被拆分。因此，HBase能够把巨大的表分布到很多台机器上，从而容纳规模近乎无限的数据。同时，对HBase进行横向扩展也非常方便，你基本只需要添加新的机器，而不用对数据做任何改动，就可以实现数据库容量线性的增长，这在其他SQL数据库中是难以做到的（尽管其他数据库也有诸如MongoDB分片集群之类的功能帮助你进行数据规模横向扩展，但是无论是在实施的难度上还是在对数据的影响方面这些都无法跟HBase相提并论。）

 

HBase快速查询原理

根据亿级的记录中快速查询 & 以实时的方式查询数据。

A：如果快速查询（从磁盘读数据），hbase是根据rowkey查询的，只要能快速的定位rowkey,  就能实现快速的查询，主要是以下因素：
     1、hbase是可划分成多个region，你可以简单的理解为关系型数据库的多个分区。
      2、键是排好序了的
      3、按列存储的

首先，能快速找到行所在的region(分区)，假设表有10亿条记录，占空间1TB,   分列成了500个region,  1个region占2个G. 最多读取2G的记录，就能找到对应记录； 

其次，是按列存储的，其实是列族，假设分为3个列族，每个列族就是666M， 如果要查询的东西在其中1个列族上，1个列族包含1个或者多个HStoreFile，假设一个HStoreFile是128M， 该列族包含5个HStoreFile在磁盘上. 剩下的在内存中。

再次，是排好序了的，你要的记录有可能在最前面，也有可能在最后面，假设在中间，我们只需遍历2.5个HStoreFile共300M

最后，每个HStoreFile(HFile的封装)，是以键值对（key-value）方式存储，只要遍历一个个数据块中的key的位置，并判断符合条件可以了。 一般key是有限的长度，假设跟value是1:19（忽略HFile上其它块），最终只需要15M就可获取的对应的记录，按照磁盘的访问100M/S，只需0.15秒。 加上块缓存机制（LRU原则），会取得更高的效率。

 

优点：

1. 存储容量大，一个表可以容纳上亿行，上百万列；

2. 可通过版本进行检索，能搜到所需的历史版本数据；

3. 负载高时，可通过简单的添加机器来实现水平切分扩展，跟Hadoop的无缝集成保障了其数据可靠性（HDFS）和海量数据分析的高性能（MapReduce）；

4. 在第3点的基础上可有效避免单点故障的发生。

 

缺点：

1：同一列族的数据才会被存放在一起，而且所有的查询都必须要依赖Key，这就使得很多复杂查询难以进行。例如，如果你的查询条件涉及多个列族，或者你无法获取要查询数据的key，那么查询效率将会非常低下

2：API相比其它 NoSql 的相对笨拙

 

Rowkey设计方案：

例：

如果我们RowKey设计为uid+phone+name，那么这种设计可以很好的支持一下的场景:

uid=873969725 AND phone=18900000000 AND name=zhangsan

uid= 873969725 AND phone=18900000000

uid= 873969725 AND phone=189?

uid= 873969725

难以支持的场景：

phone=18900000000 AND name = zhangsan

phone=18900000000

name=zhangsan

RowKey从前向后匹配，所以我们在设计RowKey的时候选择好字段之后，还应该结合我们的实际的高频的查询场景来组合选择的字段，越高频的查询字段排列越靠左。

Rowkey样例：userid_wfinsid_entityid_时间戳

 

 

总结：HBase非常适合数据量极大扩展简单

，查询条件简单，列与列之间联系不大的轻查询应用场景。HBase不适合数据结构复杂，且需要复杂查询的应用场景

 

总结

1：如果你对数据的读写要求极高，并且你的数据规模不大，也不需要长期存储，选redis；

2:如果你的数据规模较大，对数据的读性能要求很高，数据表的结构需要经常变，有时还需要做一些聚合查询，选MongoDB；

3:如果你需要构造一个搜索引擎或者你想搞一个看着高大上的数据可视化平台，并且你的数据有一定的分析价值且资金预算充足，选ElasticSearch；

4:如果你需要存储海量数据，连你自己都不知道你的数据规模将来会增长多么大，那么选HBase，且在rowkey设计时候一定要得当。

 

 

 

OLAP：

1:Hive，Hawq，Impala - 基于SQL on Hadoop

2:Presto和Spark SQL类似 - 基于内存解析SQL生成执行计划

3:Kylin - 用空间换时间，预计算

4:Druid - 一个支持数据的实时摄入

5:ClickHouse - OLAP领域的Hbase，单表查询性能优势巨大

6:Greenpulm - OLAP领域的Postgresql

 

Greenplum是MPP数据库，适合处理传统的结构化、半结构化数据库，可以处理PB级别数据。Hive是SQl on Hadoop，是分布式数据库，适合处理超大规模数据，比如100个节点以上。小规模集群下速度比较慢，一般适合做离线计算。

 

如果你的场景是基于HDFS的离线计算任务，那么Hive，Hawq和Imapla就是你的调研目标；
如果你的场景解决分布式查询问题，有一定的实时性要求，那么Presto和SparkSQL可能更符合你的期望；
如果你的汇总维度比较固定，实时性要求较高，可以通过用户配置的维度+指标进行预计算，那么不妨尝试Kylin和Druid；
ClickHouse则在单表查询性能上独领风骚，远超过其他的OLAP数据库；
Greenpulm作为关系型数据库产品，性能可以随着集群的扩展线性增长，更加适合进行数据分析。

 

 

 

 

 

 

 

 

 

 

 

 

 

本文地址：https://blog.csdn.net/qq_35338741/article/details/110491524