使用 SQL Server 处理大型数据集

Question

我正在寻找管理大量日志文件的数据集。我试图保持每月平均 150 万个新事件。我过去使用过访问权限，但显然不是为了这个，而且管理数据集是一场噩梦，因为我不得不将数据集分成几个月。

在大多数情况下，我只需要过滤事件类型并计算数量。但在我在数据导入方面做大量工作之前，我想看看是否有人可以验证这个 SQL Server 是一个不错的选择。是否有我应该避免的条目限制和存档条目？有没有办法归档条目？

另一部分是我从多个来源输入日志，有这么多的条目，将它们全部放入同一个表中是否明智，或者每个来源都有自己的表，以加快查询速度？

---

编辑...
没有连接，大约有 10 列。数据将通过视图过滤，我很想看看基于一个或多个列过滤的选择查询的结果是否有合理的响应时间？创建一组视图是否会加快频繁查询的速度？

Answer 1

根据我的经验，SQL Server 是一个很好的选择，您绝对可以期待 SQL Server 比 MS-Access 具有更好的性能，并且通常有更多的优化方法可供您使用。

我可能会像您所说的那样将这些东西放入 SQL Server Express 中，希望安装在您可以使用的最好的机器上（尽管您确实提到了只有 2GB 的 RAM）。使用一个表，只要它只代表一件事（我认为飞行员的飞行日志和软件错误日志不会在同一个“日志”表中，作为一个荒谬的人为示例）。检查你的表现。如果这是一个问题，请继续使用适用于您的 SQL Server 版本的任意数量的优化技术。

我最初可能会这样做：

如果您在日志表上使用 PK，则使用非聚集主键创建表 - 我通常使用 identity column 给我一个有保证的事件顺序（与重复的日期时间不同）并显示可能的日志插入失败（缺少身份）。在主日期时间列上设置clustered index（您提到您已经按月拆分为单独的表，所以我假设您也会以这种方式查询）。如果您有一些经常在此表上运行的查询，请务必查看它们，但不要期望通过简单地这样做来加快速度。您很可能希望根据这些查询中的 where 子句查看 indexing your table。在这里，您将为 SQL Server 提供有效运行这些查询所需的信息。

如果您无法通过优化查询、索引、使用尽可能小的数据类型（尤其是在索引列上）以及在体面的硬件上运行来获得所需的性能，那么可能是时候尝试partitioned views（这需要某种形式的持续维护）或partitioning your table。不幸的是，SQL Server Express may limit you 关于分区可以做什么，您必须决定是否需要迁移到 SQL Server 的more feature-filled edition。您始终可以使用企业评估版或开发版测试分区。

更新：

在大多数情况下，我只需要过滤事件类型并计算数量。

由于过去的日志不会改变（有点像过去的销售数据），因此在这种情况下，存储过去的汇总数字是一种常用的策略。您可以创建一个表，该表仅存储您每个月的计数，并每月（或每周、每天等）插入一次新的计数，其中包含某种预定的作业。使用 datetime 列上的聚集索引，SQL Server 可以更轻松地从实时表中聚合当前月份的数字，并将它们添加到存储的聚合中，以显示总计数的当前值等。

Answer 2

对我来说，这听起来像是一张表，它需要在您将过滤的列集上建立索引。限制通过视图访问通常是一个好主意，并确保您的索引真正被使用。

将每个源放入自己的表中将需要在以后的查询中使用 UNION，并且 SQL-Server 并不能很好地优化 UNION 查询。

“归档”条目当然可以手动完成，通过将日期范围内的条目移动到另一个表（可以存在于另一个磁盘或数据库上），或者使用“分区”，这意味着您可以将部分不同磁盘上的表（例如由日期范围定义）。您必须在规划 SQL-Server 安装时规划分区。

请注意，Express 版本限制为 4GB，因此每月 150 万行这可能是个问题。

我有一个像你这样的表，有 2000 万行，如果使用了索引，查询甚至连接都没有问题。