2

我正在数据库中设计一个表，它将存储来自应用程序的日志条目。有几件事让我比平时更多地考虑这个设计。

  • 然而，系统将在运行时使用这些日志条目来做出决定，因此它们需要相对快速地访问。
  • 他们还有一个问题是他们会很多（我估计每月增加 1250 万）。
  • 我最多不需要超过过去 30 到 45 天的时间来进行决策处理。
  • 对于支持和法律问题，我需要将所有这些保留超过 45 天，可能至少 2 年。
  • 表设计相当简单，所有简单类型（没有 blob 或任何东西），在可能的情况下将使用数据库引擎放入默认数据，最多一个外键。
  • 如果有任何不同，数据库将是 Microsoft SQL Server 2005。

我在想的是让它们写入实时表/数据库，然后使用 ETL 解决方案将“旧”条目移动到存档表/数据库 - 它很大并且在较慢的硬件上。

我的问题是您是否知道数据库/表设计的任何提示、技巧或建议，以确保它尽可能好地工作？另外，如果您认为这是一个坏主意，请告诉我，您认为更好的主意是什么。

4

4 回答 4

3

一些数据库提供“分区”（例如 Oracle）。分区就像一个视图，它将具有相同定义的多个表收集到一个中。您可以定义将新数据分类到不同表中的标准（例如，月份或一年中的一周 %6）。

从用户的角度来看，这只是一张桌子。从数据库 PoV 来看，它是几个独立的表，因此您可以高效地对它们运行全表命令（如截断、删除、从表中删除（无条件）、加载/转储等）。

如果你不能有一个分区，你会得到与视图类似的效果。在这种情况下，您可以在单个视图中收集多个表并重新定义该视图，例如，每月一次以从其余表中“释放”一个包含旧数据的表。现在，您可以高效地归档此表，清除它并在完成大工作后再次将其附加到视图中。这应该对提高性能有很大帮助。

[编辑] SQL server 2005 及更高版本（企业版）支持分区。感谢米奇小麦

于 2009-01-28T09:36:28.083 回答
1

大表速度很快，使用 ETL 从大表中提取基于日期的数据然后删除旧行是一个很大的性能开销。对此的答案是使用多个表 - 根据您的数据可能每月 1 个表。当然，您需要一些逻辑来在查询中生成表名。

我同意使用触发器来填充“CurrentMonthAudit”表，在月底，您可以将该表重命名为 MonthAuditYYYYMM。使用 ETL 将旧表从您的主服务器移出将很容易，并且您的每个表都将是可管理的。相信我，这比尝试管理大约 2.5 亿行的单个表要好得多。

于 2009-01-28T10:06:46.790 回答
1

你的第一个好决定是让一切尽可能简单。

我对您的简单只写事务日志文件模式很幸运，其中记录只是按时间顺序排列。然后，您有几个选项可用于切换过时的数据。只要您牢记简单，即使每月拥有不同的表也是可管理的查询方式。如果您有任何类型的复制在运行，您的复制表可以展开并用作存档。然后在每个月的第一天从一张新的空桌子开始。

通常我对做这样的事情的关系设计后果感到不寒而栗，但我发现只写按时间顺序排列的日志表是通常设计模式的一个例外，因为你在这里处理的原因。

但远离触发器。越远越好。最简单的解决方案是您在此处讨论的那种类型的主表，具有简单、健壮且经过时间验证的复制机制。

（顺便说一句 - 如果设计得当，大桌子不会很​​快变慢 - 它们会变慢。）

于 2009-01-28T10:17:22.260 回答
0

如果您不需要搜索最近的日志记录，还有另一种选择：根本不使用数据库。相反，将日志信息写入文件并每晚轮换文件名。写入文件后，您可以启动后台作业将数据直接导入存档数据库。

数据库并不总是最好的选择，尤其是对于日志文件 :)

于 2009-01-28T12:21:45.380 回答