这是一个创建于 264 天前的主题，其中的信息可能已经有所发展或是发生改变。
mongodb 中一个文档里有个 N 个小字段和 2 个大字段。大字段存储 base64 的图片和其他长文本内容。 在一个频繁差的查询中，我不会查询大字段，只会查询小字段，索引也只在小字段。大字段会有单独的查询使用 _id 去查询。
然后我发现数据量大了之后，mongodb 的整体查询速度变慢了，即使我没有查询大字段，速度依然变慢了。 请问，
- 我需要把大字段单独拆到一个 collection 才可以吗？
- 大字段我必须要换成 gridfs 来读写吗？历史数据又如何迁移呢？
- 如果大字段拆走了，我该如何做全文搜索呢（需要搜索长文本大字段，不搜索 base64 图片）？
谢谢大佬们
第 1 条附言 · 264 天前
索引的事属实是我自己的问题了，感谢提醒。重新调整了索引，现在速度快了一些了。至少缓解眼前的问题了。后面我再想办法把数据拆开吧
11 条回复 • 2024-03-13 21:53:51 +08:00
 |
1
nomagick 264 天前
不需要拆字段，单文档我记得好像上限 64MB 来着
先说说有多少内存，用没用 SSD 吧。。 小内存机械盘，这都属于正常情况。 |
 |
2
zhuisui 264 天前
explain 呀。。。
上来就是一顿盲目猜测 |
 |
3
sunny352787 264 天前
下回还是先说明一下运行环境吧，类似 MongoDB 的版本、内存大小、硬盘类型、数据量等等的
按你现在的描述，基本就盲猜了，MongoDB 是内存映射方式管理文档，如果文档不在内存里那么就会触发缺页中断从硬盘读取文档数据到内存里，所以我怀疑你这边是由于内存不够大导致频繁触发缺页加载导致的速度变慢，可以先从这方面入手。 不过大字段我这边在设计的时候确实是分开存储的，待查询数据是要即时响应而图片或其他长文本内容是可以接受异步延迟的，所以逻辑上这些就是不同的数据需要区分处理 |
|
4
sunny352787 264 天前
另外，全文搜索别用 Mongo ，用 Elasticsearch
|
 |
6
rizon OP @zhuisui #2 哎呀！我这好久不搞数据库了，居然连基础的排查流程都忘了。。一语惊醒啊，我这居然没想着 explain 检查一下索引命中问题。 谢谢
最近为了搞这个项目，精神上有点疲惫，脑子都开始不灵光了。 我这就去查。 @sunny352787 #3 非常感谢，后面我想办法把大字段迁移到独立的表吧。哎，好累，明明做这种独立项目都没什么很好的收益，但是既然做起来了，又得负责下去，看着这些问题不去优化心里也放不下啊。 |
|
7
rizon OP @sunny352787 #3 2C4G 的机器，SSD 的硬盘。
这是宝塔显示的 mongodb 的内存情况： 可用 113MB ，已有 2180MB ， 总内存：3400MB ，共享：2MB available：931MB ，buff/cache：1069/38MB 另外，宝塔监控上，有时候磁盘 IO 的读取延迟会变的很大，超过 1000ms 。不知道为什么。 |
Select Language