适合读者： 对于MongoDB目前尚未有整体认识的初学者。在这里本ID将作一个简要的介绍：
二、MongoDB简介
MongoDB是一个高性能，开源，无模式的文档型数据库，是当前NoSql数据库中比较热门的一种。它在许多场景下可用于替代传统的关系型数据库或键/值存储方式。Mongo使用C++开发。Mongo的官方网站地址是：http://www.mongodb.org/，读者可以在此获得更详细的信息。
小插曲：什么是NoSql？
NoSql，全称是 Not Only Sql,指的是非关系型的数据库。下一代数据库主要解决几个要点：非关系型的、分布式的、开源的、水平可扩展的。原始的目的是为了大规模web应用，这场运动开始于2009年初，通常特性应用如：模式*、支持简易复制、简单的API、最终的一致性（非ACID）、大容量数据等。NoSQL被我们用得最多的当数key-value存储，当然还有其他的文档型的、列存储、图型数据库、xml数据库等。
特点:
高性能、易部署、易使用，存储数据非常方便。主要功能特性有：
面向集合存储，易存储对象类型的数据。
模式*。
支持动态查询。
支持完全索引，包含内部对象。
支持查询。
支持复制和故障恢复。
使用高效的二进制数据存储，包括大型对象（如视频等）。
自动处理碎片，以支持云计算层次的扩展性
支持Python，PHP，Ruby，Java，C，C#，Javascript，Perl及C++语言的驱动程序，社区中也提供了对Erlang及.NET等平台的驱动程序。
文件存储格式为BSON（一种JSON的扩展）。
可通过网络访问。
功能:
面向集合的存储：适合存储对象及JSON形式的数据。
动态查询：Mongo支持丰富的查询表达式。查询指令使用JSON形式的标记，可轻易查询文档中内嵌的对象及数组。
完整的索引支持：包括文档内嵌对象及数组。Mongo的查询优化器会分析查询表达式，并生成一个高效的查询计划。
查询监视：Mongo包含一个监视工具用于分析数据库操作的性能。
复制及自动故障转移：Mongo数据库支持服务器之间的数据复制，支持主-从模式及服务器之间的相互复制。复制的主要目标是提供冗余及自动故障转移。
高效的传统存储方式：支持二进制数据及大型对象（如照片或图片）
自动分片以支持云级别的伸缩性：自动分片功能支持水平的数据库集群，可动态添加额外的机器。
适用场合:
网站数据：Mongo非常适合实时的插入，更新与查询，并具备网站实时数据存储所需的复制及高度伸缩性。
缓存：由于性能很高，Mongo也适合作为信息基础设施的缓存层。在系统重启之后，由Mongo搭建的持久化缓存层可以避免下层的数据源 过载。
大尺寸，低价值的数据：使用传统的关系型数据库存储一些数据时可能会比较昂贵，在此之前，很多时候程序员往往会选择传统的文件进行存储。
高伸缩性的场景：Mongo非常适合由数十或数百台服务器组成的数据库。Mongo的路线图中已经包含对MapReduce引擎的内置支持。
用于对象及JSON数据的存储：Mongo的BSON数据格式非常适合文档化格式的存储及查询。
在国内的整体环境之中，MongoDB在中小类型的公司之中，其流向程度远超其他Nosql.
一旦您的业务扩展迅速，业务数据变大，请您先参阅如下位置：
http://news.cnblogs.com/n/121155/
为什么不？
1）MongoDB 为了赢得 Benchmark 测试而默认使用了不安全的写方式
如果你不调用 getLastError ()，MongoDB 就不会在确认数据库写操作完成就返回了，这会引入至少两种问题：
在并发的环境下（连接池等），在一个读操作“完成”后的连续地读操作会出错，MongoDB 没有“栅栏条件锁”来知道什么时候完成写。
未知个数的保存操作会被丢弃，因为保存操作的队列会在不同的地方。比如 TCP 缓存等。当你和数据库连接因为一些意味情况断开的时候，这些东西就被丢弃了。
10gen CTO 回复： 这和 Benchmark 没有任何关系，并说这个就是 API 的设计，其交给用户自己去选择，因为写的方式也有很多种。
2）MongoDB 会以令人震惊的方式丢失数据
下面是一个我们所经历过的它丢数据的列表：
数据就是丢了，原因未知。
从损坏的数据库中恢复数据不成功，如事务日志。
主从结点间的数据复制有缺口，导致“从结点”丢失“主结点”有的数据。是的，没有 CheckSum，并且是的，你还会看到复制状态为“从结点”的当前状态。
数据复制有时会停了，没有错误。你要监控你的复制状态！
10gen CTO 逐一回复：1）从来没有一个数据丢失的 BUG 我们没有马上 fix 的事情。你能告诉我你报给我们的问题号吗？我们至少要明白是怎么一回事。如果是我们的问题，我们会马上 fix 的。2）从损坏了的数据库中不能完全恢复数据 ，这不挺正常的吗？但是如果有主从服务器互为备份应该会好一些。3）请告诉我你的问题号，我们从来没有接到过这样的错误报告。如果有，的确很严重。4）如果是说错误条件发生的时候没有通知，这有可能。另外，你可以监控数据复制的写操作，你可以使用 w=2 为 getLastError 的参数。
3）MongoDB 需要全局写锁来请求写操作
在写操作频繁的时候，这等同于杀了你。如果你运行一个 blog，你也许不会关心这个事，因为你的读写操作不高。
10gen CTO 回复：读写锁永远都是问题，但是2.0会好很多，2.2会解决得更好一些。
4）MongoDB 的 Sharding (分区) 在高负载下会停止工作
在高负载下加一个 shard 是一场恶梦。Mongo 要么会移动其数据块太快而导致 DOS 攻击产生很多流量占用带宽，要么就完全地拒绝更多的数据块。这会使一个高流量的网站承受着沉重地写操作。
10gen CTO 回复：如果系统已经超过了其负载，那么移动数据当然会变得很难。我每一次的演讲都说得很清楚，不要在系统性能不行的时候才去加 shard，这不行的。
5）Mongo 不可靠
Mongod/配置服务器/mongos 的架构确实合理且聪明。不幸的是，mongos 完全就是垃圾。在有负载的情况下，它时不时就都会崩溃，有时几个小时，有时几天。进程重启监控有时也不管用，因为它会抛出一些断言伪造出一个关键线程，导致进程还在运行。Double Fail。
最坏的是，唯一可行的方式是在一堆 mongos 实例前放一个 HaProxy (一种负载均衡器)，运行一个作业缓慢地轮着访问这些 mongos 实例，并定期 kill 掉他们，以便可以重新启动新的实例。我没有在开玩笑。
10gen CTO 回复：不可能有这种事，你能不能告诉我更多的细节？
6）MongoDB 有一次甚至删除了整个数据库
MongoDB 1.6，在数据同步配置中，有时会配置了一个错误的结点（经常是一个空结点）作为一个最新的数据结点。于是其它同步数据的结点上的数据就这样被干掉了（我说的是700GB 的好数据），因为其把这个空结点的数据同步回有数据的结点上。数据库永远永远都不应该干这个。如果出现这种问题，数据库应该抛出一个错误而让 DBA 来选择合理的操作，或是强制使用正确的配置。而不应该删除所有的数据（那天真是太糟糕了）。
他们在1.8中修复了这个问题，偶滴神啊。
10gen CTO 回复：找不到这样的事，也找不到相应提交的代码，你能多给点信息吗？
7）发布了一些不应该发布东西
众所周知，在稳定版里能找到一些尴尬的 bug 会导致数据问题——而我们总是在出了问题后他们才告诉我们这些问题，这是因为我们购买了 10gen 他们那超级诈骗的白金技术支持。他们回应是，发给我们一个 hot patch，他们内部叫 RC 的玩意，然后让这个 hot patch 运行在我们的数据上。
10gen CTO 回复：关于白金的技术支持，我们所接手的所有问题都会公开，fix 也会公开。没有特定的情景，这种事很难讨论。我们会根据不同的情况作出不同的反应。我们希望我们的用户的问题能尽快得到解决。
8）复制器在繁忙的服务器上黯然失色
复制器经常性的向 Master 发起 DOS 攻击，或是复制非常慢，花了巨长无比的时间，而 oplog 几乎被耗尽（就算是 50GB 的 oplog）。
我们有一个繁忙的，大的数据集，我们不会复制它，因为它是动态的。那是令人痛苦的一个月，或是我们需要在选择不同的数据库系统前交叉双指（注：好运的手势）
10gen CTO 回复：这看起来像上服务器负载过重了。我前面提到过了。
但是最糟糕的问题是：
你可能会说，我这些问题都是过去式了；他们修复了所有这些问题或是他们会在下一版本中修复这些问题；X问题可以用Y实践来减轻。等等，等等。
不幸的是，你说这些东西一点用也没有。
真正的问题是，这么多的问题都是首要的问题。 数据库开发者要能 hold 住比一般程序员更高的标准。也就是说，你的优先级应该像下面这个样子：
别搞丢数据，对数据要有完全的把握
通过实践保证可用性
多结点的性能扩展性
最小延迟应该保持在99%和95%之间
每个资源的每秒请求数
10gen 的顺序好像是 #5 为第一，其它项随便，#1 并不在前3位。
10gen CTO 回复：这明显不是真的。看一看我们提交的代码，看一看我们的 fix。 我们从来不会在 release 版中隐藏一个 bug。如果我们非常在乎性能的 benchmark 的话，我们会花精力解决那些锁的问题，这样一来，多线程并发会更快一些。
MongoDB 是一个新生的东西，还有很多东西需要打磨。如果你想来认识一下我们，我们欢迎你来认识一下我们。
这些失败，还有那所暗示的公司的优先级，指出了一个最基本的企业文化的问题，其会让问题出现在任一发布版中：因为他们缺乏尊守必要的数据库系统的设计律条。
请慎重考虑这些警告。