福林雨-博客

收藏：设计模式简图

tangfl — Thu, 26 Nov 2009 14:56:44 +0800

音乐搜索系统部署说明

tangfl — Tue, 24 Nov 2009 19:23:44 +0800

工作日志，转载请保留出处：唐福林博客雨音乐搜索系统部署说明 http://blog.fulin.org/2009/11/pcsearch_deploy.html

                       PC 客户端搜索系统部署说明

                        唐福林 <tangfulin AT gmail.com>

    PC 客户端搜索系统主要由 负责建索引的 IndexServer 和负责提供搜索服务的 SearchServer 两部分组成。
    IndexServer （目前是 98）负责接收资源库发过来的xml原始文件，解析原始文件，更新索引，并将更新后的索引推送到 SearchServer 上的指定目录供搜索使用。当前架构中，IndexServer 不支持分布式和负载均衡，只能部署在一台机器上。因为索引更新并不频繁，所以这里并不会带来性能瓶颈。如果是为了消除单点故障，可以在另外一台机器上起一个备份进程，当主 IndexServer 故障的时候接收资源库发过来的xml原始文件，但为了保持索引一致，建议不做实际的索引更新操作。这样 IndexServer 故障带来的唯一影响是索引更新延迟。只要做了必要的监控措施，延迟的时间是可以控制在可接受范围内的。IndexServer 主要消耗磁盘IO，也会有一些 cpu 和内存消耗。
    SearchServer （目前是 221）负责对外提供搜索服务。SearchServer 当前使用 Resin 提供的 Servlet 环境，以 HTTP 协议提供 Rest 风格的服务。SearchServer 会定期查看工作目录下是否有新的索引到达，如果有，则打开新索引，关闭旧索引。已关闭的旧索引随后会被脚本删除。SearchServer 主要消耗内存和网络IO。

一。部署之前的服务器检查：

1. 确认操作系统发行版本： cat /etc/redhat-release
    Red Hat Enterprise Linux Server release 5.3 (Tikanga) 或以上
2. 确认系统安装的 java 版本：java -version
    java version "1.5.0_15" 或以上
3. 确认系统安装的 rsync 版本： rsync --version
    rsync  version 3.0.5  protocol version 30 或以上
4. 确认磁盘空间：df -h
        确保有超过 2G 的剩余空间，建议预留 5G，方便打log。如果/home下磁盘空间不够，可以使用软链接
5. 确认svn客户端版本：svn --version
        确保含有 https 模块：
        ra_dav : Module for accessing a repository via WebDAV (DeltaV) protocol.
        - handles 'http' scheme
        - handles 'https' scheme
6. 确认 ant 版本：ant -version
    Apache Ant version 1.6.2 或以上
7. 确认 resin 版本：
    3.1.9 或以上

二。建立目录结构

        项目根目录设置为 /home/yyjd，以下的相对路径，如无特殊说明，都是相对于项目的根目录

    mkdir /home/yyjd && cd /home/yyjd && mkdir code data software && cd data && mkdir -p backup dict indexes indexserver logs pids webapps/search xml

三。取得文件数据

1. 取得必要的软件
        如果 “一” 中的检查不满足，或者希望安装 Hudson 或 JIRA，可以从 98 的 /home/yyjd/software 中取得软件，并进行安装。安装的时候，如果是 rpm 包，可以使用 rpm -ivh xxx.rpm 进行安装，如果是zip或tgz压缩包，解压缩即可，Hudson 是一个 war 包，可以直接运行，参考 code/PCSearcher/trunk/shell/server-start.sh 里的运行命令说明。
        注意，在安装 rpm 包的时候，可能会有一些依赖问题，按照提示先安装依赖包即可；安装 rpm 包如果报冲突，在命令行上加一个 --force 参数即可。

2. 取得代码
    cd /home/yyjd/code && svn checkout https://*.*.*.254/svn/PCSearch

四。相关软件设置

1. rsync 设置：在搜索机上 vi /etc/rsyncd.conf

    uid = root
    gid = root
    max connections = 200
    timeout = 600
    use chroot = no
    read only = no
    pid file=/var/run/rsyncd.pid
    hosts allow=*.*.*.98

    [search]
    path=/home/yyjd
    comment = PCsearch project sync model

    保存退出，然后运行 rsync --daemon 

    在 IndexServer 上测试 rsync 是否畅通：
    rsync -vn 搜索机ip::search/data/indexes .
    如果不通，则再测试一下使用 ssh 协议是否畅通：
    首先将 IndexServer 的 /root/.ssh/id_rsa.pub （如果没有该文件，运行一下 ssh-keygen 命令）的内容添加到搜索机 /root/.ssh/authorized_keys 文件的末尾（注意不要引入多余的换行符），然后测试：
    rsync -vn root@搜索机ip:/home/yyjd/data/indexes .

    测试正常之后，将测试成功的地址添加到  IndexServer 的 /home/yyjd/code/PCSearcher/trunk/shell/trans-dest.conf 文件末尾

2. resin 设置：
    将 data/webapps/search 目录添加到 resin app 目录列表，也可以在 resin 的 webapps 目录下建一个到    data/webapps/search 的软链接

五。编译代码

    cd /home/yyjd/code/PCSearcher/trunk && svn up && ant && ant indexserver

六。启动进程
        进入 /home/yyjd/code/PCSearcher/trunk/shell 目录
        参考 server-start.sh
