ES-ElasticSearch
ElasticSearch是一个基于Lucene的分布式搜索引擎，业内简称ES。它提供了基于 RESTful 风格的全文搜索API。Elasticsearch是用Java开发的，并作为Apache许可条款下的开放源码发布，是当前最流行的企业级搜索引擎。另外，它的分布式设计让它天生就适合用于云计算中，并能够达到准实时搜索，而且安装使用方便，还拥有稳定，可靠，快速等特性。
严格的说，ES不是一个数据库，而是一个搜索引擎，ES的方方面面也都是围绕搜索设计的。值得一提的是，ES的全文搜索对中文也有很好的支持（单是中文分词器就有很多种），绝对能够满足国内大多数人的全文搜索需求。除了搜索之外，ES还会自动的替你对所有字段建立索引，以实现高性能的复杂聚合查询，因此只要是存入ES的数据，无论再复杂的聚合查询也可以得到不错的性能，而且你再也不用为如何建立各种复杂索引而头痛了。
但是ES的字段类型无法修改、写入性能较低和高硬件资源消耗。ES会自动的替你建立索引，尽管这能给全文搜索以及聚合查询带来很多好处还能替你省了建索引这一麻烦事，但是这个特性也会带来一堆问题。ES需要在创建字段前要预先建立Mapping，Mapping中包含每个字段的类型信息，ES需要根据Mapping为字段建立合适的索引。由于这个Mapping的存在，ES中的字段一但建立就不能再修改类型了。（例如，你建的数据表的某个字段忘了加全文搜索，你想临时加上，但是表已经建好并且已经有很多数据了，这时候该怎么办呢？不好意思，你只能把整个数据表删了再重建一遍！）
因此，ES在数据结构灵活度上高于MySQL但远不如MongoDB。ES的缺点还不止这些，自动建立索引使得ES的写入性能也收到了影响，要明显低于MongoDB。对于同样的数据ES占用的存储空间也要明显大于MongoDB（建那么多索引能不占空间吗？），对硬件资源的消耗也是非常厉害，大数据量下64G内存+SSD基本是标配，算得上是数据库中的贵族服务了，因此如果你的老板很小气，对于ES的选用可要慎重喽！
ES的全文搜索特性使它成为构建搜索引擎的利器。除此之外，ES很好的支持了复杂聚合查询这一特点还使得ES非常适合拿来作数据分析使用。其实，ES还专门做了与自己配套的ELK套装，给你提供从日志收集到数据可视化分析的一条龙服务，绝对是构建高大上数据分析平台的利器。但是，ES的高成本和低写入性能这些缺点也注定了它不适合用在那些数据价值不高、对写入性能有要求、数据量大而成本受限的场景中。
HBase
HBase是Hadoop项目的一部分，而且是当年谷歌大数据三驾马车之一的BigTable方案的实现，因此绝对算得上是大数据时代最有代表性的技术之一了。
作为Hadoop系列产品之一，HBase也继承了Hadoop项目的最大优点，那就是对海量数据的支持，以及极强的横向（存储容量）扩展能力。和Redis类似，HBase也需要为每一行数据定义一个key，之后所有的查询都依赖这个key进行。但是不同的地方在于，HBase中的一行数据还可以有非常多的列项（类似MongoDB字段），数据会按照列进行分组和存储，同一列的数据存储在同一个地方，这也是HBase被称为列式存储数据库的原因。其实从本质上来说，HBase相当于是把逻辑上的一张大表按照列族分拆成若干张小表分别进行存储，不仅是列，数据的行数到达一定数量后表也会再被拆分。因此，HBase能够把巨大的表分布到很多台机器上，从而容纳规模近乎无限的数据。同时，对HBase进行横向扩展也非常方便，你基本只需要添加新的机器，而不用对数据做任何改动，就可以实现数据库容量线性的增长，这在其他SQL数据库中是难以做到的（尽管其他数据库也有诸如MongoDB分片集群之类的功能帮助你进行数据规模横向扩展，但是无论是在实施的难度上还是在对数据的影响方面这些都无法跟HBase相提并论。）
HBase的列式存储特性带来了海量数据规模的支持和极强的扩展能力，但是也给数据的读取带来很大的局限。由于只有同一列族的数据才会被存放在一起，而且所有的查询都必须要依赖Key，这就使得很多复杂查询难以进行。例如，如果你的查询条件涉及多个列项，或者你无法获取要查询数据的key，那么查询效率将会非常低下。因此，HBase仅仅适合。
HBase的列式存储特点带来了对海量数据的容纳能力，因此非常适合数据量极大，查询条件简单，列与列之间联系不大的轻查询应用场景。最典型的比如搜索引擎所使用的网页数据库。HBase不适合数据结构复杂，且需要复杂查询的应用场景。另外值得一提的是，HBase是很重的一款产品，需要依赖很多的Hadoop组件，因此如果你的数据规模不大，那就完全没必要杀鸡用牛刀，MongoDB这类产品完全可以更好的满足你的需求。
MongDB
MongoDB最大的特点是表结构灵活可变，字段类型可以随时修改。MongoDB中的每一行数据只是简单的被转化成Json格式后存储，因此MongoDB中压根没有MySQL中表结构这样的概念，你可以直接简单粗暴的将任意结构的数据塞入同一个表中，压根不必考虑表结构的限制，更不必像MySQL一样因为要修改数据表结构而大费周折。简而言之，往MySQL写数据像是在做填空题，你写入的数据必须与最早定义的表结构一致，而往MongoDB写数据就像是在做问答题，想怎么写就怎么写，这灵活度不要爽太多。
说完MongoDB的优点也该说一说它的缺点了。MongoDB不需要定义表结构这个特点给表结构的修改带来了极大的方便，但是也给多表查询、复杂事务等高级操作带来了阻碍。因此，如果你的数据的逻辑结构非常复杂，经常需要进行复杂的多表查询或者事务操作，那显然还是MySQL这类关系型数据库更合适。
得益于MongoDB的这些特点，MongoDB很适合那些表结构经常改变，数据的逻辑结构没又没那么复杂不需要多表查询操作，数据量又比较大的应用场景。例如，有一个游戏应用，需要存储每个用户的信息，用户分为法师、战士等具有不同属性的角色，还有装备、技能等很多结构复杂的信息，游戏每次更新还可能会引入很多新的用户属性，这时如果你使用MySQL，那么你可能需要建立很多个表，定义很多个表结构，并且游戏的每次更新也可能会给你带来重定义表结构等一堆麻烦事，而如果使用MongoDB则这些麻烦统统不存在，因为你可以定义只一张表便可以容纳所有的信息，而且可以随时根据新的需求增减字段。
Redis
Redis的最大特点当然就是key-value存储所带来的简单和高性能了。所谓key-value存储，就是每一条记录只包含一个用于查询数据的Key，以及与之对应的存储数据的value，就如同现实生活中的门牌号与住户，而没有诸如表、字段这些常规数据库中必需有的复杂概念，所有的查询都仅仅依赖于key值。因此，key-value数据库可谓是数据库中数据结构最简单的一种，也得益于这种简单的结构，再加上Redis会把所有数据加载到内存中的，Redis能得到远高于MongoDB这类常规数据库的读写性能。当然，Redis的功能还不止key-value存储这么简单，相较它的key-value前辈Memcached，Redis还支持数据持久化，list、set等多种数据结构，主从复制备份等一些列功能，因此Redis绝对称得上是key-value数据库中功能最全面、最简单易用的款。
Redis的key-valule存储带来了性能这个优势，但是也给复杂查询带来了很多局限。由于阉割掉了数据表、字段这样的重要特性，且所有的查询都依赖key，因此Redis无法提供常规数据库所具备的多列查询、区段查询等复杂查询功能。同时，由于Redis需要把数据存在内存中，这也大大限制了Redis可存储的数据量，这也决定了Redis难以用在数据规模很大的应用场景中。
Redis牺牲了常规数据库中的数据表、复杂查询等功能，换来了很大的性能提升，特别适合那些对读写性能要求极高，且数据表结构简单（key-value、list、set之类）、查询条件也同样简单的应用场景。如果你的数据表结构还挺复杂，你还经常需要做一些复杂查询操作，那你最好还是老老实实用MongoDB或者SQL吧。
转载自：https://zhuanlan.zhihu.com/p/37964096