高性能MONGODB(2.4)优化心得,亿级别高速读写必备。

  1. 索引统一管理, 提高索引效率, 不乱建索引, 数据库死锁大多发生在更新索引上。
  2. 查询条件无顺序区别, 索引建立有顺序区别。 索引字段只能从前往后搜索, 不要指望{a,b,c}索引能覆盖b或bc, 必须有a才行, 因为a是入口!但是ab,ac都能覆盖。 find(c).sort(a)也能覆盖。 mongo一次查询只能命中单个索引。
  3. Create Queries that Ensure Selectivity, 官方文档原话, 什么叫selectivity? unique最selectivity, 只有一个或两个值的字段最inselectivity。建inselectivity的索引只会导致数据库性能下降, 毫无益处
  4. 延时数据与实时数据拆分, 写操作异常频繁的一定要做成延时数据, 否则会导致你所有实时数据都延时! 延时数据读写分离, Replica Sets就是拿来干这事的。
  5. 上亿数据写锁高, 必然是索引不合理, 合理索引2.4或更高版本能搞定10亿数据。
  6. 不要在长字段上建索引, 会吃光你的内存, 即使要建, 也做个映射字段, 比如拿长字段头5个字符 + 末尾5个字符拼接成10给字符的索引字段, 查长字段的时候把这个带上, 虽然可能一次命中几百条数据, 但是也比索引直接建在长字段上好很多。命中数据太多可以考虑增加索引字段长度。
  7. 分片会导致写性能下降, 大多数人认为可以接受。 但是肯定没有分库 + 连接池的效率高。 内存索引只能在一台机器上是这个问题的关键。单表按首字母分库不如分片, 速度快, 维护简单。
  8. 索引顺序对单键排序没有区别, 只有多键组合排序需要定义索引方向。
  9. $regex只有'^'开头的的正则式才能使用索引,大数据需要模糊搜索时需要建立full_text index
  10. 从库的写操作会被集群保留,但不会同步到主库,对从库进行写操作会导致主从数据不一致。
Example:
    [('a',1), ('b',1), ('c',1)]:                                 
        find({'a':1})                                       HIT
        find({'c':1, 'b':1}).sort('a',1)                    HIT
        find({'c':1, 'a':{'$in':[1,2,3]}})                  HIT
        find({'b':1, 'a':{'$in':[1,2,3]}}).sort('a',-1)     HIT
        find().sort([('a',1), ('b',1)])                     HIT                              
        find({'b':1})                                       MISS
        find({'c':1, 'b':1})                                MISS
        find().sort([('a',1), ('b',-1)])                    MISS



展开阅读全文

没有更多推荐了,返回首页