静态cache之log共现词分析

标签: 性能优化 搜索引擎 静态cache 共现词分析 引擎性能优化 | 发表时间:2013-06-04 23:33 | 作者:钓雪
出处:http://www.searchtb.com

一、背景

搜索引擎的log数据可以用于query理解、user理解、doc理解和ranking。我们运行共现词分析,挖掘出引擎的query log里面共现的词,离线建静态cache,用于提升引擎的性能。

二、共现词分析

分析query log里query的平均的term数,值为5。我们对query log依次进行一至四元共现词分析,高于四元的我们推荐用fullcache解决,而且高元的离线计算成本也太高。

做法如下:

首先抽取query里分词后的term,因为term不一定是相邻的,所以根据指定的N元需要进行穷举N元共现词,使用python写map-reduce程序统计共现词。

然而这里统计出来的共现词会有问题,就是会重复。我们需要对共现词进行去重,这里分为同一元去重和不同元去重。

同一元去重:

例如,query为 “中国 人民 大学 研究生 ” ,三元共现词有“中国 人民 大学”,“人民 大学 研究生”等四个三元共现词。根据我们的应用场景,所有的三元共现词都建静态cache,然后使用静态cache时,遇到相同的query,只会贪婪匹配第一个三元共现词,即“中国 人民 大学”,其他三个都白建了,这在索引大小膨胀敏感的情况下是不可接受的,需要去重。

不同元去重:

还是上面的query,二元共现词有“中国 人民”,“人民 大学”,在已经建了三元共现词的情况下,建这两个二元共现词也同样是白费力气,不会被用到,所以需要去掉已经建过三元共现词的query串再去建二元共现词,这里也需要去重。

去重方案:

这里的方案是对每个query md5一个query id,这样在reduce统计共现词频时,统计query id的数目即可去重同一元的重复。不同元的去重,用上层的共现词对下层的共现词去做去重。步骤如下:

1. 先对N元共现词做N-1元共现词,所有的共现词频用真实词频的负数表示

2. 对新生成的N-1元共现词和之前未去重的N-1元共现词做map-reduce,统计去重后的词频

解决数据倾斜问题

在实现去重方案时,引入了query id, 而大量的高频共现词,导致这些共现词的query id链特别长,出现数据倾斜。

我们在第一次map时,对key做hash多份处理,key 为 “中国_人民”,根据hash的份数,hash为“中国_人民#0”,“中国_人民#1”,…

然后再做一轮map-reduce,即通过hash key和多轮map-reduce解决数据倾斜问题。

共现词部分结果

一至四元共现词及共现频度。

共现词分析实现小细节

现在的实现,把从query中抽取term做成接口对外开放,用户只需要实现process_log接口,从自己的log 中抽取出term,然后喂给共现词分析框架,即可完成多元共现词分析。

三、共现词分析用于静态cache

我们分析log的多元共现词,建静态cache,能有效提升引擎的性能,大量的query会落到静态cache上。在全内存情况下,能够节省CPU计算,即使在超内存情况下,IO落在SSD盘甚至普通盘上,也合并了IO,对引擎的性能提升有好处。

全内存性能提升效果:

超内存性能提升效果:

四、结尾

引擎的log数据包含各种信息,非常有价值,例如对于高latency的query进行分析,或者无少结果query的分析,对log数据进行各种挖掘,能为引擎的性能优化提供很多思路和方案,也能够提升搜索的效果和用户体验。

相关 [cache log 分析] 推荐:

静态cache之log共现词分析

- - 搜索技术博客-淘宝
搜索引擎的log数据可以用于query理解、user理解、doc理解和ranking. 我们运行共现词分析,挖掘出引擎的query log里面共现的词,离线建静态cache,用于提升引擎的性能. 分析query log里query的平均的term数,值为5. 我们对query log依次进行一至四元共现词分析,高于四元的我们推荐用fullcache解决,而且高元的离线计算成本也太高.

[转]用mysqldumpslow分析mysql的slow query log

