SkyWalking BanyanDB 引入分片键优化 TopN 聚合性能

在分布式时序数据库 BanyanDB 中，数据分片策略对查询性能有着至关重要的影响。近期社区针对 TopN 聚合查询的性能优化提出了一个重要改进方案——通过引入 sharding_key 分片键来优化数据分布。

当前分片策略的局限性

在现有实现中，BanyanDB 默认使用 name 和 entity 的组合作为数据分片依据。这种分片方式在处理 TopN 聚合查询时存在明显性能瓶颈：

1. 每个分片只包含部分 TopN 列表数据
2. 查询时需要从多个分片获取数据并聚合
3. 增加了查询延迟和磁盘 I/O 开销

特别是在服务监控场景下，当需要计算某个服务的 TopN 实例时，相关实例数据可能分散在不同分片上，导致查询效率低下。

分片键优化方案

新方案提出了在 Stream 和 Measure 模型中增加可选的 sharding_key 字段：

• 该字段用于指定数据分片依据
• 默认值为 entity，保持向后兼容
• 允许用户根据业务场景灵活配置

例如，在服务监控场景中，可以将 sharding_key 设置为 service_id。这样，同一服务的所有实例数据会被分配到相同分片：

service_1-10.0.0.1 → shard0
service_1-10.0.0.2 → shard0

技术实现要点

1. 模型扩展：在 Stream 和 Measure 元数据中增加 sharding_key 字段
2. 分片路由：改造现有的分片路由算法，支持基于分片键的数据分布
3. TopN 优化：确保 TopN 聚合结果与原始度量数据位于相同分片
4. 兼容处理：对历史数据保持原有分片方式不变

预期收益

1. 查询性能提升：TopN 聚合查询只需访问单个分片
2. 资源利用率提高：减少跨分片数据传输和聚合计算
3. 配置灵活性增强：支持根据业务特征优化数据分布

应用场景建议

1. 服务监控：使用 service_id 作为分片键
2. 主机监控：使用 host_id 作为分片键
3. 应用性能监控：使用 application_id 作为分片键

这种分片键机制为 BanyanDB 提供了更精细的数据分布控制能力，特别适合需要频繁执行 TopN 聚合查询的业务场景。用户可以根据实际数据访问模式选择最合适的分片键，从而获得最佳查询性能。