收集审计和统计数据

时间:2011-03-22 18:52:33

标签: architecture schema design-patterns

我的问题是我在大型Web应用程序中发生了很多事件,现在我想看看发生了什么(用于审计目的),或者我想汇总数据以进行统计报告。

一种解决方案是在DB中为每种类型的事件创建一个表并将其记录在那里。例如密码被更改,记录日期,用户,IP等。这将为我提供我需要的审计信息,以及针对表运行报告的能力,以查看此功能的使用频率。缺点是我需要为我想要捕获的每种类型的事件创建一个新表。

我理想的解决方案是拥有一个具有更灵活结构的表,也许是一个XML字段,但我并不为表中的xml字段而疯狂。

所以我的问题:是否有一个很好用(流行)模式来解决我的问题?

2 个答案:

答案 0 :(得分:2)

您的大型网络应用程序有多大?

将事件记录为XML blob应该可以正常工作,并且某些数据库(例如SQL Server)允许您直接查询该XML。但是,这些查询的性能很糟糕。

在数据库中进行事件记录之前,您应该计算出每秒要创建的记录数。 如果数量很大,则会对数据库造成严重负担,并可能影响整体应用程序性能。 此外,一旦累积了大量记录,查询数据将永远需要(并在此过程中终止数据库性能)。聚合数据更糟糕 - 关系数据库在进行聚合时效率不高。

Chris上面的建议适用于小型数据库,但由于您的查询必须使用连接,因此无法扩展。最好将数据去标准化。

即使您的应用程序没有获得足够的流量让您现在担心这一点,请记住,由于上述原因,记录到数据库的事件将无法很好地扩展。

建议:

如果您没有那么多流量并且决定登录到数据库,请将其执行到单独的架构,这样您就可以更轻松地将其移动到单独的数据库服务器以便从你的生产数据库。

如果您决定将事件记录为xml,请考虑使用关系数据库是否有意义 - 如果您无法有效地查询,那么简单的日志文件会更简单。当然,你必须弄清楚如何处理这些日志数据,但是对于不常见/简单的查询,使用grep,awk等编写一些脚本会花费你很长的路。

现在(非常)大规模应用程序常用的方法是记录到文件,然后使用map-reduce运行分析(聚合),例如:在hadoop。

答案 1 :(得分:1)

每个事件一个表与一个表之间的中间路径是(假设事件之间的差异是事件携带的参数/数据):

Event Type
  Event Type Id (PK)
  Name
  Number of parameters (useful - not essential)

Event
  Event Id (PK)
  Event Type Id (FK)
  Timestamp

Event Attribute
  Event Attribute Id (PK)
  Event Id (FK)
  Name 
  Value (as string in all cases)
  Sequence Number (within Event. this may well not be needed, but can be a convenience)

我不认为这是一个命名模式,但它是一种在数据库设计中反复出现的模式。

我认为这可以为您提供所需的所有信息,而无需存储XML。

相关问题