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