Mongodb查询处理流程

MyMessageHandler

用于处理客户端发送的请求消息，例如CRUD操作，db命令等.

过程函数是输入函数，该函数主要执行三件事

1生成执行上下文OperationContext

2在1）的上下文中，处理此请求消息

3条回复消息

生成执行环境

globalServiceContext

这是ServiceContext类型的全局变量，ServiceContext是抽象类，ServiceContextMongoD的子类有几种类型，ServiceContextNoop类，这里我们使用ServiceContextMongoD类. 此类用于初始化mongod的某些全局环境

1包括初始化存储引擎，因为monogdb支持多个存储引擎，所以这里将初始化当前支持的存储引擎

2为每个客户端生成一个执行上下文OperationContext

OperationContext

这是操作的执行上下文. 当每个客户端连接到客户端以执行操作时，它将生成一个上下文. OperationContext是基类. 在这里，将创建OperationContextImpl的子类. 此类的主要角色是是

1关联当前客户端

2获取新的操作ID

3通过globalServiceContext获取当前使用的存储引擎

4根据存储引擎的类型，初始化成员变量_recovery取得查询结果集总数的函数是?，_recovery是RecoveryUnit类型的抽象类，对应的子类为WiredTigerRecoveryUnit类型.

5将当前客户端Client的执行上下文设置为其自身

RecoveryUnit

此类负责数据的持久性，个人理解，所有有关数据修改的操作将保存在此类中，并最终提交或回滚. WiredTigerRecoveryUnit类型用于wiretiger存储引擎，主要封装

1个存储引擎的会话分配

2接收与此操作相关的所有更改

3开始交易

4提交或回滚交易

处理此请求

assembleResponse

assembleResponse函数是处理此请求的入口点. 在这里，所有类型的请求都得到处理. 我们将以查询为例来说明其处理流程

1个解决方案请求类型

2记录操作日志

3增加此操作的类型数

4输入receiveCommand处理功能

receivedCommand

处理命令类型的消息

1初始化CurOp的某些成员对象

2输入runCommands函数

runCommands

根据请求消息类型查询此命令的类型，然后执行此命令.

1调用Command :: findCommand以查找此Command类型并实例化此Command. 命令也是基类. 子类初始化后，会将命令名称写入Command的_commands成员变量，这是一个静态变量. 如果未找到命令，将返回错误，否则返回命令类型，我们在此处返回FindCmd类型.

2然后调用Command :: execCommand函数来执行FindCmd命令.

Command :: execCommand

1首先调用_checkAuthorization做一些授权验证工作.

2如果它是副本集，则必须验证发送的消息是否可以在相应的实例上执行取得查询结果集总数的函数是?，实例状态必须正确，主服务器可以写入，而slaveOK可以读取，等等.

3调用FindCmd的运行方法

FindCmd ::运行

1通过LiteParsedQuery类解析所有语法关键字.

2 LiteParsedQuery的筛选器成员由MatchExpressionParser类的_parse函数进行解析. 筛选器语法可以形成树结构，因此最终的解析表达式将构成一个表达式树，并且每个节点都是不同的表达式类型.

3 CanonicalQuery类的规范化功能用于进一步优化表达式树.

4通过getExecutorFind函数获取PlanExecutor.

5循环调用PlanExecutor的getNext函数以获取查询结果.

6当获得的结果集满足一次返回的数量时，它将退出循环.

7如果还有其他未提取的记录，请保存cursorId，然后调用getMore遍历光标.

8返回结果集和cursorId.

getExecutorFind

根据CanonicalQuery获得的表达式树，调用getExecutor以获取最终的PlanExecutor

1调用prepareExecution函数以获取大于或等于从CanonicalQuery类获得的表达式树的查询计划

2致电PlanExecutor ::进行选择以选择最多的PlanExecutor

prepareExecution

用于生成和执行QuerySolution和PlanStage.

1调用QueryPlanner :: plan生成查询计划，该计划将生成一个或多个查询计划QuerySolution.

2调用StageBuilder :: build函数根据查询计划生成计划阶段PlanStage，每个查询计划对应一个计划阶段.

PlanExecutor ::制作

它初始化PlanExecutor类型并调用pickBestPlan以选择最佳计划. 它包含许多不同类型的PlanStage

PlanExecutor :: getNext

在PlanExecutor的getNext函数中调用getNextImpl函数，在getNextImpl中调用PlanStage的工作函数.

CollectionScan ::工作

我们以以下解释为例来说明PlanStage的工作.

mgset-4049517113: 主要> db.test.find（{item: “ card”}）. 解释（）

{

“ queryPlanner”: {

“ plannerVersion”: 1，

“命名空间”: “ test.test”，

“ indexFilterSet”: 否，

“ parsedQuery”: {

“项目”: {

“ $ eq”: “卡”

}

}，

“ winningPlan”: {

“舞台”: “ COLLSCAN”，

“过滤器”: {

“项目”: {

“ $ eq”: “卡”

}

}，

“方向”: “前进”

}，

“ rejectedPlans”: []

}，

“ serverInfo”: {

“主机”: “ 127.0.0.1”，

“端口”: 27017，

“版本”: “ 3.2.9”，

“ gitVersion”: “ 22ec9e93b40c85fc7cae7d56e7d6a02fd811088c”

}，

“好”: 1

}

1首先，您需要初始化CollectionScan的cursor_cursor成员变量

2 _cursor是通过调用Collection的getCursor函数获得的游标

3然后调用_cursor的seekExact函数以获取一条记录，将该记录的_id字段记录到_lastSeenId成员变量中，以便下次在该记录之后获取该值，并直接调用_cursor-> next（ ）以获取下一个值.

4在WorkingSet集合中找到可用位置以存储该记录.

> WorkingSetMember的loc字段是记录的id字段，obj字段记录的bson文档，并且_state字段设置为WorkingSetMember :: LOC_AND_OBJ.

5最后，调用returnIfMatches来查看此完整表扫描的记录是否符合我们的PlanStage的CollectionScan过滤器. 如果匹配，它将返回到PlanExecutor的getNext函数，否则它将继续向后移动.

WorkingSet

工作集用于保存从存储引擎返回的结果. WorkingSet将保存查询的所有PlanStage的结果. 它具有一个数组成员_data. 该数组用于形成链表结构. 它用于保存记录和链接列表中下一个节点的位置. 记录将被调整并以WorkingSetMember类型存储. 在查询过程中，需要许多应用程序和MemberHolder的发行版. 在免费列表中，以备将来使用.

本文来自电脑杂谈，转载请注明本文网址：
http://www.pc-fly.com/a/tongxinshuyu/article-165179-1.html