MongoDB核心贡献者

默认情况下修改语句修改的只是单个文件

在传统的RDBMS中除非使用LIMIT子句，修改语句作用的将是所有匹配的地方。然而MongoDB每个查询上都默认使用等价“LIMIT 1”的设置。虽然无法做到“LIMIT 5”，但是你可以通过下面的语句整个的移除限制：

db.people.update({age: {$gt: 30}}, {$set: {past_it: true}}, false, true)

同样在官方的驱动中还有类似的选项 —— ‘multi’。

总结：可以通过指定多个文件的multi为true来完成多文件修改

查询区分大小写

字符串的查询可能不按预期的那样发展 —— 这归结于MongoDB默认区分大小写。

例如：db.people.find（{name: ‘Russell’}）与db.people.find（{name: ‘ russell‘}）是不同的。在这里最理想的解决方案就是对需要查询数据进行确认。你也可以通过正则表达式进行查询，比如：db.people.find（{name:/Russell/i}），但是这样会影响到性能。

总结：查询是区分大小写的，在牺牲速度的情况下可以利用正则表达式。

对输入的数据无容错性

当你尝试向传统数据库插入错误类型的数据，传统的数据库一般会把数据转换成预定义的类型。然而这在MongoDB中是行不通的，因为MongoDB的文件是没有预定义数据模型的。这样的话MongoDB会插入你输入的任何数据。

总结：使用准确的数据类型。

关于锁

当资源被代码的多个部分所共享时，需要确信锁必须要确保这处资源只能在一个地方被操作。

旧版本的MongoDB （pre 2.0）拥有一个全局的写入锁。这就意味贯穿整个服务器中只有一个地方做写操作。这就可能导致数据库因为某个地方锁定超负载而停滞。这个问题在2.0版本中的得到了显著的改善，并且在当前2.2版本中得到了进一步的加强。MongoDB 2.2使用数据库级别的锁在这个问题上迈进了一大步。同样值得期待的Collection级别的锁也计划在下一个版本中推出。

尽管如此，Russell还是认为：大多数受此限制的应用程序于其说是受MongoDB影响，还不如说是程序本身的问题来的更直接。

总结：使用最新的稳定版本才能获得最高的性能。

使用偶数个Replica Set成员

Replica Set是增加冗余及提升MongoDB数据集群性能的有效途径。数据在所有的节点中被复制，并选出一个作为主节点。假如主节点出故障，那么会在其他的节点中票选一个作为新的主节点。

在同一个Replica Set中使用两台机器是很有诱惑的，它比3台机器来的便宜并且也是RDBMS的标准行事风格。

但是到了MongoDB这里，同一个Replica Set中的成员数量只能是奇数个。假如你使用了偶数个成员，那么当主节点发生故障时那么其它的节点都会变成只读。发生这种情况是因为剩下待选节点的数目不满足票选主节点的规定。

如果你想节约成本，同时还希望支持故障转移和冗余的增强，那么你可以使用Arbiter。Arbiter是一种特殊的Replica Set成员，它不储存任何用户数据（这就意味着他们可以使用非常小的服务器）。

总结：只可以使用偶数个Replica Set成员，但是可以使用Arbitter来削减成本。

没有join语句

MongoDB不支持join：如果你想在多个Collection中检索数据，那么你必须做多次的查询。

如果你觉得你手动做的查询太多了，你可以重设计你的数据模型来减少整体查询的数量。MongoDB中的文件可以是任何类型，那么可以轻易的对数据进行De-Normalize。这样就可以让它始终和你的应用程序保持一致。

总结：没有join不妨看一下如何设计数据结构模型。

Journaling

MongoDB使用内存映射文件并且每60秒向磁盘输出一次通知，这就意味着最大程度上你可能丢失60秒加上向硬盘输出通知这段时间内所有的数据。

为了避免数据丢失，MongoDB从2.0版本起就添加了Journaling（默认情况下开启）。Journaling把时间从60秒更改为100ms。如果数据库意外的停机，在启动之前它将会被重启用以确保数据库处于一致状态。这也是MongoDB与传统数据库最接近的地方。

当然Journaling会轻微的影响到性能，大约5%。但是对于多数人来说额外带来的安全性肯定是物有所值的。

总结：最好别关闭Journaling。

默认情况下没有身份认证

MongoDB在默认设置下并没有身份验证。MongoDB会认为自身处在一个拥有防火墙的信任网络。但是这不代表它不支持身份验证，如果需要可以轻松的开启。

