正确的数据更新架构

Question

过程

我通过几个 cron 更新内容。一些 cron 更新来自不同来源的元数据，一些更新来自不同来源的价格，一些将内容推送到市场等。

到目前为止，每个进程都会在内容表上添加一列，例如“last_amazon_update”，并在其中存储时间戳。然后，crons 获取 X 最旧的更新并更新它们，并将时间戳设置为现在，这将其置于“列表的末尾”。 此外，插入的所有新内容都将此列设置为空，并且 cron 也会抓取它们。

限制

主要的限制是我使用的API的配额：这就是为什么我无法一直更新所有内容，甚至无法在内容创建后立即从API获取数据。 其次，我想对计算有一点了解。

问题

我不喜欢这种存储更新信息的方式，因为它会干扰内容表本身并使内容表超载。它唯一的优点是，在每次 cron 运行时，都会通过查询检索要更新的内容，以获取必须更新的内容（不需要加入或任何其他内容）。

我正在 NodeJS 中使用谷歌云、firestore 和 postgre。

目前，除了将这些数据放入连接表而不是内容表本身之外，我不知道。

Answer 1

是的，在我看来，用与更新信息相关的内容来超载内容表并不是很好，它会在获取/插入/更新期间产生一些影响。

正如您所提到的，在我看来，有一个单独的表是 goto 方式，类似于

ContentUpdate

，其中有一些列，例如

content_id

、

update_provider

、

update_timestamp

来帮助您根据需要加入和排序。

使用该表，您应该能够根据需要对提供者执行查询，并根据需要添加/删除数据提供者。这将为监控/调试数据提供者开辟许多新的可能性（例如保存更新的状态、请求所花费的持续时间、添加批次 ID 以及检查该批次期间处理了多少数据等）

此外，如果您提前知道 api 速率限制，您可以使用一些帮助程序执行分页查询（例如 kysely 的 this，或者带有 node-postgres 的经典

Cursor

），它可能会帮助您获得一些收益就性能/数据库负载而言。

通过这种设计，它提出了一个新问题，如何处理新插入的内容初始更新？我认为你有两个选择：

• 在批处理期间，稍微复杂化 sql 查询以选择新

  ContentUpdate

  表中不存在的所有内容，并根据

  update_timestamp

  添加到剩余内容之后。
• 在内容创建过程中，在

  ContentUpdate

  表中插入一些虚假数据，因此您仍然可以进行简单的查询，但该表中会有不真实的数据。