使用场景2

MongoDB作为文档型数据库，在公司生产环境得到了较为广泛的适用，现将MongoDB比较适用的场景做一个总结，已供大家在选型的时候参考。

1、各种应用服务的日志存储，MongoDB的高性能足够支撑关系型数据库2-3倍以上的TPS/QPS，同时自带的三种压缩格式方便在容量和性能直接作出选择，通过MongoDB存储日志文件，查询简单(索引)，写入导出方便（弹性结构没有表结构限制）。

2、敏捷开发，如果你想快速构建应用系统，同时还想拥有高性能，高灵活性的schema，不要犹豫，使用MongoDB吧。

3、地理位置信息存储，通过2d和2dsphere索引，可以很方便的查询出具体的位置信息。

4、json存储，json的数据结构简单、直观，非常适合用来表达数据，且易于阅读、扩展。

其实并没有什么业务场景是一定要MongoDB才能支持的，但是MongoDB往往能在同等的成本下发挥更好的作用(灵活性、性能等)，如下是MongoDB的一些主要特性：

1、事务支持 MongoDB 目前只支持单文档事务，需要复杂事务支持的场景暂时不适合。

  PS:4.0版本已经GA，已经支持ACID事务。

2、灵活的文档模型，JSON 格式存储最接近真实对象模型，对开发者友好，方便快速开发迭代。

3、高可用复制集，满足数据高可靠、服务高可用的需求，运维简单，故障自动切换。

4、可扩展分片集群，海量数据存储，服务能力水平扩展。

5、高性能，mmapv1、wiredtiger、mongorocks（rocksdb）、in-memory 等多引擎支持满足各种场景需求。

6、强大的索引支持 地理位置索引可用于构建 各种 O2O 应用、文本索引解决搜索的需求、TTL索引解决历史数据自动过期的需求。

7、Gridfs，解决文件存储的需求。

8、aggregation & mapreduce，解决数据分析场景需求，用户可以自己写查询语句或脚本，将请求都分发到 MongoDB 上完成。

如果你还在为是否应该使用 MongoDB，不如来做几个选择题来辅助决策（注：以下内容摘自 MongoDB公司的某次公开技术分享）。

应用特征	YES / NO
应用不需要事务及复杂 join 支持	必须 Yes
新应用，需求会变，数据模型无法确定，想快速迭代开发	？
应用需要2000-3000以上的读写QPS（更高也可以）	？
应用需要TB甚至 PB 级别数据存储	?
应用发展迅速，需要能快速水平扩展	?
应用要求存储的数据不丢失	?
应用需要99.999%高可用	?
应用需要大量的地理位置查询、文本查询	？

如果上述有1个 Yes，可以考虑 MongoDB，2个及以上的 Yes，选择 MongoDB 绝不会后悔。

服务架构