5步优化MongoDB以及其它数据库

Jared Rosoff 在 Scale Out Camp 发表了一篇简洁、有效、有趣和令人信服的《8 分钟 MongoDB 教程》描述了如何进行 MongoDB 优化。

文中的方法不仅限于 MongoDB，还可应用到绝大多数数据库，比如查询优化、找出你的热数据、调整文件系统、选择正确的磁盘设备、分片。下面分别对 5 种策略进行说明：

查询优化：用 B-tree 搜索的速度显然比全表扫描来的快，所以你需要优化你的查询语句。用 explain来分析你的查询语句，如果返回的结果现实这个查询用到了 cursor 那么它会是一个全表扫描，也就是说它会非常慢。分析有多少条记录会满足查询条件，以及查询会执行多长时间。改进的方法就是为其增加索引。不管你是有 1 台还是有 100 台服务器。

找出你的热数据尺寸：在数据库前面使用 Memcached 其实挺可笑的，因为现在内存很便宜，你可以使用大量的内存来缓存数据库内容，MongoDB 就是这样干的。热数据 = 活跃记录 + 使用过的索引。在内存中命中数据是非常快的，而从磁盘获取数据就非常慢。假设你有上十亿的用户，但只有十万用户当前是活跃的，那么你的热数据尺寸就是十万条。你需要规划足够的内存来存放那十万条热数据，保证他们能够从内存而不是磁盘里读取，别忘了索引也是需要占用内存的。

[[190185]] 

调整文件系统：性能问题往往根源是在文件系统。比如 EXT3 已经过时了，请使用 EXT4、XFS 和其它高性能的文件系统。对于数据库来说并不需要每次访问都去更新文件，所以关掉文件的访问时间跟踪功能，不然会有很多不必要的磁盘写操作。在 EXT3 文件系统预分配一个 2GB 大小的文件是非常耗时的，因为它必须得在分配时完整初始化整个文件。

选择正确的磁盘设备：寻道时间是需要关注的问题，因为大多数时候磁盘的 IO 操作是随机的。寻道时间取决于机械臂在磁盘上来回移动的速度，磁盘的平均寻道操作能力是每秒钟能完成 200 次。高速磁盘之所以读取数据更快，是因为他们有更高的带宽容量，除此之外他们的寻道时间并没有区别。使用单个磁盘时，你可以获得每秒 200 次寻道;而使用 RAID 0(跨多个磁盘)，3 块磁盘可以让你获得每秒 600 次的寻道速度;那么使用 RAID 10(镜像 + 跨越)，6 块磁盘甚至能让你获得每秒 1200 次寻道。所以要考虑用 RAID 来进行优化。如今的 SSD 存储就更夸张了，一次寻道只要 0.1 毫秒，是机械磁盘的 50 倍，更适用于随机的读取操作。

分片：如果你的程序性能很差，索引又建的不正确，磁盘设备的速度也很慢，那么单点的性能也就非常差了。改善这种情况的方法就是用分片来做横向扩展，分片可以让你把系统负责分散到由更多机器组成的高可用的 replica sets 集群。数据将会按一定范围被切分成很多的区块，然后横向扩展到上百台服务器，上千次的写操作在被拆分后每台服务器只需要处理十来次操作。分片让横向扩展变得容易。