ScyllaDB 工作负载属性（Workload Attributes）：用 Service Level 定义超时与负载类型

ScyllaDB 工作负载属性Workload Attributes用 Service Level 定义超时与负载类型【免费下载链接】scylladbNoSQL data store using the Seastar framework, compatible with Apache Cassandra and Amazon DynamoDB项目地址: https://gitcode.com/GitHub_Trending/sc/scylladbScyllaDB 中同一集群往往同时运行延迟敏感型OLTP与吞吐优先型OLAP等多种工作负载。本文基于官方文档 workload-attributes.rst 讲解如何通过Service Level服务级别的 CQL 命令为每个工作负载定义timeout与workload_type两类属性并结合源码剖析属性校验、多角色合并merge与调度组生效的完整链路读完后你能够独立完成工作负载属性的定义、绑定与验证。背景为什么需要工作负载属性一个典型的数据库里同时运行着多个可接受的延迟、吞吐水平各不相同的 :term:workload workload工作负载。ScyllaDB 通过“定义每个工作负载的属性”来区分对待请求当请求被分配到某个工作负载时数据库按照该工作负载的属性进行处理。工作负载属性通过service level概念定义。Service level 的 CQL 命令允许你把属性附加到用户user和角色role上当用户登录系统时附加在该用户自身以及授予给该用户的所有角色上的全部属性会被合并combined形成一组“工作负载属性”workload attributes。Service Level 的完整生命周期管理创建、分配、列表、删除请参阅 Workload Prioritization。从源码结构看每个 service level 最终会映射为一个 Seastar 调度组scheduling group由 service_level_controller 统一管理。该控制器在注册指标时会为每个 service level 输出workload_type指标取值含义为0 - unspecified, 1 - batch, 2 - interactive见 register_metrics可用于监控确认属性是否真正生效。前提条件执行工作负载属性操作前需要一个已认证且已授权的用户至少一个已创建的角色CREATE ROLE。定义工作负载属性的操作流程第一步创建带属性的 Service Level语法CREATE SERVICE LEVEL service_level_name WITH attribute [ AND attribute];例如创建一个超时为 500ms、负载类型为 interactive 的服务级别CREATE SERVICE LEVEL sl2 WITH timeout 500ms AND workload_typeinteractive;第二步将 Service Level 绑定到角色或用户语法ATTACH SERVICE_LEVEL service_level_name TO role_name|user_name;例如把sl2绑定到角色scyllaATTACH SERVICE LEVEL sl2 TO scylla;修改属性ALTER SERVICE LEVEL属性的修改通过ALTER SERVICE LEVEL完成ALTER SERVICE LEVEL service_level_name WITH attribute [ AND attribute];例如将sl2的超时清除恢复默认ALTER SERVICE LEVEL sl2 WITH timeout null;把属性设为null表示删除该属性而不是设为 0 或默认值——这一点在源码 sl_prop_defs::validate 中可以印证当timeout的字符串表示为null不区分大小写时会被解析为delete_marker删除标记而非一个时长值。可用属性一览当前文档定义的可用属性如下属性说明timeout指定 Service Level 的超时毫秒或秒见下文workload_type指定 Service Level 的负载类型unspecified / interactive / batch见下文另外从 sl_prop_defs.cc 的校验逻辑可以看到CQL 层接受的属性集合为{ timeout, workload_type, shares }——即还可通过WITH shares n取值 1–1000配置该 service level 的资源份额这与 Workload Prioritization 中按 shares 分配 CPU 资源的部分相呼应。指定 Service Level 超时timeout使用timeout属性为 service level 指定超时单位可以是毫秒或秒。例如CREATE SERVICE LEVEL primary WITH timeout 30ms;当不同工作负载的可接受延迟水平不同时分别指定超时值就很有意义交互式请求可以被快速失败fail fast而批量任务可以容忍更长的执行窗口。源码级取值约束sl_prop_defs::validate 中的get_duration函数对超时值做了严格校验这些约束比文档表述更精确不支持天/月单位——出现days或months成分时抛出Timeout values cannot be expressed in days/months必须为毫秒整数倍——纳秒值若不能被 1,000,000 整除则抛出Timeout values must be expressed in millisecond granularity即575ms合法、575.5ms非法必须非负——负值抛出Timeout values must be nonnegative。这些行为在功能测试 test_service_levels.py 中有完整验证测试用ALTER SERVICE LEVEL {sl} WITH timeout 575ms修改超时并断言读回Duration(0, 0, 575000000)纳秒又用timeout 2h验证小时单位可换算最后用timeout null验证清除语义并对一组非法输入逐一断言报错。指定工作负载类型workload_type使用workload_type属性为 service level 指定负载类型。例如CREATE SERVICE LEVEL secondary WITH workload_type batch;指定负载类型可以让 ScyllaDB 更高效地处理会话session——例如根据负载是否对延迟敏感来调整资源处理策略。可用负载类型负载类型描述unspecified无特定特征的通用负载默认值interactive延迟敏感的负载预期具有高/无界并发、动态特征即 OLTP 型负载。例如用户点击网站并产生点击事件的工作负载batch处理海量数据的负载对延迟不敏感预期具有固定并发即 OLAP 型负载。例如处理数十亿条历史销售记录以生成统计信息的工作负载源码中的枚举与解析规则负载类型在 service_level_options 中被建模为一个四值枚举enum class workload_type { unspecified, batch, interactive, delete_marker };其中delete_marker是内部标记用于表达“显式重置为 unspecified”这一动作。解析函数 parse_workload_type 只接受interactive与batch两个字符串外加null归一为unspecified其余取值返回空并触发Invalid workload type: {}异常。一个值得注意的细节在 sl_prop_defs.cc显式把workload_type设为unspecified时代码会将其转换为delete_marker从而真正重置掉先前设置的值而不是保持旧值不变。这与timeout null的清除语义一致说明属性系统对“未设置unset”与“显式删除delete”做了明确区分。登录时的属性合并语义当用户同时拥有自身直接绑定的属性以及通过角色继承的属性时这些属性会合并成一组有效工作负载属性。合并规则实现于 service_level_options::merge_withtimeout两个 service level 都设置了超时时取较小值std::min(d, *other_timeout)即更严格的超时生效——这与 Service Levels CQL 文档 中给出的示例一致role1 的 sl1timeout 2s与 role2 的 sl2timeout 10s合并后有效超时为 2sworkload_type已指定specified的类型优先于 unspecified——只要任一侧不是unspecified就优先取已指定的那一方shares补充两侧都设置时同样取较小值。合并结果还会记录每个属性值最终来自哪个 service levelslo_effective_names字段见 qos_common.hh并可通过LIST EFFECTIVE SERVICE LEVEL OF role命令查询 LIST EFFECTIVE SERVICE LEVEL OF role2; service_level_option | effective_service_level | value ------------------------------------------------------------ workload_type | sl2 | batch timeout | sl1 | 2s该命令的语句实现位于 list_effective_service_level_statement.cc是排查“这个属性到底从哪来的”最直接的手段。属性的存储与生效路径从源码结构看属性的落盘与生效路径是CQL 语句create_service_level_statement/alter_service_level_statement位于 cql3/statements/ 目录→ 写入 system 表的service_levels相关表 → 由 qos_common.cc 中的get_service_levels/get_service_level从表中读回读到的列包括service_level、timeout、workload_type、shares→ service_level_controller 为每个 service level 分配/复用调度组scheduling group命名模式为sl:{name}。集群中 service level 总数上限为 10 个含系统内置的default与driver因此用户最多创建 8 个——这一点在 workload-prioritization.rst 的 Limits 一节有明确说明。若调度组耗尽service_level_scheduling_groups_exhausted 异常会提示删除多余 service level。在查询执行侧workload_type与timeout最终随会话状态传递client_state 持有 service level 信息transport/server.cc 在建连与转发请求时依据timeout_config与timeout_for_sleep等机制落实每请求的截止时间例如 cql_server::sleep_until_timeout_passes 会在转发查询后等待到超时点再返回。验证与测试如果你想在当前仓库中验证上述行为推荐参考以下测试test/cqlpy/test_service_levels.py覆盖timeout/workload_type/shares的创建、修改、null清除与非法值报错以及LIST EFFECTIVE SERVICE LEVEL的合并展示test/boost/service_level_controller_test.cc针对service_level_controller调度组行为的单元测试test/cluster/auth_cluster/test_raft_service_levels.py 与 test_service_levels_self_healing.py基于 Raft 的分布式 service level 同步与自愈场景。小结用CREATE SERVICE LEVEL ... WITH timeout 500ms AND workload_type interactive定义工作负载属性用ATTACH SERVICE LEVEL ... TO role绑定到角色或用户timeout支持毫秒/秒源码要求毫秒整数倍、非负、禁止天/月单位设为null即清除workload_type取unspecified默认/interactiveOLTP、延迟敏感/batchOLAP、延迟不敏感显式设回unspecified会重置旧值多角色属性合并时超时取较小值、已指定负载类型优先可用LIST EFFECTIVE SERVICE LEVEL OF role追溯每个值的来源属性的存储、合并与调度组映射分别实现在 cql3/statements/sl_prop_defs.cc、service/qos/qos_common.cc 与 service/qos/service_level_controller.cc可进一步深入。相关文档Workload Prioritization、Service Levels CQL 命令参考。【免费下载链接】scylladbNoSQL data store using the Seastar framework, compatible with Apache Cassandra and Amazon DynamoDB项目地址: https://gitcode.com/GitHub_Trending/sc/scylladb创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考