各种数据处理方案（SQL，NoSQL，其他）的应用场景

综合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型和对象型数据
• 少量索引，如果索引太多会有内存和性能瓶颈
• 大量高性能要求的在线业务并不适合
  

原标题：各种数据处理方案（SQL，NoSQL，其他）的应用场景

关键词：sql