MGO 设计调优。

真的是那句话,不是你不行,知识你不了解。而已。

1. 肯定是不能加两个索引了。
   1. 索引的代价实在是太大了,不但占用内存还还大量损失查询性能,真心不能忍耐啊。
2. 设计的时候DBRef肯定是需要的,直接用有意义的ID查询肯定是性能最好的。
3. 控制key的数量肯定是必须的。比如说用户数量就是key的数量这就够了。别整那么多。collection不然损失性能。
   1. 如果真的想控制数量的话,那么数据关联肯定是十分必须的。

4. 流量控制肯定也是必须的。

   1. 流量的来源在于Find直接返回所有查询结果。卧槽。直接吃掉所有流量。
   2. 直接用FindOne 避免查询多个结果回来肯定是必须的

   3. FindOne就够了吗?我确实遇到这个坑了。在博文中已经提到关于这种情况适用filter的方法了。直接参考就OK了。

      1
      

      FindOne({_id:xxx},{Items:{"$slice":[3,1]}})
      

      虽然适用了这种方法来设计,使得查询结果减少流量降低了。但是依然存在问题

      1. 一定更要注意,不能直接dbref因为slice不好加啊。可以用过顺序id加分页,或者算时间。233 很实用,典型的用空间换时间。

      1
      2
      3
      4
      5
      6
      7
      

      db.user.findOne({user_id:2}, {"book.price":1,"book.price.":{$slice:[-10,4]}})
      
      解释下其含义哈:
      1. user集合
      2. user.book.price 表示用户拥有书籍, 书籍呢有很多价格列表
      3. 注意红色字体 "book.price." 末尾必须有个点
      4. 查找价格列表里的4条数据, 从右边第10个位置开始便宜
      

      但是也有不同的语法说明,到时候试试吧。

5. update 要做精细修改。

1

比如Update({_id:xxx},{$set:{"Items.3.Item.Health":38}});//修改第三把武器的健康值

至于一次修改和批量修改,MongoDB默认100ms flush一次(2.x),只要两次修改比较贴近,被一起保存的可能性很高。

上面这些是引用别人说的话,还是全要直接精细修改,然后数据库会自动一起修改的,性能不成问题

1. 最后几点注意
   1. 控制io(系统吞吐)这事整个系统的核心,也是系统性能的核心。
   2. 控制内存(不要让index膨胀)
      1. 控制index个数,
      2. 控制key的个数
   3. CPU控制不要让js做大量的计算,能迁移到客户端的计算就迁移到客户端,让他们算完之后在通讯
   4. 第一个性能不够的估计是硬盘,可以通过RAID或者企业级SSD搞定整个问题。

Golang MGO驱动使用

ref1

ref2

本文来自:PHILO

感谢作者:jianyingLi

查看原文:MGO 设计调优。

• 编辑
• 预览