1. IndexServer：
    a. 启动 resin （仅作测试，非必要）
    b. 启动  IndexServer：   ./indexUpdater.sh restart
    c. 启动 trans 索引传输脚本：
        (nohup ./trans-indexsnap.sh songs 2>&1 >> /home/yyjd/data/logs/trans-songs.log &)
        (nohup ./trans-indexsnap.sh albums 2>&1 >> /home/yyjd/data/logs/trans-albums.log &)
        (nohup ./trans-indexsnap.sh keywords 2>&1 >> /home/yyjd/data/logs/trans-keywords.log &)
    d. 启动 clean 索引清除脚本（如果启用了 resin，就必须启动这些清除脚本）：
        (nohup ./clean-indexsnap.sh songs 2>&1 >> /home/yyjd/data/logs/clean-songs.log &)
        (nohup ./clean-indexsnap.sh albums 2>&1 >> /home/yyjd/data/logs/clean-albums.log &)
        (nohup ./clean-indexsnap.sh keywords 2>&1 >> /home/yyjd/data/logs/clean-keywords.log &)
    e. 检查 /home/yyjd/data/logs 下的日志是否都正常

2. SearchServer：
    a. 启动 resin
    b. 启动  IndexServer：   ./indexUpdater.sh restart （可以作为 IndexServer 接收xml原始文件的功能的备份，非必要）
    c. 启动 clean 索引清除脚本：
        (nohup ./clean-indexsnap.sh songs 2>&1 >> /home/yyjd/data/logs/clean-songs.log &)
        (nohup ./clean-indexsnap.sh albums 2>&1 >> /home/yyjd/data/logs/clean-albums.log &)
        (nohup ./clean-indexsnap.sh keywords 2>&1 >> /home/yyjd/data/logs/clean-keywords.log &)
    d. 检查 /home/yyjd/data/logs 下的日志是否都正常   

七。日常管理

1. shell 脚本介绍：code/PCSearcher/trunk/shell
    build.sh            : Hudson 使用的编译，重启 IndexServer 进程的脚本，不建议使用
    clean-indexsnap.sh  : 无用索引清除脚本，SearchServer 使用
    indexUpdater.sh     : 索引更新 daemon 进程，接受 {start|stop|restart} 参数调用
    initKeyword.sh      : 关键词索引初始化脚本，平常不用
    processManager.sh   : 底层的进程启动，停止管理脚本，由其他脚本调用
    rebuild.sh          : 模拟发送重建歌曲，专辑索引的xml原始数据的脚本，重建索引时使用
    server-start.sh     : 记录了新部署机器时可能会用到的启动命令，不建议直接运行
    trans-dest.conf     : 传输脚本的目的地址配置文件
    trans-indexsnap.sh  : 索引传输脚本，IndexServer 使用

2. logs 日志介绍：data/logs
    classpath.log       : 索引更新 daemon 进程启动的时候的 classpath，debug 使用
    clean-*.log         : 索引清除日志
    trans-*.log         : 索引传输日志
    search.log          : 搜索日志
    indexserver.log     : 索引更新日志
    另外，resin 的日志也需要留意观察。

八。常见错误及修正方法    

1. svn 不支持 https
2. ant 编译出错
3. indexUpdater.sh 启动  索引更新 daemon 进程 出错
4. rsync 传输出错
5. 搜索出错，出白页面或 404
6. 搜索出错，报 Exception：确认一下 data/indexes/ 下面的每个子目录下面都有索引文件

转：500 Days of Summer

tangfl — Tue, 24 Nov 2009 19:15:46 +0800

男生以为有一种东西叫做fate。有一种情感可以被形容为love。有一种邂逅是meant to be。
　　所以当Tom看到Summer的时候，他真真切切的告诉自己，这个人就是自己一生的挚爱。
　　他傻傻的用留恋的目光追随她的影子。他惶恐不安的揣测她的每一个phrase。他不可自拔的沦陷了。
　　于是关于她的一切都是美好的。
　　黑色的头发。说话前抿一下嘴巴。胸口心形的胎记。笑起来咯咯的声音。沉沉的睡过去的样子。
　　甚至连周围一切的景观都被他主观的赋予了鲜艳的色彩。
　　世界不复存在，只有你。
　　
　　女生从来不相信关于爱情的童话。一切都只是虚幻的感情。没有什么是fate。没有什么可以被形容为true love。没有一种偶遇是meant to be。
　　relationship的意义只是have fun。仅此而已。
　　于是当他们在Ikea里面开心的玩闹的时候，她会认真的跟他说，well...I don't wanna get into something serious...is that ok?
　　Tom苦涩的笑了，但还是很快的说了sure。因为他还是抱有幻想，有一天Summer心里的那堵墙终于会因为自己而坍塌。只是因为自己。
　　所以当Summer把他带到属于自己的空间里的时候，他天真的以为自己终于把那堵墙无声无息的敲碎了。
　　所以当Summer跟他说I have never told anyone else before，他几乎百分之百的肯定，自己在对方心中也是以同样的地位存在。
　　
　　然而幻想终究只是幻想。
　　
　　Tom: I just wanna know....what are we?
　　Summer: I don't know....well I don't care. I'm happy, aren't you happy?
　　Tom: ...yea..I am happy.
　　
　　300天之后，不安终于变的强烈起来。
　　
　　不再因为水槽的笑话而大笑。不再因为喜欢同一个歌手而欣喜。不再放肆的比赛讲粗口。
　　于是关于她的一切都变的令人厌恶。
　　黑色的头发。说话前抿一下嘴巴。胸口心形的胎记。笑起来咯咯的声音。沉沉的睡过去的样子。
　　
　　终于还是分手了。原因不明。
　　这一段被认定是命中注定的恋情，终于痛苦的，不堪的，结束了。
　　然而故事并没有完。
　　
　　500天，他们再次重逢。
　　男生终于意识到，原来真的没有什么是fate。没有什么可以被形容为true love。没有一种偶遇是meant to be。
　　女生却突然醒悟，其实有一种东西叫做fate。有一种情感可以被形容为love。有一种邂逅是meant to be。
　　多么的讽刺。同样一段恋情，却让两个人走上了截然不同的道路。
　　Tom在黑板上涂满了理想中建筑的设计图。
　　Summer却戴上了别人递过来的钻戒。
　　
　　
　　其实又何必去追究是不是有fate,true love, or meant to be呢。
　　或者说其实有些人都是这样天真的执着。
　　当自己沉浸在热恋中的时候，就会坚定的相信自己的感情很真实很坚定很持久。
　　但是一旦破裂了，便会灰心丧气，一瞬间觉得一切关于爱情的描述都应该去死。

