MGO 设计调优。

Tags golang


1899-11-30 00:00:00


#MGO 设计调优。 > 真的是那句话,不是你不行,知识你不了解。而已。

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

    1. 流量的来源在于Find直接返回所有查询结果。卧槽。直接吃掉所有流量。
    2. 直接用FindOne 避免查询多个结果回来肯定是必须的
    3. FindOne就够了吗?我确实遇到这个坑了。在博文中已经提到关于这种情况适用filter的方法了。直接参考就OK了。

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

      虽然适用了这种方法来设计,使得查询结果减少流量降低了。但是依然存在问题 1. 一定更要注意,不能直接dbref因为slice不好加啊。可以用过顺序id加分页,或者算时间。233 很实用,典型的用空间换时间。

      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 要做精细修改。

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

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

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

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

Golang MGO驱动使用

ref1

ref2


本人博客文章采用CC Attribution-NonCommercial协议: CC Attribution-NonCommercial 必须保留原作者署名,并且不允许用于商业用途,其他行为都是允许的。