咨询大佬们一个关于 mongodb 的性能优化问题

253 天前
 rizon

mongodb 中一个文档里有个 N 个小字段和 2 个大字段。大字段存储 base64 的图片和其他长文本内容。 在一个频繁差的查询中,我不会查询大字段,只会查询小字段,索引也只在小字段。大字段会有单独的查询使用 _id 去查询。

然后我发现数据量大了之后,mongodb 的整体查询速度变慢了,即使我没有查询大字段,速度依然变慢了。 请问,

  1. 我需要把大字段单独拆到一个 collection 才可以吗?
  2. 大字段我必须要换成 gridfs 来读写吗?历史数据又如何迁移呢?
  3. 如果大字段拆走了,我该如何做全文搜索呢(需要搜索长文本大字段,不搜索 base64 图片)?

谢谢大佬们

1407 次点击
所在节点    程序员
11 条回复
nomagick
253 天前
不需要拆字段,单文档我记得好像上限 64MB 来着

先说说有多少内存,用没用 SSD 吧。。

小内存机械盘,这都属于正常情况。
zhuisui
253 天前
explain 呀。。。
上来就是一顿盲目猜测
sunny352787
253 天前
下回还是先说明一下运行环境吧,类似 MongoDB 的版本、内存大小、硬盘类型、数据量等等的

按你现在的描述,基本就盲猜了,MongoDB 是内存映射方式管理文档,如果文档不在内存里那么就会触发缺页中断从硬盘读取文档数据到内存里,所以我怀疑你这边是由于内存不够大导致频繁触发缺页加载导致的速度变慢,可以先从这方面入手。

不过大字段我这边在设计的时候确实是分开存储的,待查询数据是要即时响应而图片或其他长文本内容是可以接受异步延迟的,所以逻辑上这些就是不同的数据需要区分处理
sunny352787
253 天前
另外,全文搜索别用 Mongo ,用 Elasticsearch
yh7gdiaYW
253 天前
@nomagick 上限只有 16MB
rizon
253 天前
@zhuisui #2 哎呀!我这好久不搞数据库了,居然连基础的排查流程都忘了。。一语惊醒啊,我这居然没想着 explain 检查一下索引命中问题。 谢谢
最近为了搞这个项目,精神上有点疲惫,脑子都开始不灵光了。 我这就去查。


@sunny352787 #3 非常感谢,后面我想办法把大字段迁移到独立的表吧。哎,好累,明明做这种独立项目都没什么很好的收益,但是既然做起来了,又得负责下去,看着这些问题不去优化心里也放不下啊。
rizon
253 天前
@sunny352787 #3 2C4G 的机器,SSD 的硬盘。
这是宝塔显示的 mongodb 的内存情况:
可用 113MB ,已有 2180MB ,
总内存:3400MB ,共享:2MB
available:931MB ,buff/cache:1069/38MB

另外,宝塔监控上,有时候磁盘 IO 的读取延迟会变的很大,超过 1000ms 。不知道为什么。
rizon
253 天前
@rizon #7 @nomagick #1 7 楼,内存和硬盘的情况
rizon
253 天前
@zhuisui #2 修复了索引命中问题,速度恢复正常了,感谢提醒,哈哈哈。
nomagick
253 天前
@rizon 数据上规模之后性能不可能太好,MongoDB 要 8G 内存才算入门,另外低端的虚机会卡硬盘 iops
rizon
253 天前
@nomagick #10 谢谢,按看来我得单独购买 mongodb 服务才行了,自己部署终究还是不行。 买专门的存储的话,现在看价格都不便宜

这是一个专为移动设备优化的页面(即为了让你能够在 Google 搜索结果里秒开这个页面),如果你希望参与 V2EX 社区的讨论,你可以继续到 V2EX 上打开本讨论主题的完整版本。

https://www.v2ex.com/t/1023304

V2EX 是创意工作者们的社区,是一个分享自己正在做的有趣事物、交流想法,可以遇见新朋友甚至新机会的地方。

V2EX is a community of developers, designers and creative people.

© 2021 V2EX