“全世界能让你快乐的只有她”；

全世界能让你悲伤的也只有她啊。
　　其实一切的一切只是在于你自己而已。
　　是不是真正爱的，只是我们自己而已？

　　所以归根到底，对于爱情的态度只是为了自我安慰，还是一种信仰

　　现在我爱你所以一定是真爱一定能坚持很久一定可以击退一切困难。
　　现在我不爱你了所以爱情其实只是谎言不可能有什么天长地久。
　　而当下一个人出现的时候，很有可能又会很没出息的回到之前的mindset。
　　
　　这样的cycle是不是很可笑呢。
　　
　　真的不用把自己的情感分析的那么清晰透彻的。又不要你交report。

你如果觉得你爱他的多一点你就是TOM ，如果不够爱他你就是SUMMER
　　有的时候真的不用去想what are we。谁知道会不会一觉醒来就突然想结婚了呢。
When Summer is gone, Autumn is here.

只是记忆和光影，还有信仰，也会变迁么？

一定要经历过求而不得的感情才懂得珍惜么，

一定要时光把紧握的指尖分开才懂得心疼么，

不要终于能读懂幸福的时候，代价是曾经失去

转自：白色植物〃黑色年轮 http://blog.sina.com.cn/s/blog_4ac407c30100ge5w.html

音乐搜索的极致(续)

tangfl — Thu, 29 Oct 2009 10:23:35 +0800

12530 PC客户端音乐搜索项目一期的总结和思考。

SlideShare 上的 pdf：

音乐搜索的极致

View more documents from fulin tang.

PPT 的文字内容：

