MongoDB 应用二三事

最近，随着“大数据时代”的到来，NoSQL数据库作为数据库行业的后起之秀，在短短的几年之间，得到了迅猛的发展，而如今还大有取代RDBMS之势。在众多的NoSQL数据库中，名气最大的莫过于MongoDB了。MongoDB于2009年2月推出第一个版本，至今的5年多时间，其已经发展成为在DB Engine影响力排行世界第5位的数据库。

MongoDB具有以下几个特点：

1）  非结构化的数据结构，保证了适应多种多样的数据类型和形式，无需预先设计数据结构和表模式。

2）  水平扩张，理论上是可以无限扩展的水平扩展性。

3）  多样的功能和平台架构支持，经过其开发团队的自身推进以及Mongo开源社区的蓬勃发展，使得MongoDB支持越来越多的开发语言和大数据架构，同时也不断丰富了他的功能。

而本人作为一个大数据相关的从业人员，在工作中不断地学习MongoDB的知识，我自己也将其运用到了一些实际应用场景当中。

在使用MongoDB的过程中，其性能表现虽然中规中矩，也很好的体现了NoSQL的基本特性，但是实际应用场景之中，MongoDB仍然有不少功能上的不足以及性能上可改进之处。

1.      性能

首先我想谈谈MongoDB的性能表现。作为NoSQL数据库，MongoDB的读写查等许多操作的性能方面自然是领先于RDBMS的，然而在与其他的NoSQL产品比较时，MongoDB其实并没有太大的优势。

根据网上之前公布的一些权威机构的测试结果，MongoDB的性能在众多NoSQL数据库中只能说是一般般。读写性能方面，相比于HBase，MongoDB在少分区下还能基本持平，但是在多分区的情情景下性能表现也只有HBase的1/3甚至1/5。而与这方面的佼佼者Cassandra相比，Mongo在各项对比中，也只能达到Cassandra的1/10甚至更少。

http://planetcassandra.org/nosql-performance-benchmarks

而与存储方式同类的Couchbase相比，MongoDB似乎也不占优势。

http://www.csdn.net/article/2013-04-15/2814886-nosql-benchmark

http://www.couchbase.com/press-releases/couchbase-blows-past-competition-nosql-performance-benchmark

从以上两个测试报告也可以看出，作为NoSQL领军人物的MongoDB，在性能表现上确实差强人意。

2.      功能

2.1  事务

事务作为RDBMS一个非常实用的特性，在处理高可用性高安全性的情景，如企业级的应用时，事务有它独到的优点。

MongoDB并没有事务处理的功能，而在原子性的保证方面，其只能做到单个文档级别，不能支持多文件的原子性。

如今，MongoDB在开源之后应用层也有民间开发的集成了事务功能的组件，但是应用层的实现在数据库的通信上面不能保证性能和可靠性，也就很难提供更专业和完善的支持。

2.2  SQL支持

SQL作为已经使用了几十年的数据库操作语言，不仅在应用上，有着完善多样的接口和驱动，同时，SQL的思维在众多数据库使用者和DBA的脑中已经根深蒂固，想要迅速的改变这种思维方式是困难也没有必要的。所以，NoSQL对于SQL语句的支持也很重要。MongoDB并不具备这样的原生支持，同样，应用层的一些驱动并不能很好的结合数据库本身，完全发挥它的能量。

相反，有许多的同类产品已经提供自带的SQL语句处理，例如通过对接PostgreSQL来实现SQL语句支持，这样能让开发者更快的熟悉和转入NoSQL。

2.3  锁

MongoDB 只有库级粒度的锁，这意味着当 MongoDB 一个写锁处于占用状态时，其它的读写操作都需要等待。虽然因为改动过的锁处理机制让其能保证较高的并发量和高性能（感兴趣可以另外介绍）。

可是基本保证并能完全避免问题，如果数据操作不当，依然会导致长时间占用写锁，比如前台创建索引操作，当出现这种情况的时候，整个数据库就处于完全阻塞状态，无法进行任何读写操作，情况十分严重。

2.4  自动分区

体现MongoDB水平扩展能力的重要一个功能就是自动分区（auto-sharding），然而MongoDB的自动分区在实际应用当中也存在着不少问题。1）在高负载的情况下，MongoDB的自动分区功能会出现不可用或者运行缓慢的情况。2）可以看到网上有不少使用者在系统自动分区后出现数据错误或者数据丢失的情况（最出名的当然是Foursquare的宕机事件）。3）我自己在实际应用中也出现过类似问题，也就是MongoDB在高负载下，出现了数据的丢失，并且还没办法恢复。

2.5  Join

MongoDB不支持Join操作，需要在多个Collection中查找时，不能使用Join将多个Collection合并，只能分别在每个Collection中运行一次存储操作。

3.      安全性

MongoDB的原生数据库系统安全性虽然也是它极力展示的一个特性之一，但是事实上

MongoDB的安全性设计仍有缺陷。首先，MongoDB的默认安全设置为否，这给了很多不熟悉MongoDB特点的新人或是第一次转换NoSQL的企业用户一个非常大的安全隐患。此外，MongoDB也在网上被报道一些安全漏洞或者黑客攻击事件，包括非法数据获取、数据的无故丢失等这些事件究其原因也是安全保障设计的缺陷。

4.      易用性

易用上来说，MongoDB的表现也是中规中矩，虽然可以使用Javascript的Shell工具以及界面化的MMS，但是其操作仍有优化的空间。此外，MongoDB不具备自动安装部署功能。MongoDB的安装部署必须全手动操作，这样不仅比较耗时，对于新手来说可能因为不熟悉而忽略或不能完成一些系统配置的工作，导致安装失败或是使用过程中出现异常。

原文：http://blog.csdn.net/shining1110/article/details/40039729