企业级数据中心新选择：DolphinDB 存算分离架构解析
本页解释存算分离理念，并说明 DolphinDB 自 3.00.2 起通过计算组与缓存实现存算分离。
Source: https://dolphindb.cn/blogs/146
What this page covers
- 存算分离架构与计算组概念引入
- 存算分离架构应用场景
- 存算分离架构部署概览
- 控制节点与计算节点参数配置
- 横向扩展与 Web 管理界面操作
- 性能测试与结论汇总
技能认证特训营第二期报名活动
页面顶部包含活动报名引导与限时报名链接。
- 该区域用于引导用户进行报名操作。
- 该区域包含与报名相关的链接入口。
企业级数据中心新选择：DolphinDB 存算分离架构解析
本节给出文章标题、作者与发布日期信息。
- 作者署名为 momo。
- 发布日期为 2025-02-10。
存算分离架构与 DolphinDB 计算组概念引入
解释存算分离理念，并说明 DolphinDB 自 3.00.2 起通过计算组与缓存实现存算分离。
- 存算分离旨在将计算资源与存储资源分离。
- 该目标被描述为提升系统灵活性与性能。
- DolphinDB 自 3.00.2 版本起引入计算组概念。
- 计算节点可对查询数据进行缓存以支持该架构。
- 教程代码需运行在 DolphinDB server 3.00.2 或更高版本。
存算分离架构应用场景
在企业级行情中心/数据中台中，围绕资源隔离、稳定性、弹性与即席查询的适用场景说明。
- 存算分离主要通过引入计算组概念实现。
- 计算组由多个计算节点组成。
- 计算组是资源与故障隔离的基本单位。
- 每个计算节点只属于一个计算组。
- 管理员可控制用户对计算组的访问。
存算分离架构部署概览
介绍典型场景下部署存算分离架构的步骤，并指向横向/纵向扩展流程。
- 部署流程包含横向扩展与纵向扩展两类方向。
- 后续章节分别给出横向与纵向扩展的操作方式。
参数配置（控制节点与计算节点）
列出与存算分离相关的控制节点与计算节点配置项及其作用说明。
- computeNodeCachingDelay 定义“分区更新后延迟缓存”的时间间隔（秒）。
- computeNodeCachingDelay 默认值为 360。
- computeNodeCachingQueryThreshold 定义“访问次数阈值后才缓存”。
- computeNodeCachingQueryThreshold 取值范围为 [0, 32767]。
- computeNodeCacheDir 用于设置计算节点缓存存储位置。
横向扩展部署（新增服务器与计算组）
通过增加服务器部署代理节点与计算组，演示在线动态扩展与 Web 管理界面操作入口。
- 在线动态扩展先在新服务器部署代理节点。
- 随后通过 Web 管理界面在线增加代理节点与新增计算组。
- 新增代理节点入口为“配置管理 → 集群节点管理 → 新增节点”。
- “新建计算组”可设置计算组名称并添加计算节点。
- “批量添加”支持一次性配置多个计算节点。
纵向扩展部署（不新增服务器）
在现有服务器资源充足时，通过在已部署集群服务器上新增计算组进行扩展。
- 该方式在不增加物理服务器的情况下新增计算组。
- 可先参考附录配置 controller.cfg 的存算分离参数。
- 随后按相关步骤增加计算组进行配置。
删除计算组
在集群节点管理页面通过“删除计算组”按钮删除计算组。
- 集群节点管理页面的计算组区域提供“删除计算组”按钮。
- 删除操作以计算组为单位执行。
扩缩容计算组（增加/删除计算节点）
通过 Web 集群管理对计算组进行扩容或缩容，新增节点后需到总览页启动。
- 扩容时在集群节点管理中点击计算组下方“新增节点”。
- 新增节点默认处于关闭状态。
- 需到 Web 集群总览页面启动新增节点。
- 缩容时可在计算节点右侧点击“删除”完成删除。
存算分离架构性能测试概述
说明测试目标与总体结论：缓存命中与否影响查询性能、CPU 核数对复杂计算与并发吞吐的影响。
- 缓存未命中时，计算节点查询性能低于数据节点。
- 缓存命中时，计算节点查询性能优于数据节点。
- 复杂计算或多分区查询性能随 CPU 核数增加而线性提升。
- Python API 并发查询中，QPS 随并发数与 CPU 核数增加而提升。
硬件配置与测试环境
给出操作系统、CPU、内存、网络、磁盘等硬件配置，以及高可用集群与节点/计算组配置。
- 性能测试硬件为 4 台服务器。
- 操作系统为 CentOS Linux 7 (Core)。
- CPU 为 Intel(R) Xeon(R) Gold 5220R CPU @ 2.20GHz。
- 测试环境为高可用集群，数据采用双副本。
测试数据与分区/引擎设置
描述测试数据来源、分区规则、存储引擎与排序列设置。
- 测试数据为 2023 年 2 月的通联快照和逐笔成交数据。
- 分区规则为时间按天 + 股票维度 HASH50。
- 存储引擎为 TSDB。
- 排序列为“交易所类型 + 股票代码 + 交易时间”。
CPU 核数设定
说明存储服务器与计算组服务器 CPU 核数配置与梯度测试范围。
- 3 台存储服务器 CPU 核数设定为 12。
- 计算组服务器 CPU 核数梯度为 6、12、24、36 核。
计算组参数配置（测试用）
列出控制节点默认参数与计算节点缓存相关参数（内存/磁盘缓存、目录、元数据目录等）。
- 测试控制节点参数包含 enableComputeNodePrefetchData=true。
- 测试控制节点参数包含 computeNodeCachingQueryThreshold=1。
- 测试控制节点参数包含 computeNodeCachingDelay=360。
- 测试计算节点参数包含 computeNodeMemCacheSize=8192。
- 测试计算节点参数包含 computeNodeDiskCacheSize=262144。
数据库查询测试（冷/热查询与不同规模场景）
在计算节点与数据节点对比小范围查询、大范围查询与聚合计算，并给出部分量化结果与解释。
- 冷查询指无数据缓存情况下的查询。
- 热查询指冷查询结束一段时间后执行的查询。
- case 1 耗时（ms）：数据节点冷查询 24。
- case 1 耗时（ms）：计算节点冷查询 68。
- case 1 耗时（ms）：计算节点热查询 6。
预热缓存策略测试（enableComputeNodePrefetchData）
对比开启/不开启预热缓存时三次查询的耗时，并解释缓存触发机制与网络延迟差异。
- 预热缓存策略对应参数为 enableComputeNodePrefetchData。
- 开启预热缓存时第 1 次耗时为 12,237 ms。
- 不开启预热缓存时第 2 次耗时为 27,745 ms。
- 结论描述：不开启预热缓存时，触发缓存机制会先缓存到计算组再执行查询。
- 结论描述：开启预热缓存时仍下推到数据节点后异步缓存。
Python API 并发查询测试（QPS）
在 Python API 端进行并发查询压测，给出不同并发数的总耗时与 QPS，并说明 CPU 核数影响。
- 每次查询循环 100 次，并记录总耗时与 QPS。
- 场景 1：并发 1 的总耗时为 1.1s，QPS 为 92。
- 场景 1：并发 100 的总耗时为 5.5s，QPS 为 1,824。
- 结论描述：QPS 整体随并发数增长而增加。
- 并发较大或分区数较多时，性能受 CPU 核数影响较大。
总结
汇总存算分离在缓存命中、复杂计算与并发查询下的性能结论与参考价值。
- 缓存未命中时，计算节点查询性能低于数据节点。
- 缓存命中时，计算节点查询性能优于数据节点。
- 复杂计算或多分区查询性能随 CPU 核数增加而线性提升。
- Python API 并发查询中，QPS 随并发数和 CPU 核数增加而提升。
附录1：初次部署示例（4 台服务器）
给出 4 台服务器部署拓扑、IP、cluster.nodes/controller.cfg/cluster.cfg/agent.cfg 示例配置与启动验证截图说明。
- 示例使用 4 台服务器进行部署。
- 附录给出 P1-P4 的内网 IP 地址映射。
- cluster.nodes 新增 computeGroup 列表示计算组名称。
- computeGroup 列只能在计算节点后添加。
- 可在 Web 管理界面启动或关闭数据节点、计算节点和计算组节点。
Facts Index
| Entity | Attribute | Value | Confidence |
|---|---|---|---|
| 文章 | 发布日期 | 2025-02-10 | high |
| 文章作者署名 | 作者 | momo | high |
| DolphinDB | 存算分离能力引入版本与机制 | 自 3.00.2 版本起引入计算组概念；通过为计算节点设置计算组并允许计算节点对查询数据进行缓存，实现存算分离架构 | high |
| 本教程代码运行环境 | 最低版本要求 | 需要运行在 3.00.2 或更高版本的 DolphinDB server 上 | high |
| 存算分离架构 | 目的 | 通过将计算和存储资源分离，提高系统的灵活性和性能 | medium |
| DolphinDB 存算分离架构 | 实现方式 | 主要通过引入计算组的概念实现 | high |
| 计算组（compute group） | 组成与定位 | 由多个计算节点组成，是资源和故障隔离的基本单位 | high |
| 计算组 | 计算能力影响因素 | 每个计算组中计算节点数量和资源由用户配置，并直接影响计算组计算能力 | high |
| 计算组 | 缓存机制 | 拥有多级缓存机制；针对热点写入分区、热点查询分区和首次查询分区可采用不同缓存策略以优化查询性能 | medium |
| 存算分离架构 | 弹性扩缩能力 | 在业务高峰或低谷时期计算节点可以快速增减，且存储节点对此过程无感知 | medium |
| 存算分离架构 | 推荐场景 | 多个用户组之间的资源隔离 | high |
| 计算节点与计算组归属 | 归属约束 | 每个计算节点只属于一个计算组 | high |
| 权限管理与计算组访问控制 | 访问控制效果 | 管理员可控制用户对计算组访问；用户只能使用本计算组计算资源，避免组间相互干扰与资源竞争 | medium |
| 计算组之间故障隔离 | 影响范围 | 不同计算组之间的故障不会互相影响 | medium |
| 存算分离架构 | 推荐场景 | 数据节点和计算节点的隔离 | high |
| 存算分离架构 | 资源隔离收益 | 避免密集计算任务挤占数据节点 CPU 和内存等计算资源 | medium |
| 存算分离架构缓存 | 对存储节点访问影响 | 允许计算节点缓存常用查询数据，从而降低对存储节点的访问频率，减少对数据节点磁盘 IO 与网络 IO 资源占用 | medium |
| 存算分离架构 | 故障影响范围 | 计算节点出现故障时数据节点不会受到影响，从而提高数据访问和存储服务稳定性 | medium |
| 存算分离架构调度策略 | 示例策略 | 可将频繁查询分区缓存到计算节点；再次查询相同分区时调度到计算组，避免再次从数据节点读取产生的磁盘与网络开销 | medium |
| 存算分离架构 | 推荐场景 | Ad hoc（即席查询）场景的用户资源分配 | high |
| 计算组资源分配（Ad hoc） | 管理员分配方式 | 可为不同用户或用户组分配不同计算组，并使用固定 CPU、内存等资源配额 | medium |
| Ad hoc 查询资源控制 | 限制与调度 | 系统可按计算组配额限制分配资源，避免单用户占用过多；在计算组内可按用户或查询优先级动态分配计算资源 | medium |
| 控制节点参数 computeNodeCachingDelay | 含义/单位/默认值 | 分区最后一次更新后需经过设定时间间隔才能缓存到计算节点；单位秒；默认值 360 | high |
| 控制节点参数 computeNodeCachingDelay | 策略对应与作用 | 对应热点写入分区缓存策略；值不为 0 时分区更新后延迟到达才允许缓存，以避免频繁写入分区缓存导致不必要传输，并加速非频繁写入分区查询 | medium |
| 控制节点参数 computeNodeCachingQueryThreshold | 含义/取值范围/默认值 | 分区访问次数超过阈值后才允许缓存到计算节点；范围 [0, 32767]；默认值 1 | high |
| 控制节点参数 computeNodeCachingQueryThreshold | 策略对应与作用 | 对应热点查询分区缓存策略；值不为 0 时需达到访问次数才允许缓存，以仅缓存频繁访问分区并避免计算组存储资源浪费 | medium |
| 控制节点参数 enableComputeNodePrefetchData | 行为说明 | 当查询数据不在计算节点缓存中时，系统从数据节点获取数据并异步缓存到计算节点；否则（原文如此）将直接从数据节点获取数据并缓存到计算节点 | medium |
| 控制节点参数 enableComputeNodePrefetchData | 策略对应与效果 | 对应计算节点预热缓存策略；开启异步缓存后，本次查询仍下推到数据节点执行，结束后计算节点执行相同查询以拉取分区数据并缓存，以降低首次查询缓存未命中带来的网络传输代价并提升后续命中概率 | medium |
| 计算节点参数 computeNodeCacheDir | 含义与示例 | 计算节点缓存存储位置；示例 /ssd/ssd0/SCSeparationDDB/Disaggregation；多磁盘路径用“,”分隔且每个路径后加 /<ALIAS>（给出示例） | high |
| 计算节点参数 computeNodeCacheMeta | 含义与示例 | 计算节点缓存元数据地址；规则同 computeNodeCacheDir；示例为 /.../<ALIAS>/meta（支持多磁盘与多节点时每路径加 /<ALIAS>） | high |
| 计算节点参数 computeNodeMemCacheSize | 含义 | 计算节点内存缓存容量上限 | high |
| 计算节点参数 computeNodeDiskCacheSize | 含义 | 计算节点磁盘缓存容量上限 | high |
| 计算节点参数 enableComputeNodeCacheEvictionFromQueryThread | 含义 | 是否从计算节点缓存中逐出不再使用的数据 | high |
| 存算分离横向扩展示例架构 | 服务器与计算组部署 | 示例在 P4 服务器上部署计算组 cGroup1；计算节点由代理节点统一管理；读取未缓存数据时从数据节点获取 | medium |
| 存算分离架构 | 计算组节点部署限制 | 不限制计算组中节点部署在哪台服务器，用户可根据需求确定计算节点数量和所属服务器 | high |
| 在线动态扩展 | 新增服务器步骤（概述） | 先在新服务器部署代理节点（拷贝安装包、修改 agent.cfg、启动代理节点），再通过 Web 管理界面在线增加代理节点与新增计算组 | medium |
| Web 管理界面新增代理节点 | 入口 | 控制节点 Web 管理界面：配置管理 → 集群节点管理 → 新增节点 → 输入信息 → 保存 | high |
| Web 管理界面新增计算组 | 能力描述 | 点击“新建计算组”可设置计算组名称并添加计算节点；“批量添加”支持一次性配置多个计算节点 | high |
| 计算组参数配置（Web） | 配置方式 | 在计算组页面下方点击“新增一条配置”可增加配置项；不同计算组可设置不同参数以满足业务需求与资源优化分配 | medium |
| 集群节点配置新增配置 | 限定词规则 | 为指定计算节点配置参数需在“限定词”填写节点名；为多个计算组统一配置参数则不填限定词 | high |
| 纵向扩展部署 | 方式 | 在不增加物理服务器时利用现有服务器剩余资源新增计算组；可先参考附录1增加 controller.cfg 存算分离参数，再按 2.2.2 增加计算组步骤配置 | medium |
| 删除计算组 | 操作入口 | 集群节点管理页面下拉到计算组部分，每个计算组旁有“删除计算组”按钮 | high |
| 扩容计算组（增加计算节点） | 操作与注意事项 | 在集群节点管理中点击计算组下方“新增节点”设置参数并保存；新增节点默认关闭状态，需要到 Web 集群总览页面启动 | high |
| 缩容计算组（删除计算节点） | 操作 | 在集群节点管理中点击需要删除的计算节点右侧“删除”按钮完成节点删除 | high |
| 性能测试硬件 | 服务器数量 | 4 台服务器 | high |
| 性能测试硬件 | 操作系统 | CentOS Linux 7 (Core) | high |
| 性能测试硬件 | CPU 型号 | Intel(R) Xeon(R) Gold 5220R CPU @ 2.20GHz | high |
| 性能测试硬件 | 内存 | 16*32 GB RDIMM, 3200MT/s | high |
| 性能测试硬件 | 网络 | 9.41Gbps（万兆以太网） | high |
| 性能测试硬件 | 磁盘 | 6*3.84TB 固态硬盘 SATA 读取密集型 6Gbps 512 2.5 英寸 Flex Bay AG 硬盘, 1DWPD | high |
| 性能测试环境 | 集群形态与副本 | 4 台服务器搭建高可用集群，数据采用双副本 | high |
| 性能测试环境 | 前三台服务器节点配置 | 其中 3 台服务器配置 1 个控制节点、1 个数据节点、1 个计算节点 | high |
| 性能测试环境 | 第四台服务器节点配置 | 第 4 台服务器配置 1 个代理节点、1 个计算组，包含 2 个计算节点 | high |
| 性能测试数据 | 数据来源与时间范围 | 2023 年 2 月的通联快照和逐笔成交数据 | high |
| 性能测试数据 | 分区规则 | 时间维度按天 + 股票维度 HASH50 | high |
| 性能测试数据 | 存储引擎与排序列 | 存储引擎 TSDB；排序列为“交易所类型 + 股票代码 + 交易时间” | high |
| CPU 核数设置 | 存储服务器核数 | 3 台存储服务器 CPU 核数设定为 12 | high |
| CPU 核数梯度测试 | 计算组服务器核数梯度 | 6、12、24、36 核 | high |
| 测试用控制节点计算组参数 | 采用默认配置值 | enableComputeNodePrefetchData=true；computeNodeCachingQueryThreshold=1；computeNodeCachingDelay=360 | high |
| 测试用计算节点计算组参数 | 配置值 | computeNodeMemCacheSize=8192；computeNodeDiskCacheSize=262144；enableComputeNodeCacheEvictionFromQueryThread=true；computeNodeCacheDir=/ssd/ssd0.../Disaggregation/<ALIAS>,/ssd/ssd1.../<ALIAS>,/ssd/ssd2.../<ALIAS>,/ssd/ssd3.../<ALIAS>；computeNodeCacheMeta=/ssd/ssd0.../<ALIAS>/meta,/ssd/ssd1.../<ALIAS>/meta,/ssd/ssd2.../<ALIAS>/meta,/ssd/ssd3.../<ALIAS>/meta | high |
| 数据库查询测试设置 | 测试节点 | 在计算节点 cGroup1_node1 和数据节点 dnode1 上进行测试 | high |
| 数据库查询测试设置 | 写入后等待时间与参数对应 | 写入完成 5 分钟后进行查询和计算测试（对应 computeNodeCachingDelay 参数） | high |
| 冷/热查询定义（文中） | 冷查询与热查询含义 | 冷查询：无数据缓存情况下查询；热查询：冷查询结束一段时间后执行（对应 computeNodeCachingQueryThreshold），分区数据已在缓存中 | medium |
| 数据库查询测试数据源（case 1-3） | 数据源 | level-2 快照表（查询数据源为 level-2 快照表） | high |
| case 1 小数据量范围查询 | 数据规模与分区数 | 随机 1 只股票 1 天逐笔成交；约 12,613 行 * 19 列；内存占用 1.3 MB；分区数 1；计算节点 CPU=12 核 | high |
| case 1 查询耗时结果 | 耗时（ms） | 数据节点冷查询 24；计算节点冷查询 68；计算节点热查询 6 | high |
| case 1 结果解释（未命中缓存） | 原因 | 计算节点未命中缓存时需将查询下推到数据节点并返回结果，增加节点间网络 IO 开销，计算节点冷查询性能低于数据节点 | medium |
| case 1 结果解释（命中缓存） | 对比结论与原因 | 计算节点命中缓存时查询性能优于数据节点；因为数据节点分布在三台服务器且采用双副本存储，部分查询会产生节点间网络 IO 开销 | medium |
| case 2 大数据量范围查询 | 数据规模与分区数 | 全市场股票 1 天逐笔成交；约 92,352,296 行 * 19 列；内存占用 9.7 GB；分区数 50 | high |
| case 2 CPU 核数测试范围 | 计算组服务器 CPU | 6、12、24、36 核 | high |
| case 2 结果结论 | 性能趋势 | 查询涉及分区数较多时，查询性能随着计算组 CPU 核数增加而提高 | medium |
| case 3 大数据量聚合计算 | 任务与结果规模/分区数 | 按股票对全市场股票 1 周数据聚合，计算成交价最大值；结果约 6,463 行 * 2 列；内存占用 76 KB；分区数 250 | high |
| case 3 CPU 核数测试范围 | 计算组服务器 CPU | 6、12、24、36 核 | high |
| case 3 结果结论 | 性能趋势 | 大数据量聚合场景下，查询性能随着计算节点可用 CPU 核数增加线性提高 | medium |
| 计算组与数据节点在复杂计算中的对比 | 性能约束条件 | 计算组只能使用组内节点 CPU 资源；当计算组 CPU 总核数低于数据节点总核数时，数据节点在复杂计算中性能会优于计算组节点 | medium |
| 预热缓存策略 | 对应参数 | enableComputeNodePrefetchData | high |
| 预热缓存策略效果（文中解释） | 网络延迟 | 开启预热缓存后，查询符合条件分区时查询下推到数据节点，之后异步缓存，因此网络延迟更低 | medium |
| 预热缓存策略测试设置 | 执行次数与阈值对应 | 测试内容执行三次（对应 computeNodeCachingQueryThreshold 参数） | medium |
| 预热缓存策略测试任务 | 任务与结果规模 | 大数据量聚合计算：全市场股票 1 天数据计算买卖订单不平衡（Order Imbalance）；结果约 6450 行 * 3 列；内存占用 120 KB | high |
| 预热缓存策略测试结果（耗时） | 开启/不开启与三次查询 ms | 开启：第1次 12,237；第2次 11,216；第3次 17,888。不开启：第1次 11,814；第2次 27,745；第3次 18,756 | high |
| 预热缓存策略测试结论 | 触发缓存机制时差异 | 触发缓存机制时，不开启预热缓存会先缓存到计算组再执行查询，耗时显著高于其他场景；开启预热缓存仍下推到数据节点后异步缓存 | medium |
| 预热缓存策略测试资源对比 | 数据节点与计算组可用核数 | 数据节点 3 个（总可用核数 36 核）；计算组节点 2 个（总可用核数 24 核） | high |
| Python API 并发查询测试设置 | 循环次数与指标 | 每次查询循环 100 次，记录查询总耗时和每秒查询数 QPS；查询数据源为逐笔成交表 | high |
| Python 并发测试场景 1 | 数据规模与资源设置 | 范围查询：随机 1 只股票 1 天数据；约 16,800 行 * 19 列；内存占用约 1.8 MB；分区数 1；计算节点 CPU=12 核 | high |
| Python 并发测试场景 1 结果 | 总耗时与 QPS | 并发1：总耗时 1.1s，QPS 92；并发10：总耗时 1.8s，QPS 559；并发50：总耗时 3.7s，QPS 1,334；并发100：总耗时 5.5s，QPS 1,824 | high |
| Python 并发测试场景 1 结论 | QPS 趋势 | 每秒查询数整体随着并发数增长而增加 | medium |
| Python 并发测试场景 2 | 任务规模与分区数 | 大数据量聚合：按股票对全市场股票 1 周数据聚合，计算成交价最大值；约 6,463 行 * 2 列；内存占用 76 KB；分区数 250 | high |
| Python 并发测试结论（场景 2） | 影响因素 | 并发数较大或查询分区数较多时，查询性能受 CPU 核数影响较大 | medium |
| 总结：缓存未命中时查询性能对比 | 结论 | 查询未命中缓存时，计算节点查询性能低于数据节点 | medium |
| 总结：缓存命中时查询性能对比 | 结论 | 查询命中缓存时，计算节点查询性能优于数据节点 | medium |
| 总结：复杂计算/多分区与 CPU 核数关系 | 结论 | 复杂计算或查询涉及分区数较多时，计算组查询性能随可用 CPU 核数增加而线性提升 | medium |
| 总结：Python API 并发查询与吞吐 | 结论 | Python API 并发查询场景中，QPS 随并发数和 CPU 核数增加而提升 | medium |
| 附录1 部署示例 | 服务器与节点配置 | 4 台服务器：其中 3 台各配置 1 控制节点、1 数据节点、1 计算节点；第 4 台配置 1 代理节点与 1 计算组（含 2 个计算节点） | high |
| 附录1 内网 IP 地址 | IP 映射 | P1 10.0.0.80；P2 10.0.0.81；P3 10.0.0.82；P4 10.0.0.83 | high |
| cluster.nodes 配置变更 | 新增列与约束 | 修改 cluster.nodes 新增 computeGroup 列表示计算组名称；该列只能在计算节点后添加；每个计算节点只能属于一个计算组 | high |
| cluster.nodes 示例 | cGroup1 计算组节点示例行 | 10.0.0.83:8073:cGroup1_node1,computenode,cGroup1；10.0.0.83:8074:cGroup1_node2,computenode,cGroup1 | high |
| controller.cfg 存算分离参数示例 | 配置值 | enableComputeNodePrefetchData=true；computeNodeCachingQueryThreshold=1；computeNodeCachingDelay=360 | high |
| cluster.cfg 计算组参数范围 | 可指定粒度 | 允许为每个计算组或每个计算节点指定计算组参数 | high |
| cluster.cfg 统一配置参数示例 | 配置值 | computeNodeCacheDir（四盘路径含 <ALIAS>）；computeNodeMemCacheSize=8192；computeNodeDiskCacheSize=262144；enableComputeNodeCacheEvictionFromQueryThread=true；computeNodeCacheMeta（四盘 meta 路径含 <ALIAS>） | high |
| cluster.cfg 为整个计算组指定参数示例 | 限定符形式与示例值 | 使用 cGroup1%. 前缀：cGroup1%.computeNodeCacheDir（四盘路径）；cGroup1%.computeNodeMemCacheSize=8192；cGroup1%.computeNodeDiskCacheSize=262144；cGroup1%.enableComputeNodeCacheEvictionFromQueryThread=true；cGroup1%.computeNodeCacheMeta（四盘 meta 路径） | high |
| cluster.cfg 为计算节点单独指定参数示例 | 节点级配置示例值 | cGroup1_node1 与 cGroup1_node2：分别配置 computeNodeCacheDir、computeNodeMemCacheSize=4096、computeNodeDiskCacheSize=131072、enableComputeNodeCacheEvictionFromQueryThread=true、computeNodeCacheMeta（各自四盘 meta 路径） | high |
| agent.cfg（P4）示例 | 关键配置字段与值 | mode=agent；localSite=10.0.0.83:8801:agent4；controllerSite=10.0.0.80:8800:controller1；sites=...；workerNum=4；maxMemSize=4；lanCluster=0 | high |
| 集群启动与节点启停 | 操作方式 | 启动 P1/P2/P3 控制与代理节点以及 P4 代理节点后，可在 Web 管理界面启动或关闭数据节点、计算节点和计算组节点 | medium |