【VictoriaMetrics】vm-select源码阅读
调用层次表格
| 源文件 | 行号 | 函数 | 说明 |
|---|---|---|---|
| app/vmselect/main.go | 63 | main | 入口 92行调用 requestHandler |
| app/vmselect/main.go | 132 | -requestHandler | 处理http协议的入口 222行调用 selectHandler |
| app/vmselect/main.go | 236 | --selectHandler | 处理查询逻辑 326行调用 prometheus.QueryRangeHandler |
| app/vmselect/prometheus/prometheus.go | 1197 | ---QueryRangeHandler | 处理 /api/v1/query_range 1221调用queryRangeHandler |
| app/vmselect/prometheus/prometheus.go | 1227 | ----queryRangeHandler | 查询的业务逻辑 1263行调用promql.Exec |
| app/vmselect/promql/exec.go | 29 | -----Exec | 根据解析好的promql，执行查询逻辑 44行执行evalExpr |
| app/vmselect/promql/eval.go | 203 | ------evalExpr | 根据解析好的metricsql.Expr结构，执行查询 (先看简单的根据一个监控项名字查询的情形)208行调用evalRollupFunc |
| app/vmselect/promql/eval.go | 499 | -------evalRollupFunc | 执行汇总函数 526行调用evalRollupFuncWithMetricExpr |
| app/vmselect/promql/eval.go | 665 | --------evalRollupFuncWithMetricExpr | 查询单个监控项的情况 703行调用netstorage.ProcessSearchQuery |
| app/vmselect/netstorage/netstorage.go | 1405 | ---------ProcessSearchQuery | 把请求发到存储层 1439行调用processSearchQuery |
| app/vmselect/netstorage/netstorage.go | 1471 | ----------processSearchQuery | 请求，并阻塞等待结果 1476行调用startStorageNodesRequest 1478行调用processSearchQuery |
| app/vmselect/netstorage/netstorage.go | 1502 | -----------startStorageNodesRequest | 广播到所有存储节点 这里可以说明:vm-select到vm-storage这个路径上，对于选择后端的存储并没有复杂的算法，暴力广播而已！ |
| app/vmselect/netstorage/netstorage.go | 1853 | ------------func (sn *storageNode) processSearchQuery | 这里调用了sn.execOnConnWithPossibleRetry 可以看见，使用了 search_v4 这条命令来请求vm-storage |
| app/vmselect/netstorage/netstorage.go | 1531 | -----------func (snr *storageNodesRequest) collectResults | processSearchQuery中调用collectResults来处理广播后的结果 |
| app/vmselect/promql/eval.go | 787 | ---------evalRollupWithIncrementalAggregate | 在evalRollupFuncWithMetricExpr函数761行中被调用。这个函数并行处理从storage得到的结果。 |
感受
- vm-select相当于是个复杂的metric计算引擎，内部的代码非常复杂，分了非常多的情况的分门别类的处理各种查询需求
- 对于范围查询而言：
- vm-select先解析查询语句
- 与vm-insert一样，vm-select与vm-storage使用极其简单的通讯协议来传输数据
- 先握手
- 然后使用 length + value的形式分割各个字段
- 返回的数据会使用ZSTD压缩算法来压缩
- 查询的时候，广播发送给所有存储节点，并未智能的区分storage是否有这个数据
- 得到结果后，再进行去重、汇总、写入cache、返回JSON等动作
- 存储层和计算层分开了，可以避免存储层变得过于复杂。但是存储层没有计算能力的话，部分查询可能需要把大量数据从storage节点搬迁到select节点。
- 猜测vm单机版为什么会更快？可能仅仅只是存储和查询都是进程间通讯吧！待后续阅读源码来证实。