MongoDB 一次数据库请求发生了什么？

转载用于收藏学习，尊重原创

原文链接

https://blog.csdn.net/July_whj/article/details/124110597

————————————————
版权声明：本文为CSDN博主「July_whj」的原创文章，遵循CC 4.0 BY-SA版权协议，转载请附上原文出处链接及本声明。
原文链接：https://blog.csdn.net/July_whj/article/details/124110597

1、应用端

• 首先应用端选择相应节点，从链接池中获取该节点连接，判断链接是否有效；

• 对于复制集读操作，选择哪个节点是由readPreference决定的：

  • primary/primaryPreferred

  • secondary/secondaryPreferred

  • nearest

• 如果不希望一个远距离节点被选择，应做到以下之一：

  • 将它设置为隐藏节点；

  • 通过标签（Tag）控制可选的节点；

  • 使用 nearest 方式；

• 若链接获取失败，则新建连接，新建连接判断是否到达连接上线，如未到达，则建立连接，否则排队等待。排队等待若超时则异常结束。

• 总连接数大于允许的最大连接数maxPoolSize；加大最大连接数（不一定有用）；

• 建立连接前先进行认证，若认证通过，则建立连接。

• 如果一个请求需要等待创建新连接和进行认证，相比直接从连接池获取连接，它将 耗费更长时间。

  • 可能解决方案：

  • 设置 minPoolSize（最小连接数）一次性创建足够的连接；

  • 避免突发的大量请求；

• 建立连接后，向服务端发起请求，等待返回结果。执行完成后进行连接释放，流程正常结束。

2、数据库端

• 数据库端-排队等待
• 由 ticket 不足引起的排队等待，问题往往不在 ticket 本身，而在于为什么正在执行的操作会长时间占用 ticket。
• 可能解决方案：
  • 优化 CRUD 性能可以减少 ticket 占用时间；
  • zlib 压缩方式也可能引起 ticket 不足，因为 zlib 算法本身在进行压缩、解压时需要的时 间比较长，从而造成长时间的 ticket 占用；

2.1、执行请求：读

不能命中索引的搜索和内存排序是导致性能问题的最主要原因

2.2、执行请求：写

磁盘速度必须比写入速度要快才能保持缓存水位。

2.3、数据库端-合并结果

• 如果顺序不重要则不要排序
• 尽可能使用带片键的查询条件以减少参与查询的分片数

3、可能存在瓶颈点总结