MGO 设计调优。

浏览数：32 / 时间：2015年06月10日

MGO 设计调优。

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

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

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

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

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

1	FindOne({_id:xxx},{Items:{"$slice":[3,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个位置开始便宜

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

update 要做精细修改。

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

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

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

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