音乐搜索的极致唐福林 tangfulin@gmail.com http://blog.fulin.org
目录  项目简介  需求描述  搜索实现  查询示例  持续改进
项目简介 (1/3)  中国移动  12530  咪咕  Miniportal  搜索  Out source : edadao
项目简介 (2/3)  时间： 2009 年 9 月 12 日到 10 月 22 日  地点：成都，郫县，犀浦，移动音乐基地  参与人员：  需求提供： wangquanli@12530, zhengchangsong@12530  开发人员： mike,tangfulin,xww,wanghui  特别贡献： dave
项目简介 (3/3)  部署情况：  位置：移动音乐基地，西区枢纽机房  机器：  建索引： 227.98  搜索： 227.221  Dual Core AMD Opteron(tm) Processor 8218 2.6G * 8  8G mem  Red Hat Enterprise Linux Server release 5.3 (Tikanga)  Linux 2.6.18128.el5PAE #1 SMP i686 athlon GNU/Linux  索引大小： 3 个索引目录共 1.2G  流量：  机器负载情况：
需求描述  搜索字段：歌手，歌曲，专辑，歌词  搜索方式：  精确匹配  前缀匹配  分词匹配  模糊匹配  拼音全量匹配  拼音首字母匹配  拼音同音匹配  拼音纠错匹配  关键词提示： • 搜索框下拉提示 • 纠错提示
需求－精确匹配  规则：精确匹配或过滤所有特殊字符后精确匹配  单个字段：  歌手：阿唬 , 80 前后  歌曲：爱情 BT 大讲堂  专辑： Alive!  多个字段联合：  歌手名＋歌曲名：刘德华今天  歌手名＋专辑名：许茹芸爱 . 旅行 . 一公里
需求－前缀匹配  规则：过滤所有特殊字符后前缀匹配  单个字段：  歌手：刘德，张学  歌曲：  专辑：
需求－分词匹配  规则：过滤所有特殊字符后分词匹配  单个字段：  歌手：德华，杰伦，学友  歌曲：  专辑：  歌词：  多个字段联合：先 Must ，再 Should  歌手名＋歌曲名＋专辑名：  歌手名＋专辑名：
需求－模糊匹配  规则：一定模糊度的词匹配（注：很慢）  单个字段：  歌手：刘大华  歌曲： beautful, califonia  专辑：
需求－拼音全量匹配  规则：用户输入拼音匹配  单个字段：  歌手： liudehua, zhangxueyou  歌曲：  专辑：
需求－拼音首字母匹配  规则：用户输入拼音首字母匹配  单个字段：  歌手： ldh, zxy  歌曲：  专辑：
需求－拼音同音匹配  规则：用户拼音输入法，输入错误的同音字匹配  单个字段：  歌手：柳的话，两用器  歌曲：  专辑：
需求－拼音纠错匹配  规则：用户拼音输入法输入错误的字，或直接输入错误的拼音  n l,hf,z zh,c ch,s sh,an ang,en eng,in ing  单个字段：  歌手：牛德华， niudehua  歌曲：  专辑：
搜索实现  建索引策略  冗余字段  中文将拼音，首字母也建进索引里  搜索 Query 策略  弃用多次查询的策略  采用多个 Query 拼装成一个 BooleanQuery ，设置不同的权值，一次查询的策略
搜索实现：建索引策略 (1/2)  歌手： singer_name  singer_name_save: 保存字段， trim 后，原封不动  singer_name_filtered: 过滤字段，过滤所有的特殊字符，转小写  singer_name_analyzed: 分词字段  singer_name_notanalyzed: 不分词字段，前缀匹配使用  singer_name_full: 拼音全量字段  singer_name_first: 拼音首字母字段  歌曲： song_name  专辑： album_name
搜索实现：建索引策略 (2/2)  关键词： keyword  所有的歌手名，歌曲名，专辑名，歌手＋歌曲，歌手＋专辑，都视为关键词  单独一个索引文件  供下拉提示和搜索无结果时的纠错提示使用  也提供拼音全量，拼音首字母，拼音纠错等功能
搜索实现：搜索策略 (1/6)  策略列表： 1. 精确匹配：歌手，歌曲，专辑，不分词字段，去掉前后多余空格，精确匹配 2. 过滤后的精确匹配：歌手，歌曲，专辑，过滤字段，去掉所有特殊字符，英文转成小写，精确匹配 3. 拼音全量匹配：歌手，歌曲，专辑，拼音全量字段，去掉所有非英文字符，英文转成小写，精确匹配 4. 同音纠错匹配：歌手，歌曲，专辑，拼音全量字段，只对含中文的搜索词使用，中文转拼音，英文转小写，去掉所有特殊字符，精确匹配 5. 拼音首字母匹配：歌手，拼音首字母字段，中文转拼音首字母，英文转小写，去掉所有特殊字符，精确匹配 6. 前缀匹配：歌手，歌曲，专辑，不分词字段，去掉前后多余空格，英文转小写，前缀匹配 7. 分词 Must 匹配：歌手，歌曲，专辑，（歌词），分词字段，分词，词之间使用 Must 连接，分词匹配
搜索实现：搜索策略 (2/6)  策略列表（续）： 1. 分词 Should 匹配：歌手，歌曲，专辑，（歌词），分词字段，分词，词之间使用 Should 连接，分词匹配 2. 合并分词 (must) 匹配：歌手＋歌曲＋专辑分词字段，分词，（当前使用 must 连接），分词匹配 3. 合并分词 (should) 匹配：歌手＋歌曲＋专辑分词字段，分词，（当前使用 Should 连接），分词匹配 4. 拼音纠错匹配查询（忽略掉鼻音等） : 歌手，歌曲，专辑，分词字段，去掉前后多余空格，英文转小写 . 5. 中文模糊匹配，中文时模糊度： 0.65: 歌手，歌曲，专辑，分词字段，去掉前后多余空格，英文转小写 . 6. 英文模糊匹配，英文模糊度： 0.85: 歌手，歌曲，专辑，分词字段，去掉前后多余空格，英文转小写 .
搜索实现：搜索策略 (3/6)  精度选择  只搜索精确匹配结果  精确匹配，过滤后精确匹配，前缀匹配  拼音全量，首字母  分词全部命中  只搜索模糊匹配结果  分词部分命中  同音纠错，拼音纠错  模糊匹配  去掉精确匹配的结果  搜索全部结果
搜索实现：搜索策略 (4/6)  字段选择  只搜索歌手  只搜索歌曲  只搜索专辑  只搜索歌词  搜索关键词字段  搜索全部字段（暂时不包括关键词和歌词）
搜索实现：搜索策略 (5/6)  设置权值  将所有的策略置入一个有序列表中  列表中相邻的两个策略之间权值相差常数倍（当前设置为 10 ）。过大可能会导致 lucene 评分溢出，过小可能会导致不同策略命中的结果集重叠  调整列表中策略的先后次序以调整结果集中各种命中的出现顺序  二级权值：在搜索全部的时候，歌手 > 歌曲 > 专辑，所以需要在同一个策略内部再设置字段权值  中文分词命中的权值设置： Lucene 默认打分策略中，并没有考虑命中的词的长度。为了优先显示长的词命中的结果，对分词 Query 中每个词根据长度设置不同的权值
搜索实现：搜索策略 (6/6)  索引文件划分  搜索歌曲索引  搜索专辑索引  搜索关键词索引  排序策略  编辑置顶  Lucene 评分  业务量（点击，订阅，播放等）  关键词词频
搜索示例  歌曲索引，全部字段，精确搜索  搜刘德华，结果条数： 329  QUERY:(((singer_name_notanslysis: 刘德华 ^9.0 song_name_notanslysis: 刘德华 ^4.0 album_name_notanslysis: 刘德华 ))^10000.0) (((singer_name_filtered: 刘德华 ^9.0 song_name_filtered: 刘德华 ^4.0 album_name_filtered: 刘德华 ))^1000.0) (((singer_name_filtered: 刘德华 *^9.0 song_name_filtered: 刘德华 *^4.0 album_name_filtered: 刘德华 *))^100.0) ((((((+singer_name_anslysis: 刘德华 +singer_name_anslysis: 德华 )^9.0) ((+song_name_anslysis: 刘德华 +song_name_anslysis: 德华 )^4.0) (+album_name_anslysis: 刘德华 +album_name_anslysis: 德华 ))))^10.0) ((((+singer_song_album: 刘德华 +singer_song_album: 德华 ))))
搜索示例  歌曲索引，全部字段，精确搜索  搜 ldh ，结果条数： 401 （命中刘德华，刘大浩等）  QUERY:(((singer_name_notanslysis:ldh^9.0 song_name_notanslysis:ldh^4.0 album_name_notanslysis:ldh))^1000.00006) (((singer_name_filtered:ldh^9.0 song_name_filtered:ldh^4.0 album_name_filtered:ldh))^100.00001) (((singer_name_full:ldh^9.0 song_name_full:ldh^4.0 album_name_full:ldh))^10.000001) (((singer_name_first:ldh))^1.0000001) (((singer_name_filtered:ldh*^9.0 song_name_filtered:ldh*^4.0 album_name_filtered:ldh*))^0.10000001) ((((((+singer_name_anslysis:ldh)^9.0) ((+song_name_anslysis:ldh)^4.0) (+album_name_anslysis:ldh))))^0.010000001) (((((+singer_song_album:ldh))))^0.0010)
搜索示例  歌曲索引，全部字段，精确搜索  搜 liudehua ，结果条数： 324 （歌名《我不是刘德华》无法命中）  QUERY:(((singer_name_notanslysis:liudehua^9.0 song_name_notanslysis:liudehua^4.0 album_name_notanslysis:liudehua))^1000.00006) (((singer_name_filtered:liudehua^9.0 song_name_filtered:liudehua^4.0 album_name_filtered:liudehua))^100.00001) (((singer_name_full:liudehua^9.0 song_name_full:liudehua^4.0 album_name_full:liudehua))^10.000001) (((singer_name_filtered:liudehua*^9.0 song_name_filtered:liudehua*^4.0 album_name_filtered:liudehua*))^1.0000001) ((((((+singer_name_anslysis:liudehua)^9.0) ((+song_name_anslysis:liudehua)^4.0) (+album_name_anslysis:liudehua))))^0.10000001) (((((+singer_song_album:liudehua))))^0.010000001) (((singer_name_first:liudehua))^0.0010)
搜索示例  歌曲索引，全部字段，模糊搜索  搜刘德华，结果条数： 44 （命中爱德华，杨德华等）  QUERY: ((((singer_name_notanslysis: 刘德华 ^9.0 song_name_notanslysis: 刘德华 ^4.0 album_name_notanslysis: 刘德华 ))^10000.0) (((singer_name_filtered: 刘德华 ^9.0 song_name_filtered: 刘德华 ^4.0 album_name_filtered: 刘德华 ))^1000.0) (((singer_name_filtered: 刘德华 *^9.0 song_name_filtered: 刘德华 *^4.0 album_name_filtered: 刘德华 *))^100.0) ((((((+singer_name_anslysis: 刘德华 +singer_name_anslysis: 德华 )^9.0) ((+song_name_anslysis: 刘德华 +song_name_anslysis: 德华 )^4.0) (+album_name_anslysis: 刘德华 +album_name_anslysis: 德华 ))))^10.0) ((((+singer_song_album: 刘德华 +singer_song_album: 德华 ))))) +(((((singer_song_album: 刘德华 ^9.0 singer_song_album: 德华 ^4.0)))^10000.0) (((((singer_name_anslysis: 刘德华 ^9.0 singer_name_anslysis: 德华 ^4.0)^9.0) ((song_name_anslysis: 刘德华 ^9.0 song_name_anslysis: 德华 ^4.0)^4.0) (album_name_anslysis: 刘德华 ^9.0 album_name_anslysis: 德华 ^4.0)))^1000.0) (((((singer_name_full:liudehua)^9.0) ((song_name_full:liudehua)^4.0) (album_name_full:liudehua)))^100.0) ((())^10.0) ((singer_name_anslysis: 刘德华 ~0.65^9.0 song_name_anslysis: 刘德华 ~0.65^4.0 album_name_anslysis: 刘德华 ~0.65)))
搜索示例  歌曲索引，全部字段，模糊搜索  搜牛德华，结果条数： 840 （命中刘德华，爱德华，杨德华等）  QUERY: ((((singer_name_notanslysis: 牛德华 ^9.0 song_name_notanslysis: 牛德华 ^4.0 album_name_notanslysis: 牛德华 ))^10000.0) (((singer_name_filtered: 牛德华 ^9.0 song_name_filtered: 牛德华 ^4.0 album_name_filtered: 牛德华 ))^1000.0) (((singer_name_filtered: 牛德华 *^9.0 song_name_filtered: 牛德华 *^4.0 album_name_filtered: 牛德华 *))^100.0) ((((((+singer_name_anslysis: 牛 +singer_name_anslysis: 德华 )^9.0) ((+song_name_anslysis: 牛 +song_name_anslysis: 德华 )^4.0) (+album_name_anslysis: 牛 +album_name_anslysis: 德华 ))))^10.0) ((((+singer_song_album: 牛 +singer_song_album: 德华 ))))) +(((((singer_song_album: 牛 singer_song_album: 德华 ^4.0)))^10000.0) (((((singer_name_anslysis: 牛 singer_name_anslysis: 德华 ^4.0)^9.0) ((song_name_anslysis: 牛 song_name_anslysis: 德华 ^4.0)^4.0) (album_name_anslysis: 牛 album_name_anslysis: 德华 ^4.0)))^1000.0) (((((singer_name_full:niudehua)^9.0) ((song_name_full:niudehua)^4.0) (album_name_full:niudehua)))^100.0) ((())^10.0) ((singer_name_anslysis: 牛德华 ~0.65^9.0 song_name_anslysis: 牛德华 ~0.65^4.0 album_name_anslysis: 牛德华 ~0.65)))
搜索示例  歌曲索引，全部字段，模糊搜索  搜 niudehua ，结果条数： 324  QUERY:((((singer_name_notanslysis:niudehua^9.0 song_name_notanslysis:niudehua^4.0 album_name_notanslysis:niudehua))^1000.00006) (((singer_name_filtered:niudehua^9.0 song_name_filtered:niudehua^4.0 album_name_filtered:niudehua))^100.00001) (((singer_name_full:niudehua^9.0 song_name_full:niudehua^4.0 album_name_full:niudehua))^10.000001) (((singer_name_filtered:niudehua*^9.0 song_name_filtered:niudehua*^4.0 album_name_filtered:niudehua*))^1.0000001) ((((((+singer_name_anslysis:niudehua)^9.0) ((+song_name_anslysis:niudehua)^4.0) (+album_name_anslysis:niudehua))))^0.10000001) (((((+singer_song_album:niudehua))))^0.010000001) (((singer_name_first:niudehua))^0.0010)) +(((((singer_song_album:niudehua^64.0)))^1000.0) (((((singer_name_anslysis:niudehua^64.0)^9.0) ((song_name_anslysis:niudehua^64.0)^4.0) (album_name_anslysis:niudehua^64.0)))^100.0) (((((singer_name_full:niudefua singer_name_full:liudehua)^9.0) ((song_name_full:niudefua song_name_full:liudehua)^4.0) (album_name_full:niudefua album_name_full:liudehua)))^10.0) ((singer_name_anslysis:niudehua~0.85^9.0 song_name_anslysis:niudehua~0.85^4.0 album_name_anslysis:niudehua~0.85)))
搜索示例  歌曲索引，歌手字段，精确搜索  搜杰伦，结果条数： 270  QUERY:(((singer_name_notanslysis: 杰伦 ))^1000.0) (((singer_name_filtered: 杰伦 ))^100.0) (((singer_name_filtered: 杰伦 *))^10.0) ((((+singer_name_anslysis: 杰伦 ))))
搜索示例  歌曲索引，歌曲字段，模糊搜索  搜 li ，结果条数： 117 （命中你）  QUERY: ((((song_name_notanslysis:li))^10000.0) (((song_name_filtered:li))^1000.0) (((song_name_full:li))^100.0) (((song_name_filtered:li*))^10.0) ((((+song_name_anslysis:li))))) +(((((song_name_anslysis:li^4.0)))^100.0) ((((song_name_full:ni)))^10.0) ((song_name_anslysis:li~0.85)))
搜索示例  关键词索引，搜索歌曲  搜 liu ，结果：  流浪流星留恋六月雪浏阳河流浪狗流浪者之歌留不住你的温柔  QUERY:+keyword_type:2 keyword_word_notanslysis:liu + (((keyword_word_filtered:liu*)^100.0) ((keyword_word_full:liu*)^100.0) ((keyword_word_first:liu*)^100.0))
搜索示例  关键词索引，搜索歌手  搜 liu ，结果：  刘德华刘冠群刘亦敏刘韵刘若英刘基俊刘益中刘芳刘庆  QUERY:+keyword_type:1 keyword_word_notanslysis:liu + (((keyword_word_filtered:liu*)^100.0) ((keyword_word_full:liu*)^100.0) ((keyword_word_first:liu*)^100.0))
搜索示例  关键词索引，搜索全部字段  搜 zhoujie ，结果：（有歌手＋歌曲的命中）  周杰伦周杰磊周杰伦我求求你了周杰伦传递祝福周杰伦春节祝福周杰伦情人节祝福  周杰伦蒲公英的约定  周杰伦最长的电影  周杰伦阳光宅男  周杰伦甜甜的  QUERY:+(keyword_type:1 keyword_type:2 keyword_type:3) keyword_word_notanslysis:zhoujie +(((keyword_word_filtered:zhoujie*)^100.0) ((keyword_word_full:zhoujie*)^100.0) ((keyword_word_first:zhoujie*)^100.0))
搜索示例  关键词索引，搜索全部字段  搜柳的话，结果：（拼音同音命中）  刘德华留得华  刘德华冰雨  刘德华中国人  刘德华幸福这么远那么甜  刘德华百分百好戏  刘德华笑着哭  刘德华谢谢你的爱  刘德华爱你一万年  刘德华情义俩心坚  QUERY:+(keyword_type:1 keyword_type:2 keyword_type:3) keyword_word_notanslysis: 柳的话 +(((keyword_word_filtered: 柳的话 *)^100.0) (((keyword_word_full:liudehua*)^100.0) ((keyword_word_full:liudihua*)^100.0)))
持续改进  性能调优： resin ，内存， cache  汉字转拼音：多音字，特殊符号  拼音纠错：另一种思路，标准化 vs 排列组合  关键词： Trie 树，按词频排序，加入歌词数据  业务要求以频繁更新的业务量作为排序依据  标签搜索：新需求  搜索关键词，保持先后顺序  自定义打分算法的尝试  Lucene 升级到 2.9.1 ， bug 1974 ， explain 显示 0 或者 NaN  显示时最佳片段截取， html 实体截断问题  标红，按策略的山寨标红与 Lucene 自带标红的优劣比较及取舍
性能调优 • 目标：单台机器，百万数量级的索引， 1000 个并发下， 99% 0.5 秒内返回 • 优势： • 索引更新不是很频繁，可以忽略不计 • 服务器性能不错， 8cpu ， 8G 内存 • 劣势： • 并发大，返回时间 0.5 秒要求太苛刻 • 一期代码有很多不合理的地方 • 项目时间紧张 • 使用了 resin 作为容器，有太多不可控因素
汉字转拼音 • Pinyin4j 的词库 • 自己整理的多音字表 • 当前将所有多音字的组合都建在索引里 • 莫文蔚： mowenwei, mowenyu • 优点：保证能查到 • 缺点：输入 mowenyu 能查到莫文蔚，而且一个歌名中如果有好几个多音字，排列组合的数量比较可观 • 拼音首字母，而不是拼音声母 • 张学友： zxy ，不是 zhxy
拼音纠错 • 规则： • n l,h f,z zh,c ch,s sh,an ang,en eng,in ing (on ong) • 当前实现： • 将用户输入的搜索词中的每个出现，依次替换成对应的纠错，联合成一个 Should Query • 如： liudehua: niudehua, liudefua • 另一种思路：标准化 • 规定规则中的替换只能单向： n >l,z >zh 等 • 在索引中增加一个标准化拼音字段，如曾经最美，该字段存储的值为 chengjingzhuimei • 用户输入关键词，也经过同样的标准化后，在该字段进行查询
关键词 • 关键词当前使用 Lucene 的索引前缀查询的方式实现 • 也包括拼音，首字母，纠错等 Query • 本来还有模糊查询的 Query ，但后来发现太影响查询速度了，于是就暂时去掉了 • 当前没有把歌词数据建到关键词索引中去。如果把歌词建进去，这个索引就太大了，必须要进行分拆 • 考虑使用 Trie 树： • 多棵树，拼音，首字母，中文需要各自建树 • 模糊查询的问题
排序 vs 更新 • 业务需求希望能以歌曲的业务量（播放，下载等量）作为排序的一个依据 • 意味着需要频繁的更新索引，而且为了更新这样一个数字字段，需要将整个文档删除重新添加，不划算 • 打算重载 Lucene 的 Collection 类，自己实现排序字段值的加载，不从索引里面读取 • 问题： 2.4 与 2.9 在这个地方的实现上有很大的不同，没法无缝切换
标签搜索 • 固定维度的标签，编辑填写，非用户产生内容 • 如：奥运，免费，铃声，开心，悲伤等 • 关键是产品设计，非技术实现 • 参考： google 泡泡挑歌
保持搜索关键词的顺序 • 延后实现的一个需求 • 只命中跟用户输入的多个关键词之间的顺序一致的结果 • 如： • 用户输入 “谢谢爱”命中“谢谢你的爱”，但输入 “爱谢谢”不命中 • 用户输入 “眼睛背叛心”命中“你的眼睛背叛了你的心”，但输入“心背叛眼睛”不命中 • 实现： • 分词命中，无法保留顺序信息 • 模糊查询，效率太差 • ？？？
打分算法  需求： • 产品人员对 Lucene 打分算法的不理解，要求单纯的以某一个依据来进行排序，如命中的词的个数 • 拼多个 Query 查询的副作用：多个 Query 的评分累加得到的最后得分，会导致各个 Query 的命中结果重叠（想法：把累加改成取最大值？） • 一个想法：同样的分词命中，命中较长的词的结果排前面  教训： • 没有金刚钻，别揽瓷器活！不要轻易的去改 Lucene 的评分算法
Lucene 版本的选择 • 首选 2.9.0 • Bug 1974 ： https://issues.apache.org/jira/browse/LUCENE 1974 • 换成了 2.4.1 • 为了性能及长远打算，还是希望换回 2.9.1 • Explain 函数调用返回评分 0 或 NaN
摘要截取 • Miniportal 空间有限，歌曲，专辑，甚至歌手名都可能需要截断 • 截断时需要考虑标红问题 • 截断时需要考虑 html 实体的问题
标红 • Lucene 标红的优点与不足 • 优点：正统，可升级 • 缺点：不能满足需求，前缀标红，拼音标红等 • 山寨标红 • 按照每种 Query 进行相应的标红，最后合并 •
更多讨论 http://blog.fulin.org

