福林雨 博客

工作日志，转载请保留出处：唐福林 博客雨 音乐搜索系统部署说明 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 &amp 
        (nohup ./trans-indexsnap.sh albums 2>&1 >> /home/yyjd/data/logs/trans-albums.log &amp 
        (nohup ./trans-indexsnap.sh keywords 2>&1 >> /home/yyjd/data/logs/trans-keywords.log &amp 
    d. 启动 clean 索引清除脚本（如果启用了 resin，就必须启动这些清除脚本）：
        (nohup ./clean-indexsnap.sh songs 2>&1 >> /home/yyjd/data/logs/clean-songs.log &amp 
        (nohup ./clean-indexsnap.sh albums 2>&1 >> /home/yyjd/data/logs/clean-albums.log &amp 
        (nohup ./clean-indexsnap.sh keywords 2>&1 >> /home/yyjd/data/logs/clean-keywords.log &amp 
    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 &amp 
        (nohup ./clean-indexsnap.sh albums 2>&1 >> /home/yyjd/data/logs/clean-albums.log &amp 
        (nohup ./clean-indexsnap.sh keywords 2>&1 >> /home/yyjd/data/logs/clean-keywords.log &amp 
    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/ 下面的每个子目录下面都有索引文件

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

SlideShare 上的 pdf：

PPT 的文字内容：

1. 音乐搜索的极致 唐福林 tangfulin@gmail.com http://blog.fulin.org
2. 目录  项目简介  需求描述  搜索实现  查询示例  持续改进
3. 项目简介 (1/3)  中国移动  12530  咪咕  Miniportal  搜索  Out source : edadao
4. 项目简介 (2/3)  时间： 2009 年 9 月 12 日到 10 月 22 日  地点：成都，郫县，犀浦，移动音乐基 地  参与人员：  需求提供： wangquanli@12530,   zhengchangsong@12530  开发人员： mike,tangfulin,xww,wanghui  特别贡献： dave
5. 项目简介 (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.18­128.el5PAE #1 SMP  i686 athlon  GNU/Linux  索引大小： 3 个索引目录共 1.2G  流量：  机器负载情况：
6. 需求描述  搜索字段：歌手，歌曲，专辑，歌词  搜索方式：  精确匹配  前缀匹配  分词匹配  模糊匹配  拼音全量匹配  拼音首字母匹配  拼音同音匹配  拼音纠错匹配  关键词提示： • 搜索框下拉提示 • 纠错提示
7. 需求－精确匹配  规则：精确匹配或过滤所有特殊字符后精 确匹配  单个字段：  歌手：阿唬 , 80 前后  歌曲：爱情 BT 大讲堂  专辑： Alive!  多个字段联合：  歌手名＋歌曲名：刘德华 今天  歌手名＋专辑名：许茹芸 爱 . 旅行 . 一公里
8. 需求－前缀匹配  规则：过滤所有特殊字符后前缀匹配  单个字段：  歌手：刘德，张学  歌曲：  专辑：
9. 需求－分词匹配  规则：过滤所有特殊字符后分词匹配  单个字段：  歌手：德华，杰伦，学友  歌曲：  专辑：  歌词：  多个字段联合：先 Must ，再 Should  歌手名＋歌曲名＋专辑名：  歌手名＋专辑名：
10. 需求－模糊匹配  规则：一定模糊度的词匹配（注：很 慢）  单个字段：  歌手：刘大华  歌曲： beautful, califonia  专辑：
11. 需求－拼音全量匹配  规则：用户输入拼音匹配  单个字段：  歌手： liudehua, zhangxueyou  歌曲：  专辑：
12. 需求－拼音首字母匹配  规则：用户输入拼音首字母匹配  单个字段：  歌手： ldh, zxy  歌曲：  专辑：
13. 需求－拼音同音匹配  规则：用户拼音输入法，输入错误的同 音字匹配  单个字段：  歌手：柳的话，两用器  歌曲：  专辑：
14. 需求－拼音纠错匹配  规则：用户拼音输入法输入错误的字， 或直接输入错误的拼音  n l,h­f,z zh,c ch,s sh,an ang,en eng,in ing  单个字段：  歌手：牛德华， niudehua  歌曲：  专辑：
15. 搜索实现  建索引策略  冗余字段  中文将拼音，首字母也建进索引里  搜索 Query 策略  弃用多次查询的策略  采用多个 Query 拼装成一个 BooleanQuery ，设置不同的权值， 一次查询的策略
16. 搜索实现：建索引策略 (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
17. 搜索实现：建索引策略 (2/2)  关键词： keyword  所有的歌手名，歌曲名，专辑名， 歌手＋歌曲，歌手＋专辑，都视为 关键词  单独一个索引文件  供下拉提示和搜索无结果时的纠错 提示使用  也提供拼音全量，拼音首字母，拼 音纠错等功能
18. 搜索实现：搜索策略 (1/6)  策略列表： 1. 精确匹配：歌手，歌曲，专辑，不分词字段，去掉前后多余空格，精确匹配 2. 过滤后的精确匹配：歌手，歌曲，专辑，过滤字段，去掉所有特殊字符，英文转成小 写，精确匹配 3. 拼音全量匹配：歌手，歌曲，专辑，拼音全量字段，去掉所有非英文字符，英文转成小 写，精确匹配 4. 同音纠错匹配：歌手，歌曲，专辑，拼音全量字段，只对含中文的搜索词使用，中文转 拼音，英文转小写，去掉所有特殊字符，精确匹配 5. 拼音首字母匹配：歌手，拼音首字母字段，中文转拼音首字母，英文转小写，去掉所有 特殊字符，精确匹配 6. 前缀匹配：歌手，歌曲，专辑，不分词字段，去掉前后多余空格，英文转小写，前缀匹 配 7. 分词 Must 匹配：歌手，歌曲，专辑，（歌词），分词字段，分词，词之间使用 Must 连 接，分词匹配
19. 搜索实现：搜索策略 (2/6)  策略列表（续）： 1. 分词 Should 匹配：歌手，歌曲，专辑，（歌词），分词字段，分词，词之间使用 Should 连接，分词匹配 2. 合并分词 (must) 匹配：歌手＋歌曲＋专辑 分词字段，分词，（当前使用 must  连 接），分词匹配 3. 合并分词 (should) 匹配：歌手＋歌曲＋专辑 分词字段，分词，（当前使用 Should  连 接），分词匹配 4. 拼音纠错匹配查询（忽略掉鼻音等） : 歌手，歌曲，专辑，分词字段，去掉前后多余空 格，英文转小写 . 5. 中文模糊匹配 ，中文时模糊度： 0.65: 歌手，歌曲，专辑，分词字段，去掉前后多余空 格，英文转小写 . 6. 英文模糊匹配，英文模糊度： 0.85: 歌手，歌曲，专辑，分词字段，去掉前后多余空 格，英文转小写 .
20. 搜索实现：搜索策略 (3/6)  精度选择  只搜索精确匹配结果  精确匹配，过滤后精确匹配，前缀匹配  拼音全量，首字母  分词全部命中  只搜索模糊匹配结果  分词部分命中  同音纠错，拼音纠错  模糊匹配  去掉精确匹配的结果  搜索全部结果
21. 搜索实现：搜索策略 (4/6)  字段选择  只搜索歌手  只搜索歌曲  只搜索专辑  只搜索歌词  搜索关键词字段  搜索全部字段（暂时不包括关键词 和歌词）
22. 搜索实现：搜索策略 (5/6)  设置权值  将所有的策略置入一个有序列表中  列表中相邻的两个策略之间权值相差常数倍（当前 设置为 10 ）。过大可能会导致 lucene 评分溢出，过 小可能会导致不同策略命中的结果集重叠  调整列表中策略的先后次序以调整结果集中各种命 中的出现顺序  二级权值：在搜索全部的时候，歌手 > 歌曲 > 专 辑，所以需要在同一个策略内部再设置字段权值  中文分词命中的权值设置： Lucene  默认打分策略 中，并没有考虑命中的词的长度。为了优先显示长 的词命中的结果，对分词 Query 中每个词根据长度 设置不同的权值
23. 搜索实现：搜索策略 (6/6)  索引文件划分  搜索歌曲索引  搜索专辑索引  搜索关键词索引  排序策略  编辑置顶  Lucene  评分  业务量（点击，订阅，播放等）  关键词词频
24. 搜索示例  歌曲索引，全部字段，精确搜索  搜 刘德华，结果条数： 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: 德华 ))))
25. 搜索示例  歌曲索引，全部字段，精确搜索  搜 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)
26. 搜索示例  歌曲索引，全部字段，精确搜索  搜 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)
27. 搜索示例  歌曲索引，全部字段，模糊搜索  搜 刘德华，结果条数： 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)))
28. 搜索示例  歌曲索引，全部字段，模糊搜索  搜 牛德华，结果条数： 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)))
29. 搜索示例  歌曲索引，全部字段，模糊搜索  搜 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)))
30. 搜索示例  歌曲索引，歌手字段，精确搜索  搜 杰伦，结果条数： 270  QUERY ((singer_name_notanslysis: 杰伦 ))^1000.0) (((singer_name_filtered: 杰伦 ))^100.0)  (((singer_name_filtered: 杰伦 *))^10.0) ((((+singer_name_anslysis: 杰伦 ))))
31. 搜索示例  歌曲索引，歌曲字段，模糊搜索  搜 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)))
32. 搜索示例  关键词索引，搜索歌曲  搜 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))
33. 搜索示例  关键词索引，搜索歌手  搜 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))
34. 搜索示例  关键词索引，搜索全部字段  搜 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))
35. 搜索示例  关键词索引，搜索全部字段  搜 柳的话，结果：（拼音同音命中）  刘德华 留得华  刘德华 冰雨  刘德华 中国人  刘德华 幸福这么远那么甜  刘德华 百分百好戏  刘德华 笑着哭  刘德华 谢谢你的爱  刘德华 爱你一万年  刘德华 情义俩心坚  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)))
36. 持续改进  性能调优： resin ，内存， cache  汉字转拼音：多音字，特殊符号  拼音纠错：另一种思路，标准化 vs 排列组合  关键词： Trie 树，按词频排序，加入歌词数据  业务要求以频繁更新的业务量作为排序依据  标签搜索：新需求  搜索关键词，保持先后顺序  自定义打分算法的尝试  Lucene  升级到 2.9.1 ， bug 1974 ， explain  显示 0 或者 NaN  显示时最佳片段截取， html 实体截断问题  标红，按策略的山寨标红与 Lucene 自带标红的优劣比较及取舍
37. 性能调优 • 目标：单台机器，百万数量级的索引， 1000 个并发 下， 99% 0.5 秒内返回 • 优势： • 索引更新不是很频繁，可以忽略不计 • 服务器性能不错， 8cpu ， 8G 内存 • 劣势： • 并发大，返回时间 0.5 秒要求太苛刻 • 一期代码有很多不合理的地方 • 项目时间紧张 • 使用了 resin 作为容器，有太多不可控因素
38. 汉字转拼音 • Pinyin4j  的词库 • 自己整理的多音字表 • 当前将所有多音字的组合都建在索引里 • 莫文蔚： mowenwei, mowenyu  • 优点：保证能查到 • 缺点：输入 mowenyu  能查到莫文蔚，而且一个歌 名中如果有好几个多音字，排列组合的数量比较 可观 • 拼音首字母，而不是拼音声母 • 张学友： zxy ，不是 zhxy
39. 拼音纠错 • 规则： • 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 • 用户输入关键词，也经过同样的标准化后，在该字段进行 查询
40. 关键词 • 关键词当前使用 Lucene  的索引前缀查询的方式实现 • 也包括拼音，首字母，纠错等 Query • 本来还有模糊查询的 Query ，但后来发现太影响查询 速度了，于是就暂时去掉了 • 当前没有把歌词数据建到关键词索引中去。如果把歌 词建进去，这个索引就太大了，必须要进行分拆 • 考虑使用 Trie 树： • 多棵树，拼音，首字母，中文需要各自建树 • 模糊查询的问题
41. 排序 vs 更新 • 业务需求希望能以歌曲的业务量（播放，下载等量） 作为排序的一个依据 • 意味着需要频繁的更新索引，而且为了更新这样一个 数字字段，需要将整个文档删除重新添加，不划算 • 打算重载 Lucene  的 Collection  类，自己实现排序字 段值的加载，不从索引里面读取 • 问题： 2.4  与 2.9  在这个地方的实现上有很大的不 同，没法无缝切换
42. 标签搜索 • 固定维度的标签，编辑填写，非用户产生内容 • 如：奥运，免费，铃声，开心，悲伤等 • 关键是产品设计，非技术实现 • 参考： google  泡泡挑歌
43. 保持搜索关键词的顺序 • 延后实现的一个需求 • 只命中跟用户输入的多个关键词之间的顺序一致的结果 • 如： • 用户输入 “谢谢 爱”命中“谢谢你的爱”，但输入 “爱 谢谢”不命中 • 用户输入 “眼睛 背叛 心”命中“你的眼睛背叛了 你的心”，但输入“心 背叛 眼睛”不命中 • 实现： • 分词命中，无法保留顺序信息 • 模糊查询，效率太差 • ？？？
44. 打分算法  需求： • 产品人员对 Lucene 打分算法的不理解，要求单纯的以某一个 依据来进行排序，如命中的词的个数 • 拼多个 Query 查询的副作用：多个 Query 的评分累加得到的 最后得分，会导致各个 Query 的命中结果重叠（想法：把 累加改成取最大值？） • 一个想法：同样的分词命中，命中较长的词的结果排前面  教训： • 没有金刚钻，别揽瓷器活！不要轻易的去改 Lucene 的评分算法
45. Lucene 版本的选择 • 首选 2.9.0 • Bug 1974 ： https://issues.apache.org/jira/browse/LUCENE 1974 • 换成了 2.4.1  • 为了性能及长远打算，还是希望换回 2.9.1 • Explain  函数调用返回评分 0  或 NaN
46. 摘要截取 • Miniportal  空间有限，歌曲，专辑，甚至歌手名都可 能需要截断 • 截断时需要考虑标红问题 • 截断时需要考虑 html  实体的问题
47. 标红 • Lucene  标红的优点与不足 • 优点：正统，可升级 • 缺点：不能满足需求，前缀标红，拼音标红等 • 山寨标红 • 按照每种 Query 进行相应的标红，最后合并 •
48. 更多讨论 http://blog.fulin.org

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

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

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

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

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

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

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

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

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

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

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