欢迎您来到 数字平台。 您尚未登录。[登录] [注册新用户]
当前位置: 论坛首页 / 栏目 产品与服务 / 文章 692

点击:19947[回复顶层] [树状] [详细]
[回复留言] [回复(需要先登录)] [引用(需要先登录)]普通文章第 1 楼
文章id: 692
关于操作日志的检索与汇总统计探讨



一直以来,我们的系统自带一个独立与数据库的日志记录机制,用以记录所有的数据变动情况。

这些日志记录,是将每天的数据操作信息记录在当天的一个文件中(二进制的XML格式)。系统有一个日志记录机制,主要的目的是顺序记录下数据的变动历史,以便追溯。同时可以根据这些变动历史回溯恢复受损的数据。

系统当前具备的日志恢复功能、相关日志统计窗中的统计功能,就是利用这些日志文件发挥相关作用的。

但由于日志文件是一个纯文本文件集,没有为它建立相应的索引,所以直接查询日志信息效率极低,也不方便查询。

曾有两家客户主动询问过能否开发出效率更高的日志查询功能?我们的答复是肯定的——只要形成了一个大家认可的日志提取字段内容,就可以借助于数据库存贮,构造出相关索引,从而实现检索、汇总。

由于没有更多客户跟进,我们也不方便擅自作主日志信息的抽取字段,所以此事就搁置一旁。

这两天,乐山师院彭老师在跟我聊天的时候,提及他已对日志文件作了些转换,并根据这些转换的结果开发了一个外挂查询汇总前端。再次触动我的神经,所以专开此帖,希望广大客户踊跃参与讨论,以便尽早确定这个日志库表格式及索取提取字段。

随后附上乐山师院彭老师跟我的交流内容:

彭老师  15:47:07
我都开发一个你们系统的日志分析工具,根据日志文件生成了操作日志,方便查找问题

孤舟蓑笠翁  15:48:23
对了,一直在说,空了整理一下操作日志,把各种操作类型分开后,存贮进数据库中,这样检索查询与统计效率就会更高
彭老师  15:48:20

彭老师  15:48:41
比较方便

这个是每天生成的日志
15:50:30
成功接收文件 
  
打开文件   打开所在文件夹 
彭老师  15:51:32
我刚才给你抓的屏就是两个月的数据,检索的是所有操作者是penx

这样处理了随时都可以查,而且很快

彭老师  15:52:12

彭老师  15:52:48
再双击一条可以看详细情况
孤舟蓑笠翁  15:53:08
你这就是整理出了一个通用的操作类型元素及字段
彭老师  15:53:08

 

孤舟蓑笠翁  15:54:29
不过,操作类型有很多,不太容易全弄成一个固定格式,所以我想通过客户参与,确定一个或多个不同的格式,这样好存贮进一个或多个操作表中
孤舟蓑笠翁  15:55:37
所以我想通过论坛,让客户提出来,关注什么样的操作类型,想提取什么样的字段内容?
彭老师  15:55:52

彭老师  15:56:07
分了这些类型,和检索途径
孤舟蓑笠翁  15:56:22
不错
孤舟蓑笠翁  15:57:05
允许我把你这些聊天记录都发布到公司论坛中不?
彭老师  15:57:16
可以

彭老师  16:00:32

彭老师  16:01:29
前面还有一半,是备份日志与执行流水更新,和我们办公系统关于报表数据的统计

 *********************************交流内容结束****************

随后,我们通过跟帖形式,探讨一下需要关注什么日志指标即可,无须操心程序界面。



发表时间: 2011-11-07 21:19:10
最后修改时间: 2011-11-07 21:20:13
[回复留言] [回复(需要先登录)] [引用(需要先登录)]普通文章第 2 楼
文章id: 693
彭老师关注的日志内容



根据彭老师发来的其转换后日志文件,我初步认为彭老师关心的日志内容有如下信息(理解有误或有疏漏的话,请彭老师指正):

1、操作类型,2、操作时间,3、操作者,4、涉及的册条码,5、涉及的读者条码,6、涉及的读者记录路径,7、涉及的册记录路径。

以上信息,基本可以涵盖了借、还、预约、续借、赔书及超期违约金处理形成的日志内容。

但似乎没有考虑到目录、实体、期、采购等数据的增、删、改日志的检索与汇总?这些日志操作也提取出来的话,也有助于业务工作量的统计汇总,以及追溯相关记录变更的历史。这类日志,不涉及到读者证条码及读者记录路径。所以,可以考虑再调整一下相关日志提取字段以形成一个统一、兼顾的字段表。

当然,如果找不到统一的字段表,也可考虑形成两个体系。

我仅是抛砖引玉,希望大家继续讨论,表达自己认为应该提取及汇总的日志信息。最终我们将集思广益,形成最合理的操作日志数据库结构。



发表时间: 2011-11-07 21:36:06
[回复留言] [回复(需要先登录)] [引用(需要先登录)]普通文章第 3 楼
文章id: 694