音乐搜索的极致

tangfl — Thu, 15 Oct 2009 19:45:19 +0800

12530 PC客户端咪咕 (页面最下方有一个很不显眼的下载链接) 搜索原本计划是今天上线内测，20号正是随资源库后台一起上线，其实昨晚就已经替换掉了正式服务器上原来的接口。正因为昨晚悄无声息的上线，原本已经下班走到家门口的我们，又被电话叫回公司，来解决一个刚刚发现的bug。

音乐搜索，第一期还没有特别做歌词的搜索，只对歌手名，歌曲名，专辑名做优化，加上数据量本身就很小（一共才不到100万首歌），只好在查询上做文章。我们当前一共设置了十层查询 Query：

1。精确匹配：歌手，歌曲，专辑，不分词字段，去掉前后多余空格，精确匹配
2。过滤后的精确匹配：歌手，歌曲，专辑，过滤字段，去掉所有特殊字符，英文转成小写，精确匹配
3。拼音全量匹配：歌手，歌曲，专辑，拼音全量字段，去掉所有非英文字符，英文转成小写，精确匹配
4。同音纠错匹配：歌手，歌曲，专辑，拼音全量字段，只对含中文的搜索词使用，中文转拼音，英文转小写，去掉所有特殊字符，精确匹配
5。拼音首字母匹配：歌手，拼音首字母字段，中文转拼音首字母，英文转小写，去掉所有特殊字符，精确匹配
6。前缀匹配：歌手，歌曲，专辑，不分词字段，去掉前后多余空格，英文转小写，前缀匹配
7。分词Must匹配：歌手，歌曲，专辑，（歌词），分词字段，分词，词之间使用Must连接，分词匹配
8。分词Should匹配：歌手，歌曲，专辑，（歌词），分词字段，分词，词之间使用Should连接，分词匹配
9。合并分词匹配：歌手＋歌曲＋专辑分词字段，分词，（当前使用 Should 连接），分词匹配
10。模糊匹配：歌手，歌曲，专辑，分词字段，去掉前后多余空格，英文转小写，模糊匹配，包含中文时模糊度：0.65 全英文模糊度：0.85

