Architecture 收集审计和统计数据

我的问题是，我在一个大型web应用程序中发生了很多事件，有时我想看看发生了什么（出于审计目的），或者我想聚合数据以进行统计报告

一种解决方案是在DB中为每种类型的事件创建一个表，并将其记录在那里。e、 g.更改密码，记录日期、用户、ip等。这将为我提供所需的审核信息，并能够根据表格运行报告，以查看此功能的使用频率。缺点是，我需要为要捕获的每种类型的事件创建一个新表

我的理想解决方案是使用一个具有更灵活结构的表，可能是一个XML字段，但我并不热衷于将XML字段放在表中

---

因此，我的问题是：是否有一种使用良好的（流行的）模式可以解决我的问题？

每个事件一个表和一个表之间的中间方式是（假设事件之间的差异是事件所携带的参数/数据）：

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

---

我认为这将为您提供所需的所有信息，而无需存储XML。

您的大型web应用程序有多大

将事件记录为XML blob应该可以工作，一些数据库（例如SQL Server）允许您直接查询该XML。但是，这些查询的性能非常糟糕

在数据库中进行事件日志记录之前，您应该计算每秒要创建多少条记录。 如果这个数字很大，将给数据库带来严重的负载，并可能影响应用程序的整体性能。 此外，一旦您积累了大量记录，查询数据将花费很长时间（并在这个过程中破坏数据库性能）。聚合数据更糟糕——关系数据库在进行聚合时效率不高

上面Chris的建议对小型数据库很有效，但由于您的查询必须使用联接，因此无法扩展。最好是对数据进行非标准化

即使您的应用程序现在没有足够的流量让您担心这一点，也要记住，由于上面解释的原因，事件日志记录到数据库的扩展性不好

具体建议：

如果您没有那么多的流量，并且决定登录到DB，那么可以将其登录到单独的模式，这样您就可以更容易地将其移动到单独的DB服务器，以便将其从生产数据库中卸载

如果您决定将事件记录为XML，那么考虑是否使用关系数据库来达到目的——如果不能高效地查询，那么简单的日志文件会简单得多。当然，您以后必须弄清楚如何处理日志数据，但是对于不频繁/简单的查询，使用grep、awk等编写一些脚本需要花费惊人的时间

---

现在（非常）大规模的应用程序通常使用的方法是登录到文件，然后使用map reduce（例如在hadoop上）运行分析（聚合）。

谢谢Elad-感谢您的详细回复。有兴趣的是，您认为连接不会扩展的原因是什么？我一直认为连接实际上是零成本的，因此，对数据库或其模式的可伸缩性没有影响。@chris walton google“数据库连接不可伸缩”，您将得到大量的示例，主要来自NoSQL阵营。我还可以从个人经验中证明，一旦传递了特定的表大小（MySQL中只有1M条记录，尽管这在很大程度上取决于配置，尤其是RAM分配），连接查询的性能就会开始快速下降。感谢Chris-感谢模式和解释。

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)