mongodb - 大数据集的Mongo磁盘读取瓶颈和IOPS限制

Question

我无法理解与从 Mongo 数据库集合中的磁盘读取数据相关的瓶颈在哪里。我知道索引是优化查询的重要因素，但假设我们有一个没有索引的集合，我在一个包含 2500 万条记录的集合中运行一个简单的查询，大小约为 50Gb:

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

当然，这必须运行一个COLLSCAN，所以它非常慢(除非它被缓存在内存中)。但在我们的案例中，有多慢很重要。运行一些测试表明，我运行此查询的机器不会与我的可用 IOPS Hook 。在最大读取 IOPS ~10K 的机器上，这个简单的查询被限制在 1.2K 左右。注意 CPU iowait

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

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

Answer 1

mongod节点使用类似于btree的结构来存储数据。叶页可以包含许多最大 32Kb(压缩)的文档，或者单个文档，如果它的大小或更大。

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

正在处理文档以查看它们是否与查询匹配的线程正在轮流使用存储引擎线程。当您同时运行 2 个查询时，会有第二个线程处理第二个查询，因此它们可以交错对磁盘的请求，从而导致更高的 IO 使用率。