您当前的位置: 综合stackoverflow和linkin上的相关讨论，还有我个人的工作经验：
Redis应用场景（大部分场景下memcache可以用Redis代替，所以不单独讨论）
- 线上业务，读写的高性能要求
- 非海量数据（单机GB级别）
- 多机共享型操作，如session
- 支持事务（但并没有想像中的那么好用，逻辑上容易出问题）
- 优秀的原生数据结构
- 小型原子操作（如计数器）
- 不适用于N层结构的数据处理，或者说可以用于存储但是最好不要更新，以hash为例，包括redis实例（一个实例也等于是key-value字典）自己在内，只有两层结构，再多就不能使用原子操作命令，内容也只能存储成json之类的结构，不方便修改。
MySQL等传统数据库应用场景
- 相对较少的数据（相对而言，千万级以上数据量可以处理但并不推荐）
- insert/update/select不能同时都很频繁（基本上只有多读少写是比较能接受的应用范围）
- 对应可靠性要求比较高的业务
- 单次业务操作要求复杂，变更频繁，但是操作频率并不高。（比如运营管理平台之类）
- BI型业务，要求高度优化的查询方式，ES之类也许可以得到相同的结果，但效率上还做不到这一点
hadoop应用场景
- 海量数据（单机和普通机群无法处理时适用）
- 高扩展性
- 数据最好能整理成比较规则的行列形式
- 有比较多的join/group类操作/集合操作，或者更复杂的计算需求（相比之下，可以比ES之类的搜索查询复杂得多，脚本可能写得很复杂）。
- 即时性上要求不高，主要用于离线分析和处理
- 搭建和管理相对麻烦（如redis和mysql可以很简单的由普通技术人员单人搭建和维护）
Elasticsearch应用场景
- 它首先是一个搜索引擎而不是数据存储（其实也可以用做存储，只是说没有很多专门的存储那么好，但是可能对中小企业来说足够了）
- 是一个高效的数据分析引擎，自带分析用语法，比其他的工具强大
- 并不是一个全能的数据分析工具，如join之类的查询支持的并不好
- 分析的主要目标是数据列
- 数据量很大，列不定，所有列都有可能有查询需求（区别于mangodb）
- 大量新数据insert，大量search，少量update（频繁update会导致索引频繁变化，IO等都会受比较大影响）
- 有历史快照版本，可以找到已经删除掉的老数据（当然也会占用更多的空间）
mongodb应用场景
- 键值型文档存储
景 - 不要求列相同（和ES差不多）
- 分析的操作的主要目标是数据行
- 存储量大但是价值比较低的数据
- 存储json型和对象型数据
- 少量索引，如果索引太多会有内存和性能瓶颈
- 大量高性能要求的在线业务并不适合