总结：MongoDB的安全性可以通过使用防火墙和绑定正确的接口来保证，当然也可以开启身份验证。

Replica Set中损失的数据

使用Replica Set是提高系统可靠性及易维护的有效途径。这样的话，弄清节点间故障的发生及转移机制就变得至关重要。

Replica Set中的成员一般通过oplog（记录了数据中发生增、删、改等操作的列表）来传递信息，当其中一个成员发生变化修改oplog后，其他的成员也将按照oplog来执行。如果你负责处理新数据的节点在出错后恢复运行，它将会被回滚至最后一个oplog公共点。然而在这个过程中：丢失的“新数据”已经被MongoDB从数据库中转移并存放到你的数据目录‘rollback’里面等待被手动恢复。如果你不知道这个特性，你可能就会认为数据被弄丢了。所以每当有成员从出错中恢复过来都必须要检查这个目录。而通过MongoDB发布的标准工具来恢复这些数据是件很容易的事情。查看官方文档以了解更多相关信息。

总结：故障恢复中丢失的数据将会出现在rollback目录里面。

分片太迟

分片是把数据拆分到多台机器上，通常被用于Replica Set运行过慢时进行性能提升。MongoDB支持自动分片。然而如果你让分片进行太迟的话，问题就产生了。因为对数据的拆分和块的迁移需要时间和资源，所以如果当服务器资源基本上耗尽时很可能会导致在你最需要分片时却分不了片。

解决的方法很简单，使用一个工具对MongoDB进行监视。对你的服务器做最准确的评估，并且在占整体性能的80%前进行分片。类似的监视工具有：MMS、Munin（+Mongo
Plugin）和CloudWatch。

如果你确定从一开始就要分片处理，那么更好的建议会是选用AWS或者类似的云服务进行分片。而在小型服务器上，关机或者是调整机器明显比转移成千上万条数据块来的更直接一点。

总结：尽早的分片才能有效的避免问题。

不可以更改文件中的shard key

对于分片设置，shard key是MongoDB用来识别分块对应文件的凭证。当你插入一个文件后，你就不可以对文件的shard key进行更改。而这里的解决方案是把文档删除然后重新建立，这样就允许把它指定到对应的分块了。

总结：shard key不可以修改，必要的时候可以删除文件重新建立。

不可以对256G以上的Collection进行分片

重新回到分片太迟的问题上来 —— MongoDB不允许对增长到256G以上的Collection进行分片，之前版本的设置还没有256G。这个限定在以后肯定会被移除，而这里也没有更好的解决方案。只能进行重编译或者把大小控制在256G以下。

总结：在Collection达到256G以前进行分片。

唯一性索引与共享

索引的唯一性约束只能通过shard key来保证。

选择了错误的shard key

MongDB需要你选择一个shard key来将数据分片。如果选择了错误的shard key,更改起来将是件很麻烦的事情。

总结：选择shard key之前先阅读这个文档。

与MongoDB通信的未经加密

与MongoDB的连接默认情况下都是非加密的，这就意味你的数据可能被第三方记录和使用。如果你的MongoDB是在自己的非广域网下使用，那么这种情况是不可能发生的。

然而如果你是通过公网访问MongoDB的话，那么你肯定会希望你的通信是经过加密的。公版的MongoDB是不支持SSL的。庆幸的是可以非常简单的定制自己的版本。10gen的用户则拥有特别定制的加密版本。幸运的是大部分的官方驱动都支持SSL，但是小麻烦同样是不可避免的。点击查看文档。

总结：当用公网连接时，要注意和MongoDB的通信是未加密的。

事务

不像MySQL这些支持多行数据原子操作的传统数据库，MongoDB只支持单文件的原子性修改。解决这个问题的方法之一是在应用程序中使用异步提交的方式；另一个是：建立一个以上的数据存储。虽然第一种方法并不适用于所有情况，但是很显然比第二个来的要好。

总结：不支持对多文件事务。

日志预分配慢

MongDB可能会告诉你已经准备就绪，但事实上它还在对日志进行分配。如果你选择了让机器自行分配，而恰巧你的文件系统和磁盘速度又很慢，那么烦恼的事情发生了。通常情况下这不会成为问题，但是一旦出现了可以使用undocumented
flag –nopreallocj来关闭预分配。

总结：如果机器文件系统和磁盘过慢的话，那么日志的预分配也可能很慢。