高效审计的方法

5
我正在尝试为我的Spring Boot应用程序实现审计层。目前我尝试了两种方法。
1) 创建1个审计表,包含字段:user_name、table_name、column_name、old_value、new_value、uuid、event_type。每当有更改被保存时,将填充审计实体并将其保存。
优点:
- 快速 - 只有一个审计表,易于管理
缺点:
- 有时涉及从业务实体到审计实体的太多映射 - 必须从数据库中获取旧值以填充审计实体 - 手动创建审计实体 - 检索可能很麻烦
2) 使用Javers进行审计
优点:
- 自动创建和更新审计实体 - 较少数量的表需要管理 - 不需要检索旧值
缺点:
- 由于事务规模较大,所需时间太长
基准测试
处理具有20个字段(列)的10行表(实体):
使用方法1所需的时间:24328毫秒 => 24秒
使用方法2所需的时间:311292毫秒 => 311秒(近12倍)
3) 没有使用Hibernate Envers,因为创建的表数会很多。
有人能提出一个在上述优缺点的情况下更好的审计想法吗?我们的目标是:
- 少量表需要管理 - 响应时间短 - 模块化审计层,更多的是自动化而不是手动的
每个表中有10到25列。

哪个数据库提供程序? - CodeScale
1
你尝试过在低优先级的后台线程中运行审计吗?我将使用带注释的Spring AOP,并在单独的后台线程中运行批处理的更新。此表的数据源也应分离,以便审计不会以任何方式修改应用程序的BU。 - Gaetano Piazzolla
使用 Oracle 数据库 - a_good_human
3个回答

2
正如您所说,创建审计跟踪的常见方法是使用应用程序库,例如envers或Javers。这些库被挂钩到持久性库中,它们会维护数据表中的特定列(“createdBy”,“lastUpdated”等),并/或将早期记录版本复制到某种历史表中。
虽然这种方法有一些缺点:
- 在OLTP事务中将记录写入历史表会增加执行的语句数量 -> 可能导致应用程序响应时间更长 - 支持批量更新和删除 - 直接在数据库中进行的更改无法跟踪
通过3个步骤进行变更数据捕获:
1. 捕获变更数据 2. 将变更数据转换为目标数据库支持的格式以进行上传 3. 将数据上传到目标数据库
另一种技术是数据库触发器。它们不会错过任何操作,无论是来自应用程序还是数据库本身。批量语句也将被处理。
触发器CDC的另一个优点是应用程序不知道您已添加了整个审计层。但是,当作为OLTP事务的一部分执行触发器时,仍然存在延迟增加的问题。
触发器的替代解决方案(Postgresql):使用逻辑复制将数据库更改(解码的WAL消息)从主服务器流式传输到从服务器,使用WAL并启用Audit触发器以捕获在从服务器上复制的表中的更改。
当利用交易日志作为审计源并使用变更数据捕获检索更改信息并将其发送到消息代理或持久日志(如Apache Kafka)时,就不存在上述问题。通常被认为是更优越的CDC方法,但不是最容易设置的解决方案。
异步运行,CDC进程可以提取更改数据而不影响OLTP事务。
每当有数据更改时,都会向事务日志添加一个条目。
对于批量操作中更新或删除的每个记录,都将有一个日志条目,因此可以为每个更改事件生成一个更改事件。
剩下的问题是CDC如何访问元数据,例如执行数据更改的应用程序用户、其IP地址、跟踪跨度ID或任何类型的关联ID。
一种方法是拥有一个单独的表,其中存储了这些元数据。应用程序可以为每个事务在该表中存储一个记录,并具有特定的transactionId。数据更改事件将包含与更改相关联的transactionID,因此可以将数据更改事件和元数据记录相关联。

1
我会采用以下方法:
1)使用低优先级的后台线程进行审计
2)使用Spring AOP和注释来将BU与AUDITING分离
3)每次插入或更新实体时,在NOSQL数据库文档中写入完整的json化对象,带有UID;同时旧值无用,因为可以通过运行简单的查询来追溯实体的更改

0

显然,您没有正确使用Javers,您的数字不可靠。也许您为每个提交创建了新的Javers实例?

Javers是一个像审计工具一样快速的工具。 Javers只是为更改的对象创建快照并将它们插入到数据库中。每个快照对应一个数据库记录/文档。

因此,如果您更改一个对象,通常Javers会执行一个数据库读取以获取其先前的快照,并执行一个数据库插入以写入新的快照。


1
每次都会进行差异检查以查看前一个快照和当前快照之间的更改。有没有办法忽略差异检查,只创建快照? - a_good_human
不,我使用了单例的javers实例。 - a_good_human
Javers执行一次数据库读取以获取其先前的快照 - 有没有办法跳过这个步骤? - a_good_human
1
不是一个好主意。数据审核是关于跟踪更改的。如果您在没有进行差异检查的情况下提交,这将意味着编写大量重复的快照(并且在大多数数据库中,写入比读取更昂贵会导致性能下降)。 - Bartek Walacik
实际上,我们会为每个实体添加最后更新时间。因此,差异始终存在。 - a_good_human

网页内容由stack overflow 提供, 点击上面的
可以查看英文原文,
原文链接