转自：http://book.2cto.com/201211/7898.html
老实说，我们不会仅根据数据库的特性做选择，还需要知道使用它的真实成功案例。这里，我提供一些广义上的MongoDB使用场景，以及一些生产环境中的示例 。
1. Web应用程序
MongoDB很适合作为Web应用程序的主要数据存储。就算是一个简单的Web应用程序也会有很多数据模型，用来管理用户、会话、应用特定的数据、上传和权限，更不用说非常重要的域了。正如它们能和关系型数据库的表列数据配合良好一样，它们也能获益于MongoDB的集合与文档模型。因为文档能表示丰富的数据结构，建模相同数据所需的集合数量通常会比使用完全正规化关系型模型的数据表数量要少。此外，动态查询和二级索引能让你轻松地实现SQL开发者所熟悉的大多数查询。最后，作为一个成长中的Web应用程序，MongoDB提供了清晰的扩展路线。
在生产环境中，MongoDB已经证明它能管理应用的方方面面，从主要数据领域到附加数据存储，比如日志和实时分析。这里的案例来自The Business Insider（TBI），它从2008年1月起将MongoDB作为主要数据存储使用。虽然TBI是一个新闻网站，但它流量很大，每天有超过一百万独立页面访问。这个案例中有意思的是除了处理站点的主要内容（文章、评论、用户等），MongoDB还处理并存储实时分析数据。这些分析被TBI用于生成动态热点地图，标明不同新闻故事的点击率。该站目前还没有太多的数据，因此尚不需要分片，但它有使用副本集来保证停电时的自动故障转移。
2. 敏捷开发
无论如何看待敏捷开发运动，你都很难否认对于快速构建应用程序的渴望。不少开发团队，包括Shutterfly和纽约时报的团队，都部分选择了MongoDB，因为相比关系型数据库，使用MongoDB能更快地开发应用程序。一个明显的原因是MongoDB没有固定的Schema，所有花在提交、沟通和实施Schema变更的时间都省下来了。
除此之外，不再需要花时间把数据的关系型表述硬塞进面向对象的数据模型里去了，也不用处理ORM生成的SQL的奇怪行为，或者对它做优化了。如此一来，MongoDB为项目带来了更短的开发周期和敏捷的、中等大小的团队。
3. 分析和日志
我之前已经暗示过MongoDB适用于分析和日志，将MongoDB用于这些方面的应用程序数量增长得很快。通常，发展成熟的公司都会选择将用于分析的特殊应用作为切入点，进入MongoDB的世界。这些公司包括GitHub、Disqus、Justin.tv和Gilt Groupe，还有其他公司就不再列举了。
MongoDB与分析的关联源自于它的速度和两个关键特性：目标原子更新和固定集合（capped collection）。原子更新让客户端能高效地增加计数器，将值放入数组。固定集合，常用于日志，特点是分配的大小固定，能实现自动过期。相比文件系统，将日志数据保存在数据库里更易组织，而且能提供更强大的查询能力。现在，抛开grep或自定义日志检索工具，用户可以使用他们熟悉并喜欢的MongoDB查询语言来查看日志输出。
4. 缓存
这是一种数据模型，它能更完整地表示对象，结合更快的平均查询速度，经常让MongoDB介于传统的MySQL与memcached之间。例如之前提到的TBI，它可以不使用memcached，直接通过MongoDB来响应页面请求。
5. 可变Schema
看看这段代码示例 ：
这里从Twitter流上拉下一小段示例，并用管道将其直接导入MongoDB集合。因为流生成的是JSON文档，在把它发给数据库前就不需要预先处理数据了。mongoimport工具能直接将数据转换成BSON。这意味着每条推文都能保持其结构，原封不动地存储为集合中的单个文档。无论你是想查询、索引还是执行MapReduce聚合，都能立刻操作数据。而且，不需要事先声明数据的结构。
如果应用程序需要调用JSON API，那么拥有这样一个能轻松转换JSON的系统就太棒了。如果在存储之前无法预先了解数据的结构，MongoDB没有Schema约束的特性能大大简化数据模型。