Mongodb 针对大型数据集和IOPS限制的Mongo磁盘读取瓶颈

我很难理解Mongo数据库集合中从磁盘读取数据的瓶颈所在。我知道索引是优化查询的一个重要因素，但假设我们有一个没有索引的集合，我正在一个大约50Gb、有2500万条记录的集合中运行一个简单的查询：

db.customers.find({ first_name: "xyz" })

当然，这必须运行

COLLSCAN

，因此速度非常慢（除非它缓存在内存中）。但在我们的案例中，速度有多慢是很重要的。运行一些测试表明，我在其上运行此查询的计算机没有固定我的可用IOPS。在最大读取IOPS为10K的机器上，此简单查询限制在约1.2K。注意CPU

iowait

查询显然受到磁盘的限制，但它没有充分利用计算机上的可用功能。有趣的是，当我创建另一个数据库连接并异步运行两个查询时，IOPS负载增加了2倍。似乎每个查询一次只能扫描磁盘上的这么多数据。当运行这些没有索引的查询时，是什么阻碍了它

---

从长远来看，我认为将Elasticsearch引擎与之耦合将有助于尝试对大量不同数据进行复杂搜索，但我真的很好奇，为什么在这种情况下我们不能垂直扩展任何数据。

mongod节点使用类似于btree的结构来存储数据。叶页可以包含多个高达32Kb（压缩）的文档，也可以包含一个文档（如果大小等于或大于32Kb）

收集扫描在存储引擎层之上的数据库层中运行。数据库层在检查完当前文档后，会从存储器中请求下一个文档。
如果文档已经在缓存中，存储层将返回该文档。如果没有，它将从操作系统请求下一页。操作系统可以从文件系统缓存中传递或从磁盘读取。然后，存储引擎将其解压缩，将文档存储在缓存中，并将请求的文档提供给数据库层

---

处理文档以查看它们是否与查询匹配的线程正在与存储引擎线程轮换。当您同时运行两个查询时，会有第二个线程处理第二个查询，因此它们可以将请求交叉发送到磁盘，从而提高IO使用率。

我认为mongod线程就是这样工作的。我想，每个线程（tcp连接）从磁盘读取的数据量只有这么多。