MongoDB是目前最流行的NoSQL数据库，越来越多的DBA开始深入研究MongoDB。当然关注的人越多，暴露问题的机会也就越多，有不少用户开始抱怨MongoDB有这样的不足有那样的限制，对此伦敦MongoDB用户组的创始人Russell Smith特意在博客中进行了解答。他告诫用户，虽然MongoDB有一定的限制，但是只需一点点技巧就完全能够避免这些问题。以下就是Smith给MongoDB用户的一些建议：

　　1、MongoDB分成32位版本和64位版本，由于MongoDB使用内存映射文件，所以32位版本只能存储2GB左右的数据。建议存储更多数据的用户使用64位版本。

　　2、MongoDB是文档型数据库，数据以BSON形式存储在文档中。最新版本的MongoDB能够支持最大16 MB的文档大小。建议用户尽量不要存储大型对象，将文档控制在16 MB以内。

　　3、MongoDB的写入和更新速度非常快，所以错误提示并不明确。要确保写入正确，建议用户使用getLastError或者使用安全写入。

　　4、关系型数据库往往会有预定义的schema，你想添加额外的列就需要在整个表上添加。MongoDB没有这个约束，这使得开发和管理变得更简单。但这并不意味着你就可以完全忽视MongoDB的schema设计，一个设计良好的schema能够让MongoDB的性能达到最佳。

　　5、MongoDB的更新在默认情况下会使用类似于传统数据库的LIMIT语句，即LIMIT 1。因此更新不会影响到所有的文档，如果你想要一次更新许多文档，那么请把multi设为true。

　　6、MongoDB默认情况下是区分大小写的，例如db.people.find({name: ‘Russell’}) 和db.people.find({name: ‘russell’})就是不一样的。所以用户需要知道MongoDB的大小写限制。

　　7、传统数据库中，如果插入错误的数据类型，通常会提示错误或者强制转换成预定义的数据值。MongoDB中没有这种限制，所以输入错误数据类型不会出现提示。建议用户确保输入正确的数据类型。

　　8、全局锁是一直被MongoDB用户诟病的特性，MongoDB 2.2中增加了数据库级锁，这是一个很大的改进。建议用户使用稳定版的MongoDB 2.2数据库，避免全局锁限制。

　　9、过期版本MongoDB用户在下载程序包时会出问题，建议用户使用10gen最新版本的官方程序包。

　　10、Replica Set是MongoDB中受关注最多的功能，它能为MongoDB集群增加冗余并提供良好的读性能。但由于Replica Set的选举机制，必须保证Replica Set成员数目为奇数。如果是偶数的话，主节点宕机就会导致其他节点变为只读。解决方法也可以使用一个仲裁节点(arbiter)，它也是一个Replica Set的成员，但并不存储用户数据。所以请记住设置Replica Set成员时要定为奇数。

　　11、MongoDB中不存在join，你要针对多个集合进行数据检索的时候，必须使用多个查询。所以当你遇到这个问题时，可以考虑重新设计MongoDB的schema。

　　12、Journaling日志是MongoDB中非常好的功能，能够增强节点的可用性。在2.0版本之后，MongoDB默认是开启Journaling日志功能的。虽然Journaling日志会对数据库性能造成一定的影响，但这部分影响是可以忽略的。因此建议用户开启Journaling功能，特别是对于可用性要求较高的用户。

　　13、MongoDB默认情况下是没有认证功能的，因此建议用户使用防火墙对MongoDB进行保护。

　　14、Replica Set的工作是通过传送oplog来完成的，主节点发生故障后，新的数据将会存放在数据目录下的一个特定文件夹内，即rollback文件夹。你可以用来手动完成数据恢复。所以在每次故障发生之后，你一定要看看这个文件夹，MongoDB自带的工具就能够帮助你轻松地完成手动数据恢复。

　　15、跨服务器的数据拆分中，Sharding是一个有效的方法。MongoDB中支持自动化Sharding，但是对数据库性能会造成很大影响。因此建议用户尽早进行Sharding，使用MMS、Munin (+ Mongo plugin)和CloudWatch等工具对MongoDB进行监控，确保系统资源使用达到80%之前就完成Sharding工作。

　　16、MongoDB使用shard key来决定特定的文档在哪个分片上，当插入一个文档之后，你是无法更新shard key的。这里建议用户删除文档并重新插入，这样就能够将其分配到合适的分片上。

　　17、MongoDB对分片的限制还包括集合的大小，当超过256 GB的时候，MongoDB将不允许进行分片。相信10gen公司会在未来放弃这一限制，但在此之前用户需要留意。

　　18、MongoDB中跨分片并没有强制要求唯一性，MongoDB只针对独立的分片进行强制而非全局性。当然除shard key之外。

　　19、进行拆分的时候，MongoDB会要求你选择一个键。用户需要注意选择正确的键，否则会造成不必要的麻烦。如何进行选择并无定式，主要取决于你的应用，比如针对news feed使用时间戳就是错的。在下一版本中，MongoDB将对此进行改进。

　　20、MongoDB连接默认情况下是不加密的，也就是说你的数据是能够被第三方记录和使用的。所以你在公共网中访问MongoDB的话，就一定要进行加密。

　　21、MongoDB只支持单一文档的原子性，这一点与传统的数据库有所不同，如MySQL。因此MongoDB中跨多个文档是不提供内置的transaction支持的。

　　22、当MongoDB显示ready的时候，其实内部还在进行journal的配置。因此针对速度较慢的文件系统，MongoDB的journal配置也会很慢。

　　23、不建议尝试NUMA + Linux + MongoDB的组合，如果你的MongoDB跑在NUMA服务器上，建议将它关掉。

　　24、在Linux上运行MongoDB遭遇segfault错误时，这主要是因为open files / process限制过低。建议用户将限制设定为4K+。