在 postgres 中执行大规模 JSONB 替换的最有效方法答案

【问题标题】：Most efficient way to perform large scale JSONB replace in postgres在 postgres 中执行大规模 JSONB 替换的最有效方法
【发布时间】：2021-07-28 01:11:00
【问题描述】：

我有近 200 万条记录需要对类似此部分记录的标识符数组中的值进行简单的字符串替换

    {
      "id": "a851375d-f6a0-4fba-ba69-c584901de73c",
      "source": "MARC",
      "title": "Voice Content and Usability [electronic resource] / So, Preston.",
      "identifiers": [
        {
          "value": "9781952616020",
          "identifierTypeId": "fcca2643-406a-482a-b760-7a7f8aec640e"
        },
        {
          "value": "(CaSebORM)9781098128852",
          "identifierTypeId": "7e591197-f335-4afb-bc6d-a6d76ca3bace"
        },
        {
          "value": "5429852",
          "identifierTypeId": "d5989db8-ddc3-4f06-a465-73e99ec262d3"
        },
        {
          "value": "ocm00000001saf9781098128852",
          "identifierTypeId": "7e591197-f335-4afb-bc6d-a6d76ca3bace"
        }
]
}

我需要从最终值中检测并删除“ocm0000000”，并且我正在寻找最有效的方法。当我尝试简单地将 jsonb 转换为字符串时，请进行简单的字符串替换，例如

update my.table
set jsonb = REPLACE(jsonb::text, 'ocm0000000', '')::jsonb

它占用了 CPU 并占用了我们 RDS 集群的所有连接，从而干扰了其他操作，因此必须终止该进程。

当有这么多行受到影响时，进行这种替换的最佳方法是什么？

【问题讨论】：

“接受了所有的连接” 这不是一个可信的说法。 UPDATE 语句不会自发产生新的连接。（目前，他们甚至不使用并行化）。您在监控中看到什么让您产生这种想法？
数据库管理员联系我告诉我。当我查看监控时，我看到持续的大约 30 IOPS 到 > 50,000 IOPS 的峰值，并且系统中其他用户的其他事务没有通过——大概是那些挂起的连接。当我杀死我的 PID 时，发生了其他事务，IOP 恢复正常，事情和以前一样。无论如何，我想知道解决此类数据问题的最佳方法是什么。

标签： postgresql jsonb

【解决方案1】：

您当前的 UPDATE 将重写每一行，即使是不需要更改的行。您应该添加一个 WHERE 子句来防止这种情况。如果您想将更新分成多个批次，这一点尤其重要。

set jsonb = REPLACE(jsonb::text, 'ocm0000000', '')::jsonb
where jsonb::text like '%ocm0000000%'

完成此操作的最简单方法是声明一个维护窗口并直接执行此操作，或者在非工作时间执行此操作。对我来说，用 SSD 驱动器在小型笔记本电脑上更新 200 万份示例记录只用了不到 2 分钟。你说只是部分，但我不知道你的真实记录会大多少。也许您可以克隆我们的服务器并使用它来测试需要多长时间。您还可以临时预置更多 IOPS 以加快速度。

如果要批量运行，可以添加 where 子句来限制更新的 ctid 范围：

set jsonb = REPLACE(jsonb::text, 'ocm0000000', '')::jsonb 
where jsonb::text like '%ocm0000000%' 
and ctid between '(0,0)' and '(9999,99)'; --first ~80MB.

然后您将等待系统喘口气，然后将 CTID 窗口向下滑动更远地重复。重复直到整个桌子都被覆盖。您应该只需要直到 ctid 中的第一个数字与表中的当前页面一样大。然后在没有 ctid 条件的情况下再运行一次，以确保没有任何遗漏。

【讨论】：

这个特定查询的可怕之处在于它几乎影响了每一行，因此故意缺少 WHERE。但是批量运行它是我一直在寻找的——然后我可以使用 WHERE 来避免扫描所有内容。您的回答让我意识到我可以使用的另一种机制是一个临时表，其中列出了带有序列号的 id，以控制一次处理的数量
注意CTID范围扫描每次都会扫描整个表，直到V14学会如何做得更好。它不会更改该区域之外的块，但仍会读取它们。所以会导致写 IO 小批量完成，而读 IO 会一遍又一遍地完成，所以如果问题不仅仅是写 IO 而是所有 IO，它可能会比原来的更糟糕。您也许可以选择一些索引用户列（不是 CTID）来进行范围扫描以获得更有效的阅读。