有什么：mongodb有什么缺点

mongodb有甚么缺点

mongodb的缺点有：1、mongodb不支持事务操作；2、使用mongodb数据库存储数据占用空间过大；3、mongodb没有如mysql那样成熟的保护工具；4、mongodb在集群分片中的数据散布不均匀；5、在mongodb中延续插入大量数据，其写入性能会有较大波动；6、使用mongodb数据库时，其单机可靠性比较差。

下面是详细介绍：

与关系型数据库相比，MongoDB的优点：

①弱一致性（终究一致），更能保证用户的访问速度：

举例来讲，在传统的关系型数据库中，一个COUNT类型的操作会锁定数据集，这样可以保证得到“当前”情况下的较精确值。这在某些情况下，例 如通过ATM查看账户信息的时候很重要，但对Wordnik来讲，数据是不断更新和增长的，这类“较精确”的保证几近没有任何意义，反而会产生很大的延 迟。他们需要的是一个“大约”的数字和更快的处理速度。

但某些情况下MongoDB会锁住数据库。如果此时正有数百个要求，则它们会堆积起来，造成许多问题。我们使用了下面的优化方式来避免锁定：

每次更新前，我们会先查询记录。查询操作会将对象放入内存，因而更新则会尽量的迅速。在主/从部署方案中，从节点可使用“-pretouch”参数运行，这也能够得到相同的效果。 

使用多个mongod进程。我们根据访问模式将数据库拆分成多个进程。 

②文档结构的存储方式，能够更便捷的获得数据。

对一个层级式的数据结构来讲，如果要将这样的数据使用扁平式的，表状的结构来保存数据，这不管是在查询或获得数据时都十分困难。

③内置GridFS，支持大容量的存储。

  GridFS是一个出色的散布式文件系统，可以支持海量的数据存储。

  内置了GridFS了MongoDB，能够满足对大数据集的快速范围查询。

④内置Sharding。

提供基于Range的Auto Sharding机制：一个collection可依照记录的范围，分成若干个段，切分到区分的Shard上。

Shards可以和复制结合，配合Replica sets能够实现Sharding+fail-over，区分的Shard之间可以负载均衡。查询是对 客户端是透明的。客户端履行查询，统计，MapReduce等操作，这些会被MongoDB自动路由到后真个数据节点。这让我们关注于自己的业务，适当的 时候可以无痛的升级。MongoDB的Sharding设计能力较大可支持约20 petabytes，足以支持一般利用。

这可以保证MongoDB运行在低价的PC服务器集群上。PC集群扩充起来非常方便并且本钱很低，避免了“sharding”操作的复杂性和本钱。

⑤第三方支持丰富。(这是与其他的NoSQL相比，MongoDB也具有的优势)

现在网络上的很多NoSQL开源数据库完全属于社区型的，没有官方支持，给使用者带来了很大的风险。

而开源文档数据库MongoDB背后有商业公司10gen为其提供供商业培训和支持。

而且MongoDB社区非常活跃，很多开发框架都迅速提供了对MongDB的支持。很多知名大公司和网站也在生产环境中使用MongoDB，愈来愈多的创新型企业转而使用MongoDB作为和Django，RoR来搭配的技术方案。

⑥性能优越：

在使用处合下，千万级别的文档对象，近10G的数据，对有索引的ID的查询不会比mysql慢，而对非索引字段的查询，则是全面胜出。 mysql实际没法胜任大数据量下任意字段的查询，而mongodb的查询性能实在让我惊讶。写入性能一样很使人满意，一样写入百万级别的数 据，mongodb比我之前试用过的couchdb要快很多，基本10分钟以下可以解决。补上一句，视察进程中mongodb都远算不上是CPU杀手。

与关系型数据库相比，MongoDB的缺点：

①mongodb不支持事务操作。

  所以事务要求严格的系统（如果银行系统）肯定不能用它。(这点和优点①是对应的)

②mongodb占用空间过大。

  关于其缘由，在官方的FAQ中，提到有以下因素有哪些：

1、空间的预分配：为避免构成过量的硬盘碎片，mongodb每次空间不足时都会申请生成一大块的硬盘空间，而且申请的量从64M、128M、256M那 样的指数递增，直到2G为单个文件的较大体积。随着数据量的增加，你可以在其数据目录里看到这些整块生成容量不断递增的文件。

2、字段名所占用的空间：为了保持每一个记录内的结构信息用于查询，mongodb需要把每一个字段的key-value都以BSON的情势存储，如果 value域相对key域其实不大，比如寄存数值型的数据，则数据的overhead是较大的。一种减少空间占用的方法是把字段名尽可能取短一些，这样占用 空间就小了，但这就要求在易读性与空间占用上作为权衡了。我曾建议作者把字段名作个index，每一个字段名用一个字节表示，这样就不用担心字段名取多长 了。但作者的耽忧也不无道理，这类索引方式需要每次查询得到结果后把索引值跟原值作一个替换，再发送到客户端，这个替换也是挺耗费时间的。现在的实现算是 拿空间来换取时间吧。

3、删除记录不释放空间：这很容易理解，为避免记录删除后的数据的大范围移动，原记录空间不删除，只标记“已删除”便可，以后还可以重复利用。

4、可以定期运行db.repairDatabase()来整理记录，但这个进程会比较缓慢

③MongoDB没有如MySQL那样成熟的保护工具，这对开发和IT运营都是个值得注意的地方。

MongoDB合适存储一些关系简单、数据量又很大的数据，比如我们的平台上虚拟机的监控信息，包括内存、IO、CPU、网络等数据，每隔几秒就收集一次数据，每周、每个月，量很大，而且旧的监控数据也不会保存太长时间，就使用的mongodb来存储这些数据；

另外mongodb的集群部署相对照较简单，易于扩大；比如主从复制，在mongo.conf配置几个参数就OK了；分片集群的配置也比较简单。还支持使用命令行来进行动态地添加和删除节点；

Mongodb的优点与不足

（1）Mongodb的不足的地方

1、在集群分片中的数据散布不均匀

2、单机可靠性比较差

3、大数据量延续插入，写入性能有较大波动

4、磁盘空间占用比较大

（2）Mongodb的过人的地方

1、无模式

2、查询与索引方式灵活，是最像SQL的Nosql

3、支持复制集、主备、互为主备、自动分片等特性