MongoDB首次查询很慢的问题

xiaopan588128 2017-04-20 09:37:31
我在项目中遇到一个MongoDB的问题,好多天了还是没能得到解决,希望得到大牛的指点。
具体问题是:长时间不访问数据库的情况下,第一次查询数据库所需的时间很长,但是之后的查询就会很快。
具体情况:
①整个数据库大小大概在1.9TB左右;
②我查询的collection的数据大致为700万条;
③我查询一次得到的数据为23万条左右;
④服务器内存为120GB;
⑤已按照查询条件建立了索引,索引数据大小为600MB左右;
⑥第一次查询所用时间20s左右,之后的查询在1s以内。
目前考虑的原因:
由于MongoDB不负责内存的管理,所以,当长时间未访问数据库时,内存中的数据即为冷数据,操作系统的内存管理程序就会将这部分冷数据释放,导致下次查询时,需要重新加载数据到内存,所以比较费时。目前,不能够确定是加载索引比较费时,还是加载数据比较费时。MongoDB虽然提供了touch命令(该命令能够指定将某个collection的索引数据或者用户数据加载到内存中),但是我使用的是WiredTiger存储引擎,该命令不支持该存储引擎。
需要得到的帮助:
①是不是以上原因导致的该问题?
②如果是该原因导致的,如何确定是加载索引费时还是加载数据费时?
③有什么比较好的解决方案么?

注:由于该collection最大会达到25GB左右,而且整个数据库还有其他很多collection,所以将该collection的所有数据存储到内存是不可取的。如果能够确认是加载索引费时的话,倒是可以考虑定期将索引加载到内存,但是对于WiredTiger存储引擎,没有支持该功能的方法,这又是一个问题。
...全文
3440 8 打赏 收藏 转发到动态 举报
写回复
用AI写文章
8 条回复
切换为时间正序
请发表友善的回复…
发表回复
zjcxc 2019-09-04
  • 打赏
  • 举报
回复
首次访问一定是要走磁盘的,如果磁盘IO慢,则这个过程会很慢,缓存包含两层,一层是操作系统本身的缓存,另一层是 WiredTiger 的内部缓存,在这一层,数据还会被解压缩(默认设置下,数据是压缩存储的)
所以磁盘读取/解压缩,这些都会导致首次查询慢
索引的问题应该不在,它的数据量不大,消耗的磁盘IO不会太大,索引默认是前缀压缩,这个在 WiredTiger 内部缓存中也不需要解压缩的
确认的方法:你可以建立一个同样的集合,集合中只包含索引数据,对比一下这个集合与原始集合的首次查询性能
qq_20996981 2019-09-02
  • 打赏
  • 举报
回复
请问这个mongodb首次查询慢的问题解决了吗?
qq279788 2019-07-18
  • 打赏
  • 举报
回复
我目前也遇到这个问题,使用explain查询语句发现首次查询 需要saveState和restoreState 大量数据,第二次这个数据就会小很多,请问楼主这个问题解决了吗?
维秀斯丢丢 2018-05-02
  • 打赏
  • 举报
回复
每天来个预热查询吧。
  • 打赏
  • 举报
回复
系统启动开始自动进行一次随机一个数据的查询不行吗?
maxx 2018-04-27
  • 打赏
  • 举报
回复
mark一下 我也发现这个问题了 因为我是web访问的数据所以我一直以为是浏览器的问题 看来是mongo的问题
a532041020 2017-12-04
  • 打赏
  • 举报
回复
楼主解决了吗,同样遇到类似的问题,时间长不访问第一次访问速度很慢。然后再访问速度就正常了
rucypli 2017-04-27
  • 打赏
  • 举报
