背景图

通用日志表的设计

1. 快照表

表结构修改具有关联性,存储的数据比较多。可维护性很强。

2. JSON

2.1 记录修改前后值

这个性能可能和前面的快照表的性能损耗是一样的,要有很多修改的东西。

2.2 记录修改后的值

修改前的值可以用parent_id进行关联,这种方式可以解决我们的问题。但是root没有关联,需要将插入的数据保存一分过来。

2.3 记录修改的字段的值

这个和2.2 差不多只是,只序列化修改的字段,这样存储的信息更少。但是如果想要知道哪个字段的修改就无能为力,需要找到所有的更改记录。

3. 操作表+更改表

就是一个记录基本操作信息的表,然后另一张表记录修改哪张表的哪个字段,哪个值被改为哪个值。如果要查改动之前的值就是会有查询的操作,另外就是批量更改可能会产生大量需要更改的数据。

3.1 原值+现值

依然还是存储想要的值,但是只有修改的字段的原值和现值。

3.2 只记录现值

还是通过parent_id记录修改的历史,但是root必须是原来的值,所以插入的时候需要保存一份在这个地方。

原值的改动可以在第一次查询使用的时候,通过parent_id找到,这种方式的缺点是,无从知晓上一次本字段是在哪次编辑的,反正找打了就要存下来。如果原值不需要查询,那么在生成日志的时候就一起存下来。有的原值是NULL,这样就达不到缓存的策略,所以可以设置为空字符串也不要设置为NULL,这样缓存策略才能生效。

其实parent_id这种方式只能保证更改的记录串行而已,但是无法确定一个字段的原值,通过parent-id进行回溯,可能存在次数过多的问题。所以应该在记录filed的这张表设置中加入被修改表的信息,以及修改的记录id的信息,通过记录id和字段名找到所有值,这样就可以知道原来的值是什么了,排序就是事件的发生顺序,所以应该没有问题。

4. No SQL的存储

这种存储方式,可能会出现数据不好解析的问题,因为我们可能是进行序列化的。MongoDB可能比较适合,我们能进行相应数据的查询。但是普遍没有事务的支持。

还有一种文档存储就是基于Lucene的存储,一般我们不会直接使用Lucene,而是使用封装好的结构进行存储,比如说solr和EleasticSearch。

5. 列存储

如果进行列存储的话,其实可以解决我们的不少问题。我其实比较倾向于使用列存储的方式来解决我们遇到的问题。表格存储最大的好处就是列信息可以变动。

6. 日志文件打印

日志文件的打印不一定是打入到文件里面去,也可以打印到流里面去。网上有很多网络流的工具,比如apache的flume。

当然也可以打印到日志文件中,这样由第三方的工具再从日志文件中读取分析。但是读取的数据需要分析存储。当然这需要工具记录上次的读取位置。

7. MQ中继方式

将数据直接推送至MQ中,或者直接发给flume,再由flume推送到MQ中。一般有3层机制也有多层的架构机制。

使用这些机制的原因是一层一层的速度放缓,其实这就是本质,flume快速接受,MQ推送可以暂存一部分数据,然后storm或者spark进行分析,进一步完成数据的分析过程,又是一层的数据放缓,最后存储最终整理或者分析后的数据。

当然hadoop是用来处理离线数据的。

总结

以上就是我对通用日志的一些总结信息,想到数据分析的作用,日后如果有新的想法,我会继续加入改进。

0%