其中模糊匹配还分了两级：

a 拼音纠错
b 模糊查询，包括中文模糊和英文模糊（模糊度不一样）

当前拼音模糊是使用组合的办法来实现的：

1。建索引的时候，拼音全量字段里建的是字段的准确拼音，包括多音字的组合
2。搜索的时候，将用户输入的关键词转成拼音，在拼音全量字段里搜
3。模糊的时候，将用户输入关键词转成的拼音，按照模糊规则：n-l 互换，zh-z, ch-c, sh-s 互换，an-ang, en-eng, in-ing, on-ong 互换，每次只换一个（当前只支持模糊度为1的拼音模糊查询），如果有多个可以替换的点，则返回的结果为一个数组组合，然后使用精确匹配在拼音全量字段进行查询

还有一种做法：

首先定义个所谓的拼音标准化过程：
n->l，zh->z, ch->c, sh->s ，an->ang, en->eng, in->ing, on->ong 不是互换，而是单向替换。
将一个拼音串的所有可替换点都替换后，得到的一个串，称为标准化串。
1。建索引的时候，歌曲名，歌手名，专辑名各新增一个标准化串字段，按","分词（多音字），存储字段的拼音标准化串
2。搜索的时候，将用户输入的关键词转成拼音，在拼音全量里面搜索
3。模糊的时候，将用户输入关键词的拼音再转成标准化串，在标准化串字段里面搜索

