大多数商业和一些开放源码的RDBMS平台(例如Postgresql)可以支持分区表,可以用这种方式来做这种事情.如何从日志中填充数据库作为读者的练习.

基本上,这种系统的结构如下：

>你有一个表分区
排序日期或日期时间值,
按小时,日期或任何地点划分
谷物似乎是合适的.日志
条目附加到此表.
随着时间窗滑下来
分区,定期工作索引或
总结并将其转换为
它的“冻结”状态.例如,a
Oracle上的工作可能会创建位图
该分区上的索引或更新
物化视图,包括总结
该分区的数据.
>以后,你可以删除旧的数据,
总结或合并分区
一起.
随着时间的推移,定期工作
后面填满了前沿
划分.历史数据是
转换为借出的格式
本身进行统计
查询前边缘
分区保持易于更新
很快.因为这个分区没有
有这么多的数据,查询
整个数据集是相对的
快速.

这个过程的确切性质在DBMS平台之间是不同的.

例如,sql Server上的表分区并不是很好,但是可以使用Analysis Services(Microsoft捆绑sql Server的OLAP服务器)完成此操作.这通过将领先分区配置为纯ROLAP(OLAP服务器简单地针对底层数据库发出查询),然后将尾随分区重建为MOLAP(OLAP服务器构建其自己的专用数据结构,包括称为“聚合”的持久摘要) ).分析服务可以完全透明地向用户完成.它可以在后台重建一个分区,而旧的ROLAP对用户仍然可见.一旦构建完成,它在分区中交换;多维数据集全部可用,不会中断服务给用户.

Oracle允许独立更新分区结构,因此可以构建索引,或者构建在实例化视图上的分区.使用Query重写,Oracle中的查询优化器可以计算出从基本事实表计算的聚合数据可以从物化视图中获取.查询将从分区可用的物化视图和未分区的前沿分区读取聚合数据.

Postgresql可能能够做类似的事情,但是我从来没有研究过实现这种类型的系统.

如果您可以通过定期停机生活,可以通过进行总结并设置对前导数据和尾随数据的视图来明确地进行类似的操作.这样就可以在不支持透明分区的系统上进行这种分析.但是,由于视图被重建,系统将会发生暂时中断,所以您在营业时间内无法真正做到这一点 – 最常见的是一夜之间.

编辑：根据日志文件的格式或可用的日志选项,有多种方式将数据加载到系统中.一些选项是：

>使用您喜欢的编程语言编写脚本,读取数据,解析相关位并将其插入数据库.这可能会相当频繁地运行,但你必须有一些方法跟踪你在文件中的位置.小心锁定,特别是在Windows上. Unix / Linux上的默认文件锁定语义允许你这样做(这就是tail -f的工作原理),但Windows上的默认行为是不同的;两个系统都必须写成相互发挥.
>在unix-oid系统上,您可以将日志写入管道,并且具有与上述读取管道类似的过程.这将具有所有的最低延迟,但读取器中的故障可能会阻止您的应用程序.
>为您的应用程序编写一个直接填充数据库的日志记录接口,而不是写出日志文件.
>为数据库使用批量加载API(大多数(如果不是全部都有这种类型的API可用))并批量加载日志记录数据.将类似的程序写入第一个选项,但使用批量加载API.这样做会比逐行填充更少的资源,但是设置批量加载的开销却更大.这是适合较不频繁的负载(可能是每小时或每天),并且对整个系统的压力较小.

在大多数这些情况下,跟踪你在哪里成为一个问题.轮询文件以查看更改可能会非常昂贵,因此您可能需要将记录器设置为使其以与日志读取器良好的方式工作.

>一个选择是更改记录器,以便每个时段(例如每隔几分钟)开始写入不同的文件.让您的日志阅读器定期启动并加载尚未处理的新文件.阅读旧文件.为了这个工作,文件的命名方案应该基于时间,因此读者知道要接收哪个文件.处理应用程序仍在使用的文件更加方便(您将需要跟踪已读取的内容),因此您只需要直到最后一段时间才能读取文件.另一个选项是移动文件然后读取它.这最适用于Unix类型的文件系统,但应该适用于NTFS.你移动文件,然后读取它.但是,它需要记录器以创建/追加模式打开文件,写入它然后关闭它 – 不要保持打开和锁定.这绝对是Unix的行为 – 移动操作必须是原子的.在Windows上,您可能必须站在记录器上才能使其工作.