- - 小彰
mysql有一个功能就是可以log下来运行的比较慢的sql语句,默认是没有这个log的,为了开启这个功能,要修改my.cnf或者在mysql启动的时候加入一些参数. 如果在my.cnf里面修改,需增加如下几行. long_query_time 是指执行超过多久的sql会被log下来,这里是1秒. log-slow-queries 设置把日志写在那里,可以为空,系统会给一个缺省的文件 host_name-slow.log,我生成的log就在mysql的data目录.

使用 LAL 收集并分析 Nginx access log

- - 掘金 后端
本篇文章演示如何将 Nginx access log 收集到 SkyWalking 中,并通过 LAL 进行指标分析. 本文由社区贡献者  魏翔 撰写, SkyWalking 社区帐号发表. Nginx access log 中包含了丰富的信息,例如:日志时间、状态码、响应时间、body 大小等.

Guava cache

- - 孟飞阳的博客
Guava Cache是一个全内存的本地缓存实现,它提供了线程安全的实现机制. 整体上来说Guava cache 是本地缓存的不二之选,简单易用,性能好.    Guava Cache有两种创建方式:.   通过这两种方法创建的cache,和通常用map来缓存的做法比,不同在于,这两种方法都实现了一种逻辑——从缓存中取key X的值,如果该值已经缓存过了,则返回缓存中的值,如果没有缓存过,可以通过某个方法来获取这个值.

Log调试

- - ITeye博客
在开发中我们一定不能避免使用Log类,但是这个类存在一个问题就是,当你在程序中使用了大量的Log,那么在程序开发完毕的时候,这将是一个问题,因为,你需要将所有的Log记录注释掉(当然,你不注释也是可以的). 我们可以写一个类,将Log类包装起来,使用一个boolean来控制所有的Log记录的显示. public static final boolean isDebug = true;//这里控制所有Log的显示情况.

Linux 内存高速缓存(cache)类型分析

- - Linux - 操作系统 - ITeye博客
      在Liunx内存管理机制中,除了对目录项(dentry,Linux文件系统中某个inode的链接)进行缓存外,. 还采取了两种高速缓存,即Buffer Cache和Page Cache,前者针对磁盘块的读写,后者针对文件inode的. 通过增加这些Cache,有效缩短 I/O时间.        先通过free命令查看内存使用情况:.

log file sync总结

- - 数据库 - ITeye博客
log file sync等待时间发生在redo log从log buffer写入到log file期间. 下面对log file sync做个详细的解释. 1.commit或者rollback. 3.log buffer 1/3满或者已经有1M的redo数据.       更精确的解释:_LOG_IO_SIZE 大小默认是LOG_BUFFER的1/3,当log buffer中redo数据达到_LOG_IO_SIZE 大小时,发生日志写入.

Java Cache系列之Guava Cache

- - BlogJava-首页技术区
然而作为工具库中的一部分,我们自然不能期待Guava对Cache有比较完善的实现. 因而Guava中的Cache只能用于一些把Cache作为一种辅助设计的项目或者在项目的前期为了实现简单而引入. 在Guava CacheBuilder的注释中给定Guava Cache以下的需求:. 对于这样的需求,如果要我们自己来实现,我们应该怎么设计.

巧用query cache

- - OurMySQL
   收到一用户反馈其应用日志中狂报错误,获取连接超时:. 同时应用报错超出了数据库的最大连接数:max connections:. 这种情况很有可能是有慢sql占用了连接池中的连接没有释放,导致后续进来的请求迟迟获取不到连接池中的连接,导致请求报错,登录数据库排查发现如下sql出现执行非常的慢:.

Oracle online redo log 扫盲

- - CSDN博客数据库推荐文章
Oracle 的日志分为:ONLINE REDO LOG 和 archived log. 一个数据库至少要有2组 redo log,每组 redo log 至少要有一个 member(出于安全考虑,建议每组 redo log 至少有 2 个多元化的 redo log member). redo log 循环使用,当一组日志写满后,就会切换到下一组日志.