Dan*_*iel 2 database sql-server logging sql-server-2008-express large-data
我正在寻找管理日志文件的大型数据集.我想保留每月平均150万个新事件.我过去曾使用过访问权限,虽然它显然不适用于此,管理数据集是一场噩梦,因为我不得不将数据集分成几个月.
在大多数情况下,我只需要过滤事件类型并计算数量.但在我对数据导入方面做了大量工作之前,我想看看是否有人可以验证这个SQL Server是一个不错的选择.我应该避免和存档条目的入口限制吗？有没有归档条目的方法？
另一部分是我从多个来源输入日志,有了这么多的条目,将它们全部放在同一个表中是明智的,还是每个来源都有自己的表,以便更快地进行查询？
编辑...
没有连接,大约10列.数据将通过视图进行过滤,我很想知道基于一列或多列过滤的select查询的结果是否会有合理的响应时间？创建一组视图是否可以加快频繁查询的速度？
根据我的经验,SQL Server是一个很好的选择,你可以期待SQL Server比MS-Access更好的性能,通常你可以使用更多的优化方法.
我可能会继续把这些东西放到SQL Server Express中,如你所说,希望安装在你可以使用的最好的机器上(虽然你确实只提到了2GB的RAM).使用一个表只要它只代表一件事(我认为飞行员的飞行日志和软件错误日志不会在同一个"日志"表中,作为一个荒谬的人为例子).检查你的表现.如果这是一个问题,请继续使用您的SQL Server版本可用的任意数量的优化技术.
这是我最初可能会这样做的:
如果在日志表中使用PK,则使用非群集主键创建表 - 我通常使用标识列为我提供有保证的事件顺序(与重复日期时间不同)并显示可能的日志插入失败(缺少标识) ).在主日期时间列上设置聚簇索引(您提到您已按月拆分为单独的表,因此我假设您也将以这种方式查询).如果你经常在这个表上运行一些查询,那么一定要查看它们,但不要指望通过这样做来加速.您可能希望根据这些查询中的where子句来查看对表的索引.在这里,您将为SQL Server提供有效运行这些查询所需的信息.
如果您无法通过优化查询,索引,使用尽可能小的数据类型(特别是在索引列上)并在合适的硬件上运行来获得所需的性能,那么可能是时候尝试分区视图(需要某种形式的持续性)维护)或分区你的桌子.不幸的是,SQL Server Express 可能会限制您使用分区所能做的事情,并且您必须决定是否需要转移到功能更丰富的SQL Server 版本.您始终可以使用Enterprise评估版或Developer版测试分区.
更新:
在大多数情况下,我只需要过滤事件类型并计算数量.
由于过去的日志不会发生变化(有点像过去的销售数据),因此存储过去的总数是这种情况下经常使用的策略.您可以创建一个表格,该表格只存储每个月的计数,并且每月(或一周,一天等)使用某种计划的作业插入一次新计数.使用日期时间列上的聚簇索引,SQL Server可以更轻松地从实时表中聚合当前月份的数字,并将它们添加到存储的聚合中,以显示总计数的当前值等.