回复
如果对这么大数据必须要这么强的实时性 可以考虑用内存引擎替换wiredtiger
关系型数据库和NoSQL数据库 什么是NoSQL 大家有没有听说过“NoSQL”呢?近年,这个词极受关注。看到“NoSQL”这个词,大家可能会误以为是“No!SQL”的缩写,并深感愤怒:“SQL怎么会没有必要了呢?”但实际上,它是“Not Only SQL”的缩写。它的意义是:适用关系型数据库的时候就使用关系型数据库,不适用的时候也没有必要非使用关系型数据库不可,可以考虑使用更加合适的数据存储。 为弥补关系型数据库的不足,各种各样的NoSQL数据库应运而生。 为了更好地了解本书所介绍的NoSQL数据库,对关系型数据库的理解是必不可少的。那么,就让我们先来看一看关系型数据库的历史、分类和特征吧。 关系型数据库简史 1969年,埃德加•弗兰克•科德(Edgar Frank Codd)发表了划时代的论文,首次提出了关系数据模型的概念。但可惜的是,刊登论文的《IBM Research Report》只是IBM公司的内部刊物,因此论文反响平平。1970年,他再次在刊物《Communication of the ACM》上发表了题为“A Relational Model of Data for Large Shared Data banks”(大型共享数据库的关系模型)的论文,终于引起了大家的关注。 科德所提出的关系数据模型的概念成为了现今关系型数据库的基础。当时的关系型数据库由于硬件性能低劣、处理速度过慢而迟迟没有得到实际应用。但之后随着硬件性能的提升,加之使用简单、性能优越等优点,关系型数据库得到了广泛的应用。 通用性及高性能 虽然本书是讲解NoSQL数据库的,但有一个重要的大前提,请大家一定不要误解。这个大前提就是“关系型数据库的性能绝对不低,它具有非常好的通用性和非常高的性能”。毫无疑问,对于绝大多数的应用来说它都是最有效的解决方案。 突出的优势 关系型数据库作为应用广泛的通用型数据库,它的突出优势主要有以下几点: 保持数据的一致性(事务处理) 由于以标准化为前提,数据更新的开销很小(相同的字段基本上都只有一处) 可以进行JOIN等复杂查询 存在很多实际成果和专业技术信息(成熟的技术) 这其中,能够保持数据的一致性是关系型数据库的最大优势。在需要严格保证数据一致性和处理完整性的情况下,用关系型数据库是肯定没有错的。但是有些情况不需要JOIN,对上述关系型数据库的优点也没有什么特别需要,这时似乎也就没有必要拘泥于关系型数据库了。 关系型数据库的不足 不擅长的处理 就像之前提到的那样,关系型数据库的性能非常高。但是它毕竟是一个通用型的数据库,并不能完全适应所有的用途。具体来说它并不擅长以下处理: 大量数据的写入处理 为有数据更新的表做索引或表结构(schema)变更 字段不固定时应用 对简单查询需要快速返回结果的处理 。。。。。。 NoSQL数据库 为了弥补关系型数据库的不足(特别是最近几年),NoSQL数据库出现了。关系型数据库应用广泛,能进行事务处理和JOIN等复杂处理。相对地,NoSQL数据库只应用在特定领域,基本上不进行复杂的处理,但它恰恰弥补了之前所列举的关系型数据库的不足之处。 易于数据的分散 如前所述,关系型数据库并不擅长大量数据的写入处理。原本关系型数据库就是以JOIN为前提的,就是说,各个数据之间存在关联是关系型数据库得名的主要原因。为了进行JOIN处理,关系型数据库不得不把数据存储在同一个服务器内,这不利于数据的分散。相反,NoSQL数据库原本就不支持JOIN处理,各个数据都是独立设计的,很容易把数据分散到多个服务器上。由于数据被分散到了多个服务器上,减少了每个服务器上的数据量,即使要进行大量数据的写入操作,处理起来也更加容易。同理,数据的读入操作当然也同样容易。 提升性能和增大规模 下面说一点题外话,如果想要使服务器能够轻松地处理更大量的数据,那么只有两个选择:一是提升性能,二是增大规模。下面我们来整理一下这两者的不同。 首先,提升性能指的就是通过提升现行服务器自身的性能来提高处理能力。这是非常简单的方法,程序方面也不需要进行变更,但需要一些费用。若要购买性能翻倍的服务器,需要花费的资金往往不只是原来的2倍,可能需要多达5到10倍。这种方法虽然简单,但是成本较高。 另一方面,增大规模指的是使用多台廉价的服务器来提高处理能力。它需要对程序进行变更,但由于使用廉价的服务器,可以控制成本。另外,以后只要依葫芦画瓢增加廉价服务器的数量就可以了。 不对大量数据进行处理的话就没有使用的必要吗? NoSQL数据库基本上来说为了“使大量数据的写入处理更加容易(让增加服务器数量更容易)”而设计的。但如果不是对大量数据进行操作的话,NoSQ

1,747

社区成员

发帖
与我相关
我的任务
社区描述
MongoDB相关内容讨论区
社区管理员
  • MongoDB社区
加入社区
  • 近7日
  • 近30日
  • 至今
社区公告
暂无公告

试试用AI创作助手写篇文章吧