ShaunLi.com

必看 8 分钟 5 步优化 MongoDB 以及其它数据库

June 9 2014

原文链接

Jared RosoffScale Out Camp 发表了一篇简洁、有效、有趣和令人信服的《8 分钟 MongoDB 教程》描述了如何进行 MongoDB 优化。文中的方法不仅限于 MongoDB,还可应用到绝大多数数据库,比如查询优化、找出你的热数据、调整文件系统、选择正确的磁盘设备、分片。下面分别对 5 种策略进行说明:

  1. 查询优化:用 B-tree 搜索的速度显然比全表扫描来的快,所以你需要优化你的查询语句。用 explain 来分析你的查询语句,如果返回的结果现实这个查询用到了 cursor 那么它会是一个全表扫描,也就是说它会非常慢。分析有多少条记录会满足查询条件,以及查询会执行多长时间。改进的方法就是为其增加索引。不管你是有 1 台还是有 100 台服务器。
  2. 找出你的热数据尺寸:在数据库前面使用 Memcached 其实挺可笑的,因为现在内存很便宜,你可以使用大量的内存来缓存数据库内容,MongoDB 就是这样干的。热数据 = 活跃记录 + 使用过的索引。在内存中命中数据是非常快的,而从磁盘获取数据就非常慢。假设你有上十亿的用户,但只有十万用户当前是活跃的,那么你的热数据尺寸就是十万条。你需要规划足够的内存来存放那十万条热数据,保证他们能够从内存而不是磁盘里读取,别忘了索引也是需要占用内存的。
  3. 调整文件系统:性能问题往往根源是在文件系统。比如 EXT3 已经过时了,请使用 EXT4、XFS 和其它高性能的文件系统。对于数据库来说并不需要每次访问都去更新文件,所以关掉文件的访问时间跟踪功能,不然会有很多不必要的磁盘写操作。在 EXT3 文件系统预分配一个 2GB 大小的文件是非常耗时的,因为它必须得在分配时完整初始化整个文件。
  4. 选择正确的磁盘设备:寻道时间是需要关注的问题,因为大多数时候磁盘的 IO 操作是随机的。寻道时间取决于机械臂在磁盘上来回移动的速度,磁盘的平均寻道操作能力是每秒钟能完成 200 次。高速磁盘之所以读取数据更快,是因为他们有更高的带宽容量,除此之外他们的寻道时间并没有区别。使用单个磁盘时,你可以获得每秒 200 次寻道;而使用 RAID 0(跨多个磁盘),3 块磁盘可以让你获得每秒 600 次的寻道速度;那么使用 RAID 10(镜像 + 跨越),6 块磁盘甚至能让你获得每秒 1200 次寻道。所以要考虑用 RAID 来进行优化。如今的 SSD 存储就更夸张了,一次寻道只要 0.1 毫秒,是机械磁盘的 50 倍,更适用于随机的读取操作。
  5. 分片:如果你的程序性能很差,索引又建的不正确,磁盘设备的速度也很慢,那么单点的性能也就非常差了。改善这种情况的方法就是用分片来做横向扩展,分片可以让你把系统负责分散到由更多机器组成的高可用的 replica sets 集群。数据将会按一定范围被切分成很多的区块,然后横向扩展到上百台服务器,上千次的写操作在被拆分后每台服务器只需要处理十来次操作。分片让横向扩展变得容易。