使用 Postgres，类似 Google Docs 的版本历史记录会是什么样子？

Question

经过一些初步研究，我正在尝试确定一个可扩展的解决方案，用于为 Postgres 表实现类似 Google 文档的版本历史记录。困难在于这些表具有一对多和自引用一对多关系，因此我研究的解决方案看起来需要创建大量附加数据。举个例子，假设我有下表。

table A {
    id         string          
    name       string          
    created_at date         
    updated_at date                 
}

table B {
    id          string  
    title       string 
    text_data   json (used in a rich text editor)
    b_id        string?
    a_id        string
    created_at  date 
    updated_at  date       
}

表 A 与表 B 具有一对多关系。表 B 可以与其自身具有一对多关系（想象一下类似嵌套子项的情况）。

目标是类似 Google Docs 的“版本历史记录”，其中记录 A 或 B 的更改，并且可以恢复 A 或 B 的先前/历史版本。

在研究中，我发现了“历史表”模式，但无法找到一对多和自引用一对多关系的实现方式。两个表是否都有自己的历史表（例如

A_History

和

B_History

），其中历史表相关？

另一种方法是使用当前表，但添加可用于确定当前版本的新列。类似于

start_date

和

end_date

，其中如果

end_date

是

null

那么该行就是当前版本。

但无论哪种情况，考虑到需要跟踪 A 或 B 的任何更新，数据量似乎都会很大。 Prisma 用于定义数据库模式并作为 ORM。

使用 Postgres 的可扩展解决方案是什么样的？

Answer 1

我觉得你可以采取两种主要方法来解决这个问题。

1。在历史表中存储 A 和 B 中所有行的完整历史记录 当有人更新 B 中的一行时，该行的旧版本将被插入到 B_History 中，新版本将被插入到 B 中。这将产生大量重复数据，并且可能会占用大量存储空间。

2。存储版本之间的差异 与上面的相同，但不是每次存储各个版本之间的差异时都存储记录的整个版本。您可以将其视为各个提交之间文件中的 git diff。 这应该会减少存储需求，但是您必须计算差异，并且当您想要回滚到以前的版本（或者甚至只是向用户显示以前的版本）时，您必须逐一重新应用差异。 （如果你想从版本 X 到 X-3，你必须 X -> X-1 -> X-2 -> X-3，每个箭头代表将差异重新应用到记录的版本）

将历史记录存储在一张表中，将当前版本存储在另一张表中，这样查询当前版本的速度就不会受到存储了多少个历史版本的影响，如果您有历史版本和当前版本，则不会出现这种情况同一表中的版本并使用 start_date - end_date 方法。

我不确定您的目标规模是多少，但通过created_at对历史表进行分区并创建适当的索引应该可以让您处理数十百万行而不会出现重大问题。

其他需要考虑的事情是限制要存储的历史版本的数量。例如，仅存储最后 X 个版本或仅存储上个月创建的版本。 您需要多少粒度的历史版本？如果用户花费 5 分钟对 B 中的记录进行连续编辑，应该产生多少个历史版本？是否应该在用户每次“点击保存”时创建一个新版本，或者您是否同意每 10 分钟创建一次快照？每小时？每天？

最后，我不知道 A-B 和 B-B 关系的业务含义是什么，但是当 A 发生更改时，您可能必须对与 A 相关的所有 B 进行历史记录，以捕获完整的历史记录。