存储消息的修订更改

Question

像 stackoverflow 和 Wikipedia 那样存储修订更改涉及哪些算法和流程？

是否只保留一份消息副本？如果是这样，它只是最新的副本吗？ 那么只从那里存储返回到以前版本的更改？ （这将有助于更快地显示主要消息）。 或者存储完整的消息？如果是这样，每个显示器上的这些之间是否进行了比较？

什么算法最适合确定消息中的确切更改？ 这些数据如何存储在数据库中？

如果有人确切知道 Wikipedia 或 stackoverlfow 是做什么的，我很想知道。

Answer 1

Mediawiki（维基百科的软件）存储所有修订版的全文，请参阅数据库架构。 Mediawiki 中的文本表中的每个条目都有标志来告诉内容是否已被例如gziped，使用标准压缩通常是最明智的选择。

我无法告诉您如何通过算法进行差异，但无论您使用哪种算法，都应该从文本的两个完整版本中进行比较。即从数据库中获取旧对象和新对象的完整版本，然后进行比较。这使得可以轻松地更改比较算法。

Git 是 Unix 应用程序的一个很好的例子，它可以进行非常便宜的（存储和速度）增量存储。有一些 wiki 可以使用 git，例如ikiwiki，但我猜你想用数据库来做到这一点。

Answer 2

最长公共子串算法可以用来检测版本之间的差异，但它是有限的。例如，它不会检测文本的移动，但会将其视为不相关的删除和插入。

我认为网站通常会完整存储最新的副本，并从那里应用反向差异。这也是 CVS 的工作方式，但是 Subversion 使用前向差异，这会导致结账速度变慢。

要将其存储在数据库中，可以维护一个包含最新版本的主表，并拥有一个具有相反差异的单独表。该表的行格式为

(article_id, revision_id, differences)

.

Answer 3

通常消息被存储为完整的快照。以前的版本已被禁用，并显示最新版本。可能会使用诸如缓存最新版本之类的优化。

Answer 4

典型的修订版本更改是使用增量算法存储的，因此存储的唯一数据是每个修订版本相对于原始版本的更改。我不确定维基百科或 stackoverflow 他们是如何实现它的。

Answer 5

我会使用以下技术：

• 将当前消息存储为完整文本。
• 使用 delta 算法存储历史记录。

这将使您的常规显示保持良好的性能，同时将历史记录的存储空间保持在最低限度。