Mongo磁盘读取瓶颈，适用于大型数据集和IOPS限制

Question

我无法理解与Mongo数据库集合中的磁盘读取数据有关的瓶颈所在。我知道索引是优化查询的重要因素，但可以说我们有一个没有索引的集合，而我正在一个集合中运行一个简单的查询，该集合在50Gb左右有2500万条记录：

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

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

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

长期而言，我认为将Elasticsearch引擎与此结合起来将在尝试对大量不同数据进行复杂搜索时有所帮助，但是我很好奇为什么在这种情况下我们无法垂直扩展任何内容。

Answer 1

mongod节点使用类似于btree的结构来存储数据。叶子页可以包含许多最大为32Kb（压缩）的文档，如果该尺寸或更大，则可以包含一个文档。

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

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