MongoDB 并发 - 降低性能

Question

我知道 mongo db 会锁定读写操作。

我的用例：

仅读取操作。没有写操作。

我收集了大约 1000 万份文档。存储引擎是wiredTiger。

Mongo 版本是 3.4。

我提出了一个应该返回 30k 文档的请求 - 平均需要 650 毫秒。

当我发出并发请求时 - 相同的请求 - 100 次 - 需要几秒钟 - 几秒到 2 分钟处理所有请求。

我只有一个节点来提供数据。

我如何访问数据：

每个文档包含 25 到 40 个字段。我索引了几个字段。我基于一个索引字段进行查询。

API 会以 json 形式返回所有匹配的文档。

其他信息：API 是使用 Spring boot 编写的。

从远程机器上的命令行通过 JMeter shell 脚本测试并发性。

所以，

我的问题：

1. 我是否缺少任何优化？ [存储引擎级别，版本]
2. 我不能在不到一秒的时间内完成所有读取请求吗？
3. 如果是这样，我可以为这个用例保留什么 SLA？

有什么建议吗？

编辑：

我在 mongodb 中启用了级别 2 的数据库分析器。

我的单个查询在内部转换为 4 个查询：

1. 初始读取
2. 获取更多
3. 获取更多
4. 获取更多

这些是通过分析器找到的查询。

总共不到 100 毫秒。真的吗？

我的并发查询：

现在，当我达到 100 个请求时，将近 150 个操作超过 100ms，100 个操作超过 200ms，90 个操作超过 300ms。

根据我的单个查询分析，100 个请求将在内部转换为 400 个查询。这是我通过检查分析器输出中的查询标记来验证的固定模式。

我希望这会影响我的请求性能。

Answer 1

我的单个查询在内部转换为 4 个查询：

1. 初始读取
2. 获取更多
3. 获取更多
4. 获取更多

这是 mongo 游标的工作方式。文档分批从数据库传输到应用程序。 IIRC 第一批是大约 100 个文档 + 游标 ID，然后连续的 getMore 调用通过游标 ID 检索下一批。

您可以从应用程序中定义批次大小（批次中的文档数）。批次不能超过 16MB，例如如果您将批量大小设置为 30,000，则仅当文档大小小于 500B 时，它才会适合单个批次。

您的调查清楚地表明负载下的性能下降。有太多因素，我相信锁定不是其中之一。 WiredTiger 在文档级别为常规写操作执行独占锁，而您在测试期间只进行读取，不是吗？如有任何疑问，您可以比较测试前后db.serverStatus().locks 的结果，以查看获得了多少写锁。您也可以在测试期间运行db.serverStatus().globalLock 来检查队列。有关锁定和并发的更多详细信息，请参见：https://docs.mongodb.com/manual/faq/concurrency/#for-wiredtiger

瓶颈可能在其他地方。需要检查的通用事项很少：

• 查询优化。确保使用索引。分析器在 execStats 字段中不应有“COLLSCAN”阶段。
• 系统负载。如果您的数据库与应用程序共享系统资源，则可能会影响数据库的性能。例如。 API 中的 BSON 到 JSON 转换非常消耗 CPU，并且可能会影响查询的性能。在 *nix 系统上使用 top 或 htop 检查系统的 LA。
• MongoDB 资源。如果服务器有足够的 RAM、IO、文件描述符、连接等，请使用 mongostat 和 mongotop。

如果您找不到任何明显的东西，我建议您寻求专业帮助。我发现获取数据的最简单方法是将数据导出到 Atlas，然后针对集群运行测试。然后，您可以与支持团队交谈，如果他们可以对查询提出任何改进建议。