python - 使用 DVCS 进行 RDBMS 审计跟踪

Question

我正在为一个相当复杂的关系数据库实施审计跟踪，它的模式很容易改变。我正在考虑的一种途径是使用 DVCS 来跟踪更改。

^{（我能想象的好处是：无模式历史，整个系统状态的快照，用于分析、回放和迁移的标准工具，高效存储，独立系统，保持数据库清洁。数据库不是大量写入，历史不是核心功能，更多的是为了进行审计跟踪。哦，我喜欢尝试疯狂的新方法来解决问题。）}

我不是这些系统的专家（我只有基本的 git 熟悉度），所以我不确定实施起来会有多困难。我正在考虑采用 mercurial 的方法，但可能将文件内容/清单/变更集存储在键值数据存储中，而不是使用实际文件。

数据行将被序列化为 json，每个“文件”可以是一行。或者，可以将整个表存储在“文件”中，每一行位于与其主键相等的行号上（假设表不是太大，我希望所有表的行数都少于 4000 左右。这可能意味着可以自动生成变更集，而无需查阅表“文件”的其余部分。

^{（但我对此表示怀疑，因为我认为我们需要整个文件的 SHA-1 哈希。文件可能会被可预测的行数分割，例如0 < primary key < 1000在文件 1、1000 < primary key < 2000文件 2 等中，使它们保持较小）}

是否有熟悉 DVCS 内部或一般数据结构的人可以评论这样的方法？怎样才能让它发挥作用，甚至应该完成它吗？

我想这样的系统有两个方面：1）将 SQL 数据映射到 DVCS 系统和 2）将 DVCS 数据存储在键/值数据存储（而不是文件）中以提高效率。

^{（注意我的 ORM 涵盖了 json 序列化位）}

Answer 1

我自己研究了一下，这里有一些评论要分享。

虽然我曾认为使用 python 中的 mercurial 会使事情变得更容易，但 DVCS 有很多不必要的功能（尤其是分支、合并）。我认为简单地窃取一些设计决策并根据我的需要实现一个基本系统会更容易。所以，这就是我想出的。

斑点

系统生成要归档的记录的 json 表示，并生成此记录的 SHA-1 哈希（如果您愿意，则为“节点 ID”）。此哈希表示该记录在给定时间点的状态，与 git 的“blob”相同。

变更集

更改被分组到更改集中。变更集记录一些元数据（时间戳、提交者等）并链接到任何父变更集和当前“树”。

树木

我没有使用 Mercurial 的“清单”方法，而是选择了 git 的“树”结构。树只是 blob（模型实例）或其他树的列表。在顶层，每个数据库表都有自己的树。下一个级别可以是所有记录。如果有很多记录（经常有），可以将它们拆分为子树。

这样做意味着，如果您只更改一条记录，您可以不理会未触及的树木。它还允许每条记录都有自己的 blob，这使得事情更容易管理。

贮存

我喜欢 Mercurial 的 revlog 理念，因为它允许您最小化数据存储（仅存储变更集），同时保持快速检索（所有变更集都在同一个数据结构中）。这是在每条记录的基础上完成的。

我认为像 MongoDB 这样的系统最适合存储数据（它必须是键值，而且我认为 Redis 过于专注于将所有内容保存在内存中，这对于存档并不重要）。它将存储变更集、树和 revlogs。当前 HEAD 等的一些额外键和系统已完成。

因为我们使用的是树，所以我们可能不需要将外键显式链接到它所指的确切“blob”。仅使用主键就足够了。我希望！

用例：1. 归档更改

一旦进行了更改，记录的当前状态就会被序列化为 json，并为其状态生成一个哈希值。这是针对所有其他相关更改完成的，并打包到一个变更集中。完成后，更新相关的 revlog，使用新对象（“blob”）哈希生成新树和子树，并使用元信息“提交”变更集。

用例 2. 检索旧状态

在找到相关的变更集（MongoDB 搜索？）之后，然后遍历树，直到找到我们正在寻找的 blob ID。我们转到 revlog 并检索记录的状态或使用可用的快照和变更集生成它。然后用户必须决定是否也需要检索外键，但是这样做很容易（使用我们开始使用的相同变更集）。

概括

这些操作都不应该太昂贵，并且我们对数据库的所有更改都有一个节省空间的描述。存档与生产数据库分开保存，允许它做自己的事情并允许随着时间的推移对数据库模式进行更改。

Answer 2

如果数据库不是大量写入（如您所说），为什么不以实现目标的方式实现实际的数据库表呢？例如，添加一个“版本”列。然后永远不要更新或删除行，除了这个特殊的列，您可以将其设置为 NULL 表示“当前”，1 表示“最旧的已知”，然后从那里上升。当您想更新一行时，将其版本设置为下一个更高的版本，然后插入一个没有版本的新版本。然后，当您查询时，只需选择具有空版本的行。

Answer 3

看看 cqrs 和 Greg Young 的事件采购。我还有一篇关于在元事件中工作的博客文章，它指出了业务事件河流中的模式变化。

http://adventuresinagile.blogspot.com/2009/09/rewind-button-for-your-application.html

如果您浏览我的博客，您还会发现版本脚本方案，并且您可以对它们进行源代码控制。