MongoDB优化的几点原则

  • 1.查询优化
  1.  确认你的查询是否充分利用到了索引，用explain命令查看一下查询执行的情况，添加必要的索引，避免扫表操作。
  • 2.搞清你的热数据大小

可能你的数据集非常大，但是这并不那么重要，重要的是你的热数据集有多大，你经常访问的数据有多大(包括经常访问的数据和所有索引数据)。使用MongoDB，你最好保证你的热数据在你机器的内存大小之下，保证内存能容纳所有热数据。

  • 3.选择正确的文件系统

MongoDB的数据文件是采用的预分配模式，并且在Replication里面，Master和Replica Sets的非Arbiter节点都是会预先创建足够的空文件用以存储操作日志。这些文件分配操作在一些文件系统上可能会非常慢，导致进程被Block。所以我们应该选择那些空间分配快速的文件系统。这里的结论是尽量不要用ext3，用ext4或者xfs。

  • 4.选择合适的硬盘 
  1. 这里的选择包括了对磁盘RAID的选择，也包括了磁盘与SSD的对比选择。
  • 5.尽量少用in的方式查询

尤其是在shard上，他会让你的查询去被一个shand上跑一次， 如果逼不得已要用的话再每个shard上建索引。 优化in的方式是把in分解成一个一个的单一查询。速度会提高40-50倍

  • 6.合理设计sharding key

增量sharding-key：适合于可划分范围的字段，比如integer、float、date类型的，查询时比较快

随机sharding-key: 适用于写操作频繁的场景，而这种情况下如果在一个shard上进行会使得这个shard负载比其他高，不够均衡，故而希望能hash查询key，将写分布在多个shard上进行,考虑复合key作为sharding key， 总的原则是查询快，尽量减少跨shard查询，balance均衡次数少。

mongodb默认是单条记录16M，尤其在使用GFS的时候，一定要注意shrading-key的设计。

不合理的sharding-key会出现，多个文档，在一个chunks上，同时，因为GFS中存贮的往往是大文件，导致mongodb在做balance的时候无法通过sharding-key来把这多个文档分开到不同的shard上， 这时候mongodb会不断报错 [conn27669] Uncaught std::exception: St9bad_alloc, terminating。最后导致mongodb倒掉。

解决办法：加大chunks大小（治标），设计合理的sharding-key（治本）。

  • 7.mongodb可以通过profile来监控数据，进行优化。

查看当前是否开启profile功能 用命令db.getProfilingLevel() 返回level等级，值为0|1|2，

分别代表意思：0代表关闭，1代表记录慢命令，2代表全部

开启profile功能命令为 db.setProfilingLevel(level); #level等级，值同上 level为1的时候，慢命令默认值为100ms，更改为db.setProfilingLevel(level,slowms)如db.setProfilingLevel(1,50)这样就更改为50毫秒

通过db.system.profile.find() 查看当前的监控日志。

  • Ext4

Linux kernel自2.6.28开始正式支持新的文件系统 Ext4。 Ext4是Ext3的改进版，修改了Ext3中部分重要的数据结构，而不仅仅像Ext3对Ext2那样，只是增加了一个日志功能而已。Ext4 可以提供更佳的性能和可靠性，还有更为丰富的功能：

1.与Ext3兼容。执行若干条命令，就能从Ext3在线迁移到Ext4，而无须重新格式化磁盘或重新安装系统。原有Ext3数据结构照样保留，Ext4作用于新数据，当然，整个文件系统因此也就获得了Ext4所支持的更大容量。

2.更大的文件系统和更大的文件。较之Ext3目前所支持的最大16TB文件系统和最大2TB文件，Ext4分别支持1EB(1,048,576TB，1EB=1024PB，1PB=1024TB)的文件系统，以及16TB 的文件。

3.无限数量的子目录。Ext3目前只支持32,000个子目录，而Ext4支持无限数量的子目录。

4.Extents。Ext3 采用间接块映射，当操作大文件时，效率极其低下。比如一个 100MB 大小的文件，在Ext3中要建立25,600个数据块(每个数据块大小为 4KB)的映射表。而Ext4引入了现代文件系统中流行的extents概念，每个 extent 为一组连续的数据块，上述文件则表示为“该文件数据保存在接下来的25,600个数据块中”，提高了不少效率。

5.多块分配。当 写入数据到 Ext3 文件系统中时，Ext3 的数据块分配器每次只能分配一个 4KB 的块，写一个 100MB 文件就要调用 25,600 次数据块分配器，而 Ext4 的多块分配器“multiblock allocator”(mballoc) 支持一次调用分配多个数据块。

6.延迟分配。Ext3的数据块分配策略是尽快分配，而 Ext4 和其它现代文件操作系统的策略是尽可能地延迟分配，直到文件在 cache 中写完才开始分配数据块并写入磁盘，这样就能优化整个文件的数据块分配，与前两种特性搭配起来可以显著提升性能。

7.快速 fsck。以前执行 fsck 第一步就会很慢，因为它要检查所有的 inode，现在 Ext4 给每个组的 inode 表中都添加了一份未使用 inode 的列表，今后 fsck Ext4 文件系统就可以跳过它们而只去检查那些在用的 inode 了。

8.日志校验。日志是最常用的部分，也极易导致磁盘硬件故障，而从损坏的日志中恢复数据会导致更多的数据损坏。Ext4的日志校验功能可以很方便地判断日志数据是否损坏，而且它将 Ext3 的两阶段日志机制合并成一个阶段，在增加安全性的同时提高了性能。

9.“无日志”(No Journaling)模式。日志总归有一些开销，Ext4允许关闭日志，以便某些有特殊需求的用户可以借此提升性能。

10.在线碎片整理。尽管延迟分配、多块分配和extents能有效减少文件系统碎片，但碎片还是不可避免会产生。Ext4支持在线碎片整理，并将提供e4defrag工具进行个别文件或整个文件系统的碎片整理。

11.inode 相关特性。Ext4 支持更大的inode，较之Ext3默认的inode大小128字节，Ext4为了在 inode 中容纳更多的扩展属性(如纳秒时间戳或inode版本)，默认inode大小为256字节。Ext4 还支持快速扩展属性(fast extended attributes)和inode保留(inodes reservation)。

12.持久预分配(Persistent preallocation)。 P2P 软件为了保证下载文件有足够的空间存放，常常会预先创建一个与所下载文件大小相同的空文件，以免未来的数小时或数天之内磁盘空间不足导致下载失败。 Ext4在文件系统层面实现了持久预分配并提供相应的API(libc 中的 posix_fallocate())，比应用软件自己实现更有效率。

13.默认启用 barrier。磁 盘上配有内部缓存，以便重新调整批量数据的写操作顺序，优化写入性能，因此文件系统必须在日志数据写入磁盘之后才能写commit记录，若commit 记录写入在先，而日志有可能损坏，那么就会影响数据完整性。Ext4默认启用barrier，只有当barrier之前的数据全部写入磁盘，才能写 barrier之后的数据。(可通过“mount -o barrier=0″命令禁用该特性。)