elasticsearch、redis的应用场景是怎样的？
ElasticSearchES场景 分布式的搜索引擎和数据分析引擎，全文检索，结构化检索，数据分析 对海量数据进行近实时的处理，站内搜索（电商，招聘，门户，等等）， IT 系统搜索（ OA ， CRM ， ERP ，等等），数据分析
ES不是一个数据库，而是一个搜索引擎，ES的方方面面也都是围绕搜索设计的。ES支持全文搜索，这里简单解释下什么是全文搜索：对于“我在北京的一家互联网公司工作”这样的数据，如果你搜索“北京”、“互联网”、“工作”这些关键词都能命中这条数据的话，这就是全文搜索，你每天都在用的百度、Google都属于全文搜索。值得一提的是，ES的全文搜索对中文也有很好的支持（单是中文分词器就有很多种），绝对能够满足国内大多数人的全文搜索需求。除了搜索之外，ES还会自动的替你对所有字段建立索引，以实现高性能的复杂聚合查询，因此只要是存入ES的数据，无论再复杂的聚合查询也可以得到不错的性能，而且你再也不用为如何建立各种复杂索引而头痛了。
ES也有很多的短处，最明显的就是字段类型无法修改、写入性能较低 和 高硬件资源消耗。 前边讲到ES会自动的替你建立索引，尽管这能给全文搜索以及聚合查询带来很多好处还能替你省了建索引这一麻烦事，但是这个特性也会带来一堆问题。ES需要在创建字段前要预先建立Mapping，Mapping中包含每个字段的类型信息，ES需要根据Mapping为字段建立合适的索引。由于这个Mapping的存在，ES中的字段一但建立就不能再修改类型了。（例如，你建的数据表的某个字段忘了加全文搜索，你想临时加上，但是表已经建好并且已经有很多数据了，这时候该怎么办呢？不好意思，你只能把整个数据表删了再重建一遍！！！） 自动建立索引使得ES的写入性能也收到了影响，明显低于MongoDB。对于同样的数据ES占用存储空间也要明显大于MongoDB（建那么多索引能不占空间吗？），对硬件资源的消耗也是非常厉害，大数据量下64G内存+SSD基本是标配，算得上是数据库中的贵族服务了，因此如果你的老板很小气，对于ES的选用可要慎重喽！
redisredis场景 常规计数：粉丝数，微博数；用户信息变更；缓存处理，作为 mysql 的缓存；队列系统，建有优先级的队列系统，日志收集系统
Redis是现在最热门的key-value数据库。它与MongoDB同在2009年发布，也同样是早期大数据时代的数据库代表作。
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吧。
总结如果你对数据的读写要求极高，并且你的数据规模不大，也不需要长期存储，选redis；
如果你的数据规模较大，对数据的读性能要求很高，数据表的结构需要经常变，有时还需要做一些聚合查询，选MongoDB；
如果你需要构造一个搜索引擎或者你想搞一个看着高大上的数据可视化平台，并且你的数据有一定的分析价值或者你的老板是土豪，选ElasticSearch；
如果你需要存储海量数据，连你自己都不知道你的数据规模将来会增长多么大，那么选HBase。
