基于MongoDB的档案管理系统设计与实现 (3)
MongoDB支持备份和故障恢复。它不仅支持复制服务器与客户机服务器之间传递的数据，复制服务器与服务器之间传递的数据，还提供冗余、自动故障转移。
MongoDB通过自动分片，支持具有扩展性的云计算层次，可动态添加其他的机器。
完善的文档支持与驱动支持，开发者可以再多种环境语言下使用，加之MongoDB官方提供良好的技术支持，可以解决很多问题，所以MongoDB是很有前景的数据库技术。
一位资深工程师是这样描述对MongoDB数据库的感觉，“居然不自动回滚!不用它不行，速度实在太快了!”这就足够说明MongoDB在查询和写入性能方面的优越性，有用户报告称其与MySQL相比，对有索引的ID的查询速度不会慢，而在非索引字段的查询更是优胜[4][5][6][7]。
2.1.2 MongoDB的主要缺点及局限
2011年下半年，Hacker News上出现了一篇名为《Don’t Use MongoDB》的文章，这篇文章很快在业界传播开来，笔者以用户的名义，声称饱受MongoDB之苦，列举了数条MongoDB的“罪行”。10gen的CTO(首席技术官)迅速对此事件作出了反应，并且给出了相应的回应(其中有些问题是没有任何证据能够表明，或者说没有收到用户的反馈报告，理论上也是不太可能出现)。这一事件以一个戏剧性的结尾收场了：原来这篇文章只是该文作者的一个恶作剧，他声称只是想通过这个实验，以显示要想控制一个人的思文是多么的容易。
然而，所谓无风不起浪，这篇文章之所以显得格外真实，不正是抓住了许多用户心中的疑虑，而其中某几条“罪行”也是真真切切的。若是要想客观地对MongoDB的欠缺进行评价，结合在2012年举办的MongoDB 北京开发者聚会上Stone Gao先生发表的演讲《Challenges with MongoDB》（MongoDB的挑战）以及其他参考资料和个人经验简述如下：
首先是全局锁。不支持写锁，包括对集合和文档，毫无疑问，这很大程度上降低了系统的执行效率。10gen表示目前已经进行了优化，在写操作方面做了很大的改进。但是在集合锁出现以前，这个问题还是难以得到根本的解决，因此在必须频繁使用写锁的情况下，MongoDB并不适用。
其次，需要完善自动分片的功能。在某些条件下，分片中的数据并不平衡，甚至可能需要用户关掉自动平衡功能，自行制定平衡策略。
再次，由于是以Key-value（关健值）的形式储存文档，那么在key域较大时，空间的浪费很是惊人。这促使开发人员在对存储空间较为敏感的情况下，必须缩小表示Key值的字段，还需要在开发文档中进行说明[8][9]。
最后，10gen被指责对用户反馈不够敏感，一些固有的技术或性能问题(如上文提到的全局锁、自动分片等)即使是在用户反馈后，也并没有得到及时解决[9]。
2.1.3 MongoDB支持的数据类型
在基于MongoDB的档案管理系统中，数据的存储是极其重要的一部分，本系统选择使用非关系型数据库MongoDB进行存储系统数据。MongoDB对于数据存储具有强大的安全性、稳定性和可靠性。在对数据库进行架构设计时，第一步就是把握好整体项目的各类用户需求，还要包含未来可能添加的需求数据。
MongoDB在使用前，相应的数据库并不需要事先创建好，表的结构也不要进行设计。
在MongoDB中，取代“表”这一个概念的是“集合”（Collction）。当然，没有表也就没有数据记录的概念，有的是文档，我们可以理解为，MongoDB中的”文档“就是“对象”[10]。