跨团队在线会议调度场景下时序数据存储与查询方案咨询

现有思路的问题 #

你最初的按用户存储动态时间字段的设计存在明显缺陷：将时间戳作为实体属性键会导致Datastore索引爆炸，2周共336个小时对应每个用户要新增数百个动态索引字段，存储成本和查询效率都会受影响。

至于你纠结的两种查询逻辑：

• 先拉A队可用时段再逐个查对应可用团队：单次请求需要触发数百次Datastore查询，延迟太高
• 遍历20支待匹配团队逐个计算适配时段：仅适合待匹配团队规模极小的场景，扩展性差

推荐实现方案 #

你提出的按时段为独立实体存储可用团队列表的倒排索引思路是完全正确的，非常适配你的业务场景，是这类小数据规模时段匹配问题的最优解。

落地优化细节 #

1. 调整用户可用时间存储结构
   不要用时间作为动态属性键，改用数组存储可用时段即可，Datastore对数组字段的原生查询支持足够满足需求：

{
  userId: '123456',
  availableSlots: ['2021-11-14T12:00:00+0000', '2021-11-14T14:00:00+0000']
}

2. 保留团队可用状态预计算逻辑
   用户更新可用时间、或者每日定时任务触发时，重新计算用户所属团队的所有时段可用状态：单团队最多6人，只要单时段可用人数≥4就标记为团队可用，计算量极小完全无压力。

3. 时段倒排索引的查询逻辑
   当需要为A队匹配最多20支其他团队的会议时间时：

• 第一步先拉取A团队的所有可用时段列表（最多336条）
• 第二步批量查询这些时段对应的可用团队列表实体
• 第三步按业务需要聚合结果：要按时段展示可用团队就按时段分组，要按团队展示可用时段就按团队分组

单次批量查询300多条Datastore记录的延迟极低，完全满足使用需求。

通用标准方案说明 #

这类时段匹配问题根据数据规模有两类通用方案：

• 中小规模（时间窗口≤1个月，待匹配团队≤100支）：就用你想到的时段倒排索引方案，开发成本低，运行效率足够
• 大规模（时间窗口更长，待匹配团队数更多）：可用位图（BitMap）优化，每支团队的可用时段用二进制位存储，匹配时直接做按位与运算，计算速度极快，存储空间也更小，不过你的场景暂时不需要用到这个方案。

落地注意事项 #

• 所有时段统一用UTC时间存储，避免多时区用户的适配问题
• 定时清理超过2周的过期时段实体，减少不必要的存储开销
• 如需支持更长时长的会议（比如2小时），只需匹配连续N个时段同时满足双方可用即可，逻辑扩展非常方便

内容的提问来源于stack exchange，提问作者Graham