优点：不同那么复杂的组合逻辑
缺点：无法控制模糊度

拼一个很大的 Query 去 Lucene 里面查询最大的问题就是，排序很难控制。不停的查看 Lucene Explain 出来的打分细节，再微调 Query 之间的 boost 权值，再查看打分细节，再微调。特别是分词命中这个 Query ，Lucene 分词命中的默认打分规则，总觉得不太满意。自己做了一个 Similarity 的子类来算分，可毕竟不是专业的，考虑的不够全面，解决了一个问题，副作用带来更多的问题。最后，还是不得不放弃这个方向的尝试。

拼一个大 Query 的一个意外收获就是，发现 Lucene 2.9.0 的一个 bug：LUCENE-1974，提到官方 JIRA 后，很快被确认，并修复了，并且我提交的 TestCase 也被将接纳到 Lucene 的测试用例集合中。可惜 2.9.1 出来前，我们还是不得不将项目切换回 2.4.1 ，以避免这个 bug。

现在使用的 IK 分词器，总觉得行为有些奇怪，又没有什么地方可以设置的。天龙八部，最多分词分出来“天”，“八”是我们不想要的，最长分词，又分不出“天龙”，真是郁闷。

因为 Query 太复杂，Lucene 自带的标红效果不是很令人满意，所以标红的部分也是完全自己做的。仿照 Query 的模式，定义了一系列的规则，如全量命中，拼音命中，分词命中等，记录下每种规则匹配到的区段，最后做一次归并就可以了。

