配置¶

使用gsctl部署交互式服务的可配置项¶

在使用gsctl部署Interactive时，可以配置多种项目。对于名为item-name的可配置项，您可以按如下方式设置其值：

gsctl instance deploy --type interactive [--item-name=value]

以下是所有可配置项的列表：

项目名称	默认值	描述	起始版本
coordinator-port	8080	协调器服务端口	v0.3
admin-port	7777	交互式管理服务的端口	v0.3
storedproc-port	10000	交互式存储过程服务的端口	v0.3
cypher-port	7687	Cypher服务的端口号	v0.3
config	None	引擎交互服务的自定义配置文件	v0.4

端口¶

默认情况下，Interactive将在以下端口启动这些服务：

协调器服务: 8080
交互式元数据服务端口: 7777
交互式Cypher服务端口：7687
存储过程服务: 10000

您可以根据需要自定义这些端口。例如：

gsctl instance deploy --type interactive --coordinator-port 8081 --admin-port 7778 --cypher-port 7688 --storedproc-port 10001

服务配置¶

默认情况下，Interactive会使用其默认设置初始化服务。然而，GraphScope Interactive被设计为灵活且能适应您的特定需求。这意味着您可以使用自定义配置来调整服务的行为。

自定义您的服务配置¶

要自定义服务的设置，您可以提供一个YAML配置文件interactive_config.yaml。该文件允许您指定各种参数，从目录路径到日志级别，确保服务符合您的要求。要使用自定义配置，只需将YAML文件传递给命令，如下所示：

gsctl instance deploy --type interactive --config ./interactive_config.yaml

注意

请注意，您无需配置所有选项。只需根据需求调整相关设置即可。任何未配置的选项将自动采用默认值，具体细节将在后续章节中说明。

示例配置¶

以下是一个典型YAML配置文件的大致示例：

log_level: INFO # default INFO, available(INFO,WARNING,ERROR,FATAL)
verbose_level: 0 # default 0, should be a int in range [0,10]. 10 will verbose all logs
compute_engine:
  thread_num_per_worker: 1  # the number of threads for each worker, default 1
compiler:
  planner:
    is_on: true
    opt: RBO
    rules:
      - FilterMatchRule
      - FilterIntoJoinRule
      - NotExistToAntiJoinRule
  query_timeout: 20000  # query timeout in milliseconds, default 20000

分片服务¶

Interactive的核心查询引擎采用基于Seastar的hiactor框架开发。Seastar采用无共享SMP架构运行，其中每个核心独立运作，不共享内存、数据结构或CPU资源。每个Seastar核心通常被称为一个分片(shard)。

通过利用future-promise API和协作式微任务调度器，分片服务显著提升了性能和吞吐量。然而，这种配置也可能导致潜在问题：由于分片调度算法可能将请求路由到繁忙的分片，即使某些分片处于空闲状态，传入请求仍可能遭遇延迟。这在Interactive中尤为棘手，该服务通常托管两个子服务——QueryService和AdminService。关键在于，即使QueryService处于高负载状态，AdminService也必须保持响应能力。

如discussion-4409中所讨论的，一个潜在的解决方案是为处理不同请求分配不同的分片。这种方法呈现了三种场景：

常规场景: 在此场景中，用户可能执行复杂和简单查询，因此需要专门分配一个分片来处理管理请求。但由于该分片不处理查询请求，整体系统性能可能会下降。
性能关键场景: 在此场景中，用户追求Interactive的最高性能。所有分片都用于处理查询请求，管理请求由它们并发处理。因此，可能会出现请求延迟的情况。

默认情况下，Interactive 配置为常规操作，包含以下内容：

http_service:
  sharding_mode: exclusive # In exclusive mode, a shard is exclusively reserved for admin requests. In cooperative mode, both query and admin requests can be processed by any shard.

通过更改为sharding_mode: cooperative，您可以充分利用所有计算能力来运行QueryService。

可用配置¶

在下表中，我们使用.符号来表示YAML结构中的层级关系。

属性名称	默认值	含义	起始版本
log_level	INFO	数据库日志级别，可选INFO/WARNING/ERROR/FATAL	0.0.1
verbose_level	0	数据库日志的详细级别，应为整数类型	0.0.3
compute_engine.thread_num_per_worker	1	用于处理查询的线程数。增加该数值可以提高查询吞吐量	0.0.1
compiler.planner.is_on	true	确定是否在编译Cypher查询时启用查询优化	0.0.1
compiler.planner.opt	RBO	指定用于查询优化的优化器。目前仅支持基于规则的优化器(RBO)	0.0.1
compiler.planner.rules.FilterMatchRule	不适用	一个优化规则，将过滤条件(`Where`)下推到`Match`子句中	0.0.1
compiler.planner.rules.FilterIntoJoinRule	N/A	一个原生的Calcite优化规则，在执行连接操作前将过滤条件下推到Join参与者	0.0.1
compiler.planner.rules.NotMatchToAntiJoinRule	N/A	将"不存在"模式转换为反连接操作的优化规则	0.0.1
compiler.query_timeout	3000000 ｜编译器等待引擎回复的最长时间，单位为`ms`	0.0.3
http_service.sharding_mode	exclusive	HTTP服务的分片模式。在exclusive模式下，一个分片专门保留给服务管理请求。在cooperative模式下，查询请求和管理请求都可以由任何分片处理。	0.5

待办事项¶

目前我们仅允许在实例部署期间进行服务配置。在不久的将来，我们将支持：

图级别配置
修改服务配置