作者: 精灵


    刚才看了江老师与彭老师的对话,回想起我以前查找日志的经历,个人感觉弄否在以下两个方面对日志这个功能进行一下改动。

    一、日志存储

    目前日志存储的时候采用文件存储方式,以天为单位,每天的日志单独保存为一个文件,这样不太利于用户对日志进行检索和备份。我们能否这样处理,在数据库中单独用一个库来保存日志,这样不但方便检索,也方便用户备份数据库。同时,这个数据库中的日志库能否让用户自定义库的存放路径。也就是说在第一次生成这个库的时候,由用户决定这个库的存放路径,这样做主要是考虑到用户服务器中硬盘配置不尽相同。如果用户的服务器磁盘工作模式为“RAID5”模式,或者用户把数据库存放到“NAS”中,并且机房配置了UPS的话日志数据库与其他数据库一起存放倒没什么问题。但是,如果用户服务器只有两块硬盘并且没有工作在RAID1模式下,那么日志库与其他库文件再存放在一起就会有点小麻烦。一旦数据库所在的硬盘损坏,并且用户每次做备份的时间间隔又长的话,那么用户的数据损失可能会非常大。但是,如果用户可以在生成日志库的时候自定义日志库的存放位置,把日志库存放到其他硬盘上,当出事时,只要是用户服务器的硬盘不是同时坏掉,那么用户都可以依靠日志或者是依靠其他书目库很方便的恢复数据。减少损失。。。

    二、日志的查找、显示

    我们能否在内务“文件菜单中”增添两项,一项为“日志查询窗”,一项为“日志显示窗”。

    1、“日志查询窗”:

    这个窗口采用跟其他查询窗口相同的处理方式,在窗口的上方显示两个标签一个为“简单”,一个为“逻辑”,在简单标签中显示“检索词”、“库名称”、“检索路径”、“匹配方式”,在“逻辑”标签中支持多检索点多条件的联合检索,同时在逻辑标签中设立时间段选项,可以精确到分钟,并且对于检索路径的配置可以用自定义的方式,也就是说用户可以自行定义检索点,就像其他库那样定义检索点。用户输入检索式之后,在窗口的下方显示出检索结果。

    2、“日志显示窗”

    用户点击检索结果后,系统把用户点击的检索结果装入“日志显示窗”,在“日志显示窗”中,我们可以使用双标签,一个标签为“HTML”,一个标签为“XML”。

    A、“HTML”标签

    “HTML”这个标签中显示用户的操作时间、操作类型,同时还显示出数据变动情况,也就是说显示出被修改的数据中哪个字段或子字段被修改过,并且显示出这条数据中的被修改的字段或子字段修改前的样子,以及修改后的样子。对于这条数据中没有修改的字段或子字段不做显示,这样方便用户分析数据。

    B、“XML”标签

    这个标签比较简单,就是显示出这条日志数据的原貌。



发表时间: 2011-11-14 13:16:32
最后修改时间: 2011-11-14 18:40:46
[回复留言] [回复(需要先登录)] [引用(需要先登录)]普通文章第 4 楼
文章id: 695
关键是一个数据库表结构



第一,存贮在什么地方不是什么问题。一般来说,可以允许管理员指定某个SQL数据库(不一定跟当前系统数据库在同一个SQL中),但为了节省数据库投入成本和管理成本,我觉得还是在同一个SQL数据库中开辟一个“日志库”即可。

第二,关键是找一个兼顾各种指标的库表结构——即所谓的字段。你如果仔细看当前系统的日志记录,应该可以看到每种数据操作类型的日志记录不尽相同,所以如果有心,可以归纳一个字段提取需求,以它形成一个“日志库中的表结构”。只要大家认为这个字段提取可以基本涵盖所需的操作查找、汇总统计即可。

第三,这个将操作日志记入“日志库”中,并不意味着要取消当前生成的“日志文件”方式。所以不用担心日志记录存贮在与数据所在同一个SQL数据库后,因数据库受损导致无法找到日志进行灾难恢复。何况,假如仅为了查询与汇总统计所需,“日志库”中的记录,有可能会有些取舍或不一定顺序存贮(比如按不同操作类型分表存贮,就不方便形成线性的顺序),所以也不容易实现顺序恢复的效果。

所以,假如我们把每条日志当成一条原始记录存贮进数据库中,并根据需求,提取相应的检索点字段,可能就是一个较好的解决方案——那么,关键是这些相应的检索点内容,你们认为需要有哪些呢?册条码、读者证条码、操作时间、操作者、操作类型(如有细分,则按操作子类型提取)是否就够?

无须担心那种编目、册登记等不涉及到读者的数据操作——如果不存在读者证条码,则该检索点为空即可。

彭老师的提取内容中,含有册记录路径和读者记录路径——我认为提取到了唯一性的册条码和读者证条码后,册记录路径和读者记录路径就可以据此找到,所以无须再提取后者。



发表时间: 2011-11-14 21:52:09
[回复留言] [回复(需要先登录)] [引用(需要先登录)]普通文章第 5 楼
文章id: 698
回复: 关键是一个数据库表结构