关键词提示，即用户在搜索框里输入的同时，下拉一个提示列表。现在的做法是建了一个单独的关键词索引，用户输入的时候，使用前缀去匹配。中文的 Trie 树比英文复杂不少，所以最开始没有选它。但现在发现关键词索引太大了，Lucene 更新太慢，才后悔最初的选型失误。关键词里面需要保存词频的信息，搜索量的信息，所以以后的更新肯定也会不少。明天继续想办法解决这个问题。

做完这个项目以后，大约所有的搜索功能，都不会让我觉得害怕了吧。

原创，转载请著名出处：唐福林博客雨 http://blog.fulin.org/2009/10/acme_of_music_search.html

密码保护：相别

tangfl — Mon, 12 Oct 2009 22:10:59 +0800

这是一篇受密码保护的文章。您需要提供访问密码：

密码保护：相见

tangfl — Fri, 09 Oct 2009 10:08:56 +0800

这是一篇受密码保护的文章。您需要提供访问密码：

关于音乐搜索

tangfl — Tue, 22 Sep 2009 19:43:35 +0800

音乐搜索属于垂直搜索的一种，但它又有着自己独特的一些需求。

首先，几乎所有的音乐搜索都实现了用户输入时的关键词提示功能。但在网上搜索相关的技术文章，大多是讲如何用 Js 实现前台表现层的功能，少有的几篇关于后台技术实现的文章，也都太过简单。标准的办法是使用 Trie 树，但太过晦涩，不够直观。我们打算直接使用 Lucene 的前缀查询来实现，并且计划在项目上线后写一个比较详细的说明。

其次，很多的音乐搜索都提供了拼音查询的功能。比如说用户输入 “liudehua”，关键词提示里会给出 “刘德华”，但即使用户不理会提示，直接点击提交，在服务器端，还是可以查询到关于 “刘德华” 的条目。甚至，用户输入拼音首字母 “ldh”，都可以匹配到 “刘德华”。这主要是考虑到使用音乐搜索的用户群的特点（低龄？懒惰？互联网初级用户？），以及某些艺人的名字确实比较难拼写吧。技术上其实很简单，建索引的时候，将歌曲名，歌手名等都转成拼音一并进行索引就可以了。唯一一点需要注意的地方在于，多音字的处理。

再次，有些搜索引擎，像 qq music，提供了同音字纠错的功能，可以在用户输入“周洁论”的时候，命中关于“周杰伦”的结果。有了上一步的拼音索引，这一步也很容易实现了。再多做一步，考虑到南北方的口音差别，很多人 en 与 eng，zh 与 z，n 与 l 不分，在搜索过程中进行一些简单的替换，拼音模糊纠错功能也就水到渠成了。

最后，汉字的模糊搜索。我们常用的一个例子就是，用户输入“刘大华”，能否命中“刘德华”？技术上肯定是可以的，lucene 本身就提供这样的查询，只是在产品设计上，是否有代替用户思考的嫌疑呢？这就需要产品人员去仔细思量了。

前面说的是功能，后面说说排序。

最基础的排序当然是按文档匹配度，也就是 lucene 的 score 来排了。但是有时候编辑推荐的歌曲是一定要排前面的，这个比较好实现。可是点击率比较高的歌曲也要靠前排，这个就有点麻烦了，因为牵涉到频繁的字段更新，以及 boost 值的微调。

最麻烦的是上面说的那一堆的特殊处理。比如用户输入了一个词，精确匹配肯定应该排最前面了，没有精确匹配中文的，拼音全量匹配也可以，分词匹配，或者部分匹配的结果次之，再接下来应该是前缀搜索，同音字纠错，模糊搜索的匹配条目。最开始的想法一直是多次搜索，可是在多次搜索里，一是无法控制所谓的精确匹配；二是多次搜索打包的结果用于排序的时候，很麻烦；三则，多次搜索，本身的逻辑就非常复杂。不过今天学会一招，如果不考虑性能损耗，可以说是屠龙刀级别的必杀技：打包多个 Query 对象，一次搜索！排序的问题，当然使用 Query.setBoost 解决了。至于精确匹配，冗余一个字段，不分词就行。

搭建好了 Hudson，写了一个看起来蛮复杂的 build.xml ，然后每天看着它自动的编译，测试，发布，还是有点成就感的。

开始写测试用例。一边写也一边在思考，搜索引擎项目该如何进行功能正确性的测试，又如何进行搜索结果好坏的评价呢？

密码保护：成都的雨

tangfl — Mon, 21 Sep 2009 15:39:00 +0800

这是一篇受密码保护的文章。您需要提供访问密码：

我的Twitter

tangfl — Tue, 16 Jun 2009 18:33:11 +0800

更多我的Twitter内容，请访问 http://blog.fulin.org/twitter_tangfl
[twitter=tangfl&5]