MongoDB的8个方面

　　应用性能的高低依赖于数据库性能，MongoDB 是一个基于分布式文件存储的数据库。它由 C++ 语言编写，是为 WEB 应用提供可扩展的高性能数据存储解决方案。MongoDB 是一个介于关系数据库和非关系数据库之间的产品，是非关系数据库当中功能最丰富，最像关系数据库的。

　　本文针对实时监控 MongoDB 数据库，总结了一些使用的工具以及需要重点注意的性能方面。

　　1，实时监控 MongoDB 工具

　　MongoDB 用自己的工具来统计现在运行的 MongoDB 服务器的数据，并进行实时报告分析：

　　mongostat：可以展示像 opcounts，lock%，内存使用以及副本集更新状态等关键指标，因为可以实时看到发生的状况，所以一般用于故障除疑。

　　sh.status()：返回你的分片集群的状态，尤其是每块碎片的数量，显示关于分片集群的现有区块的信息的格式化的报告，如果区块大于等于20就不显示详细块信息。

　　mongotop：mongostat 提供的是全局指标，而 mongotop 则提供追踪 MongoDB 实例花费在读写操作数据的时间指标，提供每个集合级别的统计数据。

　　is.status()：返回的是当前服务器节点执行操作后副本集的状态，通过这个来实时查看集群的变化。

　　2，连接数

　　连接到 MongoDB 的每个连接都有助于追踪系统所需的内存的开销。这最初由 Unix 通过 ulimit 来设置限制，但随后成为由服务器资源，特别是存储器限制。

　　过高数量的连接数还可以指明问题，例如你的应用程序代码打开太多的连接，造成某地方产生很高的 lock% 。

　　有时客户端和数据库之间的连接数超出服务器处理请求的能力，这可能会导致在 MongoDB 环境的应用程序性能的下降。

　　3，内存使用量和页面错误

　　内存可能是你可以给 MongoDB 的最重要的资源，因为 Mongodb 是相当吃内存的，如果控制不好的话，mongodb会挂掉。。。所以你要确保你给的内存总是有足够的!经验之谈是提供符合索引数量的足够的 RAM，如果可能的话，为所有数据提供足够的内存。

　　常驻内存是这里的关键指标，MongoDB 内存 mem 记录了 Mongod 的系统架构和内存使用。

　　页面错误和内存相关因为页面错误发生时是 MongoDB 去磁盘里面查找数据而不是内存中，如果内存的数量不能满足性能需求，那么你将会看到页面错误，随着页面错误率的上升，opcounters 最终会低于期望值，所以这时你应该增加可用的 RAM。

　　4，锁

　　MongoDB 使用一个全局锁来确保一致性。但是，如果某些操作是长时间运行的或形成一个队列，操作等待锁就会大大降低应用程序性能。

　　在 MongoDB 2.6版本中，锁是数据库级别的，一直持续 MongoDB 2.8，写操作都是一个全局性数据库锁，MongoDB 使用的这种「readers-writer」锁，虽然支持并发但有很大的局限性，当一个读锁存在，许多读操作可以使用这把锁，然而当一个写锁存在时，其它读写操作不能使用共享这个锁，写入优先于读取，当两个操作一个读取和一个写入正在等待锁，MongoDB 会授予写锁，所以如果写锁发生的过于频繁，那么你应用的性能出现文件也就不奇怪了。当然如果你的应用中真的有大量的写操作，可以考虑 Cassandra 数据库。

　　5，数据库操作

　　不多说，实时掌握数据库操作的统计数据以及复制和分片操作的详细信息，确保每秒数据库操作(inserts，query，update，delete，getmore 等 command 命令)的总数有助于分析和跟踪数据库的负载。

　　6，片键

　　分片是在多台计算机存储数据记录的过程中 MongoDB 来满足数据增长需求的特有方式。随着数据量的增加，一台服务器可能不足以存储数据或提供大量的读写操作。分片解决了水平扩展的问题，通过分片，可以添加更多的机器来支持数据增长以及满足读写操作的需求。

　　MongoDB 在集合的水平上分割数据和分片，通过一个片键( shard key )来分割分片。

　　7，复制集

　　MongoDB 复制集通过将数据部署在多个不同的服务器上，防止因单机故障而造成数据的丢失，借助数据冗余来提高数据的可靠性和安全性。而且还可以通过复制技术构建分布式数据库，提高系统的访问性能和安全性。

　　复制集同步数据过程如下所示：Primary 节点写入数据，Secondary 通过读取 Primary 的 oplog 得到复制信息，开始复制数据并且将复制信息写入到自己的 oplog，复制延迟是 Primary 节点上写入到 Secondary 节点读取 oplog 再写入操作的延迟，复制延迟可能是一个显著的问题，严重影响 MongoDB 副本集部署，过度复制延迟使「滞后」的节点将很快成为 Primary ，增加了分布式读操作不一致的可能性。

　　为了将一个集合分片，需要选择一个片关键字。一个片键是一个索引字段，或是存在于每个集合文档中的一个复合索引字段。选择正确的分片键可以对应用性能，功能以及数据库和集群的运作有很大的影响，合适的分片键选择取决于你的数据的架构和应用程序的查询和写入数据的方式。而且 Mongodb 数据库是否能高效运转也取决于你指定了文档的哪个字段作为分片字段。由于分片字段都是预先选择且选定后无法更改的，而且考虑到 MongoDB 纵向扩展能力的限制，选择时就需要深思熟虑了。分片键应该满足以下条件：

　　分配 -- 分片键最糟糕的情况是自增的值(当所有的写操作将被平衡到单个碎片时就意味着"热碎片"的发生，而这就是瓶颈)。理想的分片重点应该读和写是尽可能多的"随机分布"。

　　理想的片键主要功能应该是用于查询，如果大部分的查询请求都能够命中尽可能少的分片那就最好了。

　　一个好的片键使得 MongoDB 分配内容变的容易。MongoDB 会根据你的设置将你的数据划分到有着相同片键的数据块 (Chunk) 中。而后这些数据块将根据片键的大致顺序分散到副本集中。

　　8，集成监控工具 Cloud Insight

　　想要看到以上数据指标，需要一定的监控手段，MongoDB 本身就有一堆自己的工具，此外还有开源工具以及第三方厂家提供的监控软件，总结为一点，监控非常重要，Cloud Insight全面监控 MongoDB，一工具在手，默认60个数据指标，MongoDB 发生什么都了然于心。