高分区键基数场景下CosmosDB变更源性能缓慢问题咨询

唯一值分区键是否属于不合理设计 #

唯一值分区键本身并不违反CosmosDB设计规范，但你当前的使用方式触发了CosmosDB的底层限制：CosmosDB物理分区的拆分触发条件为单分区存储达到50GB或吞吐量持续超过10000RU，你虽然用了最高基数的分区键，但只要总数据量/吞吐量没达到拆分阈值，整个events容器只会保留1个物理分区，对应的变更源也只会有1个处理分片，不管你扩容多少Function实例，同一时间最多只能有1个实例拿到租约处理数据，这就是你扩容无效的核心原因。

按天合成分区键的选型建议 #

{设备ID}|{日期}格式的合成分区键是IoT+Event Sourcing场景的最优选型之一，完全可以替代你当前的全唯一分区键：

• 基数足够高：单设备单天的粒度既可以避免单设备上报量过大导致的长期热分区问题，也能让物理分区更快达到拆分阈值，获得更多的变更源并行处理分片
• 兼容现有查询逻辑：你原来使用STARTSWITH的查询逻辑不需要做任何修改，查单设备全量事件直接用STARTSWITH(分区键, "deviceXXX|")即可
• 可控热分区的影响极低：单设备单日的热分区只会影响当天的分片，次日自动切换到新的分区键值，完全在可接受范围内

你遗漏的核心问题 #

• 租约容器配置错误：6个独立Function共享同一个lease容器时，必须为每个Function配置独立的LeaseCollectionPrefix参数，否则不同Function的租约会互相抢占干扰，导致部分Function无法正常分配处理资源
• 变更源配置未优化：默认配置下Function每次拉取的事件数偏少，你可以调大MaxItemsPerInvocation参数，单次拉取更多事件，减少网络开销，提升单实例处理吞吐量
• 写入逻辑未做批量优化：如果你的Function当前是单条事件触发一次CosmosDB写入，改成批量写入视图数据，能大幅降低CPU占用，提升处理速度

紧急缓解方案 #

如果不想立即修改分区键逻辑，可以先临时将events容器的RU提升到12000以上，触发CosmosDB自动拆分物理分区，至少得到2~3个物理分区后再调回正常RU值，此时变更源会生成对应数量的处理分片，你扩容的Function实例就能被正常调度，延迟问题会得到明显缓解。

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