先谈谈 Nosql
CAP理论的核心是：一个分布式系统不可能同时很好的满足一致性，可用性和分区容错性这三个需求，最多只能同时较好的满足两个。 对于分布式数据系统，分区容忍性是基本要求，否则就失去了价值。因此设计分布式数据系统，就是在一致性和可用性之间取一个取舍平衡。
- C: Consistency 一致性 对于关系型数据库，要求更新过的数据能被后续的访问都能看到，这是强一致性。如：银行转账 如果经过一段时间后要求能访问到更新后的数据，则是最终一致性,弱一致性。如：在线字典，例子个数 通常靠锁保证，影响系统的并发度
- A: Availability 可用性 对于一个可用性的分布式系统，每一个非故障的节点必须对每一个请求作出响应。无论请求是否出错。 当向数据库写入时，mongodb默认不等待响应消息。使用getLastError命令来确保操作已经正确执行。
- P:Partition Tolerance分区容错性 分区容错性和扩展性紧密相关。好的分区容错性要求能够使应用虽然是一个分布式系统，而看上去却好像是在一个可以运转正常的整体。比如现在的分布式系统中有某一个或者几个机器宕掉了，其他剩下的机器还能够正常运转满足系统需求。
mongodb简介
- 分布式文档存储数据库
- 面向集合（文档）的类JSON格式存储方式,对面向对象编程语言友好
- 读写高性能（相对于RDBMS），高并发下的数据存储
- 扩展性好，通过增加机器实现性能扩展。如果负载的增加（需要更多的存储空间和更强的处理能力） ，它可以分布在计算机网络中的其他节点上这就是所谓的分片。
- 存储数据无模式，适合半结构化及非结构化数据存储，数据格式经常发生变
- 最接近RDBMS的NoSql数据库，介于键值对nosql和关系型数据库之间
- 支持mapreduce数据批量处理与聚合
- 支持大文件存储，GridFS提供了一种将大型文件存储在MongoDB的文件规范
- MongoDB支持各种编程语言:RUBY，PYTHON，JAVA，C ，PHP，C#等多种语言。
官方网站
https://www.mongodb.org/
mongodb的局限性与不足
- 在32位系统上，不支持大于2.5G的数据。
- 单个文档大小限制为 4 M/16 M（1.8版本后升为16M）
- 不支持join操作和事务机制,辩证角度看这也是优点。CAP原理。
- 对内存要求比较大，至少要保证热数据（索引，数据及系统其它开销）都能装进内存
- 用户权限方面比较弱，这一点MongoDB官方推荐的是将机器部署在安全的内网环境中，尽量不要用权限。
- 占用大量的磁盘空间。空间预分配，删除记录不释放空间，定期整理记录。
- 从维护工具，人才，实践经验较关系数据库都很缺乏
应用场景
- 数据模型简单，无复杂关联关系的大数据存储与检索。
- 用户需求频繁变化，数据无固定模式。
- 网站数据(弱一致性)：Mongo非常适合实时的插入，更新与查询，并具备网站实时数据存储所需的复制及高度伸缩性。
- 缓存：由于性能很高，Mongo也适合作为信息基础设施的缓存层。在系统重启之后，由Mongo搭建的持久化缓存层可以避免下层的数据源过载。
- 大尺寸，低价值的数据：如日志数据，用户行为数据，历史数据
- 高伸缩性的场景：Mongo非常适合由数十或数百台服务器组成的数据库。Mongo的路线图中已经包含对MapReduce引擎的内置支持。
- 用于对象及JSON数据的存储：Mongo的BSON数据格式非常适合文档化格式的存储及查询
不适用的场景如下
- 要求高度事务性的系统,如银行转账。强业务数据状态相互影响，频繁变换，如：企业OA。
- 传统的商业智能应用。针对特定问题的BI数据库会对产生高度优化的查询方式。对于此类应用，数据仓库可能是更合适的选择。
- 复杂的跨文档（表）级联查询。在查询条件复杂的情况下，相对于RDBMS并无明显优势，甚至没有优势或处于劣势。
总之，具备以下几点请考虑使用mongodb
- 你期待系统面对很高的写负载需要有更好的表现，如大规模并发日志收集系统
- 你的数据将爆发式增长，对可扩展性提出要求。
- 你的数据模型较为简单，查询条件简单。
- 你的数据结构较为松散
- 对性能要求较高，数据一致性要求较低
