Firestore批量操作特殊场景的额外写入问题及解决方案咨询

会触发多笔写入的Firestore特殊场景 #

以下操作或特殊值会导致单个批量操作消耗2次写入配额：

• serverTimestamp：正如你遇到的情况，当写入包含serverTimestamp()的字段时，Firestore会先写入一个占位符标记，待服务器生成实际时间戳后再执行一次更新，因此整个操作会消耗2次写入。即使同一个文档中包含多个serverTimestamp字段，也只会触发2次写入，而非每个字段单独计数。
• arrayUnion/arrayRemove：这类原子数组操作需要先读取当前数组的状态，再执行修改写入，因此每次操作消耗2次写入配额。
• increment() 数值递增：原子递增操作同样需要先读取当前字段值，再写入新的递增后的值，单次操作消耗2次写入。

解决方案 #

针对你遇到的本地计数器计算错误问题，以及多写入消耗的场景，可以采用以下方案：

1. 调整本地计数器逻辑 #

维护两个计数器分别跟踪：

• 批量操作的操作数：Firestore批量操作最多允许500个操作，这个计数器不能超过500。
• 实际写入消耗配额：根据操作类型累加，普通操作加1，包含上述特殊值/操作的加2。

在Golang SDK中，可以通过递归检查写入数据是否包含特殊类型来判断计数，示例代码：

import "cloud.google.com/go/firestore"

// calculateWriteCost 计算单个写入操作的消耗配额
func calculateWriteCost(data interface{}) int {
    switch val := data.(type) {
    case firestore.ServerTimestamp:
        return 2
    case map[string]interface{}:
        for _, v := range val {
            if calculateWriteCost(v) == 2 {
                return 2
            }
        }
    case []interface{}:
        for _, v := range val {
            if calculateWriteCost(v) == 2 {
                return 2
            }
        }
    }
    // 检查原子操作类型
    if _, ok := data.(firestore.Increment); ok {
        return 2
    }
    if _, ok := data.(firestore.ArrayUnion); ok {
        return 2
    }
    if _, ok := data.(firestore.ArrayRemove); ok {
        return 2
    }
    return 1
}

2. 替代serverTimestamp（业务允许的情况下） #

如果业务场景对时间戳的精度要求不高，不需要严格依赖服务器时间，可以直接使用客户端当前时间（如time.Now()）替代serverTimestamp()，这样单个写入操作只会消耗1次配额，避免额外的写入消耗。

3. 优化批量拆分策略 #

根据实际写入消耗配额来拆分批量，而不是仅按操作数拆分。例如，若你的单批次允许的最大写入配额是1000，那么当加入一个操作后总消耗超过1000时，就提交当前批量并新建一个，确保不会超出配额限制。

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