近期对mongodb的写入和查询性能做了一个分析,前提是各个接口独立测试,没有进行复合测试,即读写接口同时测试等情况。
总结了以下几点内容:
1.从数据上显示写入或者编辑数据的性能不受数据条数影响,平均时间在15-20ms左右。
2.数据超30条后,复杂的语句,例如带模糊查询,范围查询和排序操作耗时尤为明显,即使建了复合索引,性能提升也是有限的。删除上面提到的查询后,性能明显提升。
优化思路:数据量大时尽量使用精准查询,避免使用以上查询,但是有时业务需要也是没有办法。如果耗时太久的接口,可以采用定期转移冷数据到历史表,维持热数据表在一个比较适合的大小。
3.带count的语句,成为接口性能的主要瓶颈,在数据量大时耗时更加明显。
优化思路:数据量大时取消count服务或者使用异步任务方式返回数据。
本人尝试了另一种折中方案,采用redis缓存。
查询语句去掉每页条数和页索引,将其md5值加上标识符作为key,value就是count出来的条数值。
以30万条数据为界,数据在此以下时,采用实时返回count条数;数据在30万到50万之间时,缓存时间为1分钟;50万到100万之间,缓存时间为5分钟;100万以上,缓存时间为10分钟。
启用缓存后,第一次查询时后按实时查询时间返回,所有会感觉比较慢,但是在缓存时间内,之后查询会感觉飞快。