作者: xietao


==========

以下是引用 孤舟蓑笠翁 于 2011-11-14 21:52:09 发表的文字:

第一,存贮在什么地方不是什么问题。一般来说,可以允许管理员指定某个SQL数据库(不一定跟当前系统数据库在同一个SQL中),但为了节省数据库投入成本和管理成本,我觉得还是在同一个SQL数据库中开辟一个“日志库”即可。

第二,关键是找一个兼顾各种指标的库表结构——即所谓的字段。你如果仔细看当前系统的日志记录,应该可以看到每种数据操作类型的日志记录不尽相同,所以如果有心,可以归纳一个字段提取需求,以它形成一个“日志库中的表结构”。只要大家认为这个字段提取可以基本涵盖所需的操作查找、汇总统计即可。

第三,这个将操作日志记入“日志库”中,并不意味着要取消当前生成的“日志文件”方式。所以不用担心日志记录存贮在与数据所在同一个SQL数据库后,因数据库受损导致无法找到日志进行灾难恢复。何况,假如仅为了查询与汇总统计所需,“日志库”中的记录,有可能会有些取舍或不一定顺序存贮(比如按不同操作类型分表存贮,就不方便形成线性的顺序),所以也不容易实现顺序恢复的效果。

所以,假如我们把每条日志当成一条原始记录存贮进数据库中,并根据需求,提取相应的检索点字段,可能就是一个较好的解决方案——那么,关键是这些相应的检索点内容,你们认为需要有哪些呢?册条码、读者证条码、操作时间、操作者、操作类型(如有细分,则按操作子类型提取)是否就够?

无须担心那种编目、册登记等不涉及到读者的数据操作——如果不存在读者证条码,则该检索点为空即可。

彭老师的提取内容中,含有册记录路径和读者记录路径——我认为提取到了唯一性的册条码和读者证条码后,册记录路径和读者记录路径就可以据此找到,所以无须再提取后者。

==========

这件事情提出来很有些日子了。

我觉得要避免两个极端的方向:

一个是认为日志库是万能的,需要什么信息在里面一检索就得到了。持有这个想法的朋友,多半是对数据库的能力和限制不了解导致的。目前的日志文件和日志记录结构,首先是为忠实描述日志信息而设计的,也就是说,它唯一的目的就是要保存好日志信息,在恢复的时候能完整恢复以前的信息。因为操作类型的复杂性,所以日志记录的格式非常复杂。这个复杂性不是我们开发者人为造成的,而是实际业务的复杂性导致的。

而,把全部日志记录集合起来成为一个“数据库”,那么其中的记录的格式就必须在某种程度上达成统一。数字平台现在的XML数据库结构,已经不要求记录格式如关系数据库的库表那样整齐划一,可以有相当程度的灵活性;但这也并不意味着什么记录都可以装入一个数据库。如果数据库中的记录格式无法统一,那就无法设计出检索点抽取代码,无法设计出浏览代码,...。这样的数据库只能成为一个垃圾堆,而不是“数据库”了 --- 想要检索的东西检索不出来、数据无法有效利用。

(如果谁不屑于我的这个说法,请设计一个万能的日志库记录结构给我看看。)

为什么一个具有完整功能的书目库需要有配套实体库、期刊库、订购库、评注库等等构成? 这就是数据结构复杂性的一个典型例子。(dt1000曾经实践过把各种业务数据都放在MARC中,但最后证明效率上不是最优,在数据结构设计上也是一个冒险而失败的例子)

在上个世纪90年代,图书馆自动化在国内刚刚兴起的时候,也出现过十几二十年的思想迷乱过程,很多人出于非常原始的想法,以为关系数据库的结构一定能描述好来自西方的MARC数据结构。实际上MARC数据结构完全是为了描述图书馆书目信息而产生的,并没有考虑到所谓数据库乃至关系数据库的方便性。从历史的发展过程来看,恰恰是所谓的数据库技术在不断发展变化以便解决服务于关键业务的本质需要的问题,而不是反过来让业务去符合所谓的数据库技术。

现今,半结构化或者无结构化的数据库都是很多的,世界上并不是只有关系数据库这一种。关系数据库经过努力,可以变革地满足半结构化的需求。但不应该是反之。

另外一个是认为日志库是无能的,什么也解决不了。持有这个想法的朋友,恐怕多是因为在技术上知道的事情太多而有消极遁世的倾向。从统计的角度,确实可以设计出一些具体的数据库结构,满足具体的统计需求,或者一边运作一边改进。虽然远远不是完美主义所期望的那样美好,但确实可以解决很多实际的问题。

所以,请注意避免走两个极端。过程必然是曲折的,会有不少反复。在没有达到一个比较理想的程度以前,我也看不清那个局面到底是一个什么样的局面。



发表时间: 2011-11-17 14:48:09
最后修改时间: 2011-11-17 14:54:54



页 1 / 1
 

在线用户
(无) 
当前栏目在线用户数 0, 总在线用户数 0