音乐搜索属于垂直搜索的一种，但它又有着自己独特的一些需求。
首先，几乎所有的音乐搜索都实现了用户输入时的关键词提示功能。但在网上搜索相关的技术文章，大多是讲如何用 Js 实现前台表现层的功能，少有的几篇关于后台技术实现的文章，也都太过简单。标准的办法是使用 Trie 树，但太过晦涩，不够直观。我们打算直接使用 Lucene 的前缀查询来实现，并且计划在项目上线后写一个比较详细的说明。
其次，很多的音乐搜索都提供了拼音查询的功能。比如说用户输入 “liudehua”，关键词提示里会给出 “刘德华”，但即使用户不理会提示，直接点击提交，在服务器端，还是可以查询到关于 “刘德华” 的条目。甚至，用户输入拼音首字母 “ldh”，都可以匹配到 “刘德华”。这主要是考虑到使用音乐搜索的用户群的特点（低龄？懒惰？互联网初级用户？），以及某些艺人的名字确实比较难拼写吧。技术上其实很简单，建索引的时候，将歌曲名，歌手名等都转成拼音一并进行索引就可以了。唯一一点需要注意的地方在于，多音字的处理。
再次，有些搜索引擎，像 qq music，提供了同音字纠错的功能，可以在用户输入“周洁论”的时候，命中关于“周杰伦”的结果。有了上一步的拼音索引，这一步也很容易实现了。再多做一步，考虑到南北方的口音差别，很多人 en 与 eng，zh 与 z，n 与 l 不分，在搜索过程中进行一些简单的替换，拼音模糊纠错功能也就水到渠成了。
最后，汉字的模糊搜索。我们常用的一个例子就是，用户输入“刘大华”，能否命中“刘德华”？技术上肯定是可以的，lucene 本身就提供这样的查询，只是在产品设计上，是否有代替用户思考的嫌疑呢？这就需要产品人员去仔细思量了。
前面说的是功能，后面说说排序。
最基础的排序当然是按文档匹配度，也就是 lucene 的 score 来排了。但是有时候编辑推荐的歌曲是一定要排前面的，这个比较好实现。可是点击率比较高的歌曲也要靠前排，这个就有点麻烦了，因为牵涉到频繁的字段更新，以及 boost 值的微调。
最麻烦的是上面说的那一堆的特殊处理。比如用户输入了一个词，精确匹配肯定应该排最前面了，没有精确匹配中文的，拼音全量匹配也可以，分词匹配，或者部分匹配的结果次之，再接下来应该是前缀搜索，同音字纠错，模糊搜索的匹配条目。最开始的想法一直是多次搜索，可是在多次搜索里，一是无法控制所谓的精确匹配；二是多次搜索打包的结果用于排序的时候，很麻烦；三则，多次搜索，本身的逻辑就非常复杂。不过今天学会一招，如果不考虑性能损耗，可以说是屠龙刀级别的必杀技：打包多个 Query 对象，一次搜索！排序的问题，当然使用 Query.setBoost 解决了。至于精确匹配，冗余一个字段，不分词就行。
搭建好了 Hudson，写了一个看起来蛮复杂的 build.xml ，然后每天看着它自动的编译，测试，发布，还是有点成就感的。
开始写测试用例。一边写也一边在思考，搜索引擎项目该如何进行功能正确性的测试，又如何进行搜索结果好坏的评价呢？