仿google、百度的联想输入

前段时间公司有个需求，要求用户输入时能够像google、百度输入框那样提示相关信息。

思路很简单，通过ajax与后端交互获取结果集，问题是获得结果集如何足够快？我想问题的关键应该是在如何建索引，以及索引如何存储，才能检索速度够快。

和朋友讨论过基于汉字拼音等等方式，问题是自己写存储和检索的成本实在太高（其实是不会，现学现卖也不太现实）。

后来还是用lucene实现，自己写了个前缀分词器（姑且这么叫吧），例如：北京欢迎您，被分词为：北、北京、北京欢、北京欢迎、北京欢迎您几个词条，利用lucene进行索引和检索，单机访问速度也还可以接受，在高并发下还没测试。

 

但这种实现是典型的“头痛医头，脚痛医脚”的方式，在这里想问问大侠们有没有更好的方法呢？

用lucene实现的话？如果出现性能瓶颈，应该朝哪个方向优化？

 

 

 

維護一棵大平衡樹

平衡树存哪呢？存内存中太耗内存，存文件中，读写很麻烦（不会）
其实我想问两个问题：
1、前缀分词这个思路对不对
2、除了恶补基本功以外，还有没有别的解决方案？

去看一下分词系统，应该有你想要的东西。另，客户端也要优化一下，我之前也打算做一个的，只把JS部分写完了，比GG的完美，服务器端还没想好怎么做。

不论怎么样，你得预缓存，如果要求性能，肯定不能考虑频繁的实时查询数据库。

可以分词频级别，分级容器放关键词句，你肯定不会是匹配到一个关键词，就得马上要拉取整个文本到客户端的，可以拉取部分，这样可以缓存起来部分句子，降低内存占用。

还可以通过JS来控制，比如，用户点击输入框，onblur事件或者windown.onload之后预缓存部分高频率词句到客户端，差不多用户输入的时候用纯JS匹配，这个我跟我朋友已经实现了。JS匹配不到的，到服务器端查询，这样在高词频的部分可以明显降低压力，我试过了，纯JS的正则解析，至少可以承受4M的string,这仅仅是我未优化正则之前的速度。

从服务器生成关键词列表，比如，所有 “北京” 开头的关键词

<ul class="keywords">
   <li class="b j h y n">北京欢迎你
   <li class="b j j s s">北京金山上
</ul>

输入框输入“ bjh ”

JS 代码(jQuery)：

$("#keywords").show();
$("#keywords li").hide();
$("#keywords").children(".b.j.h").show();

LZ 可以自行决定，当用户输入 b 还是 bj ，从服务器刷新关键词列表。 这样，服务器就不需要对一个词建太多索引，基本一个词，索引投 1 个或者 3 个字就够用了

缺点是，如果用户输入" jbh " 和 "bjh" 滤出的关键词是一样的，但是这样的情况，实际发生的概率不大，基本可以接受，如果需要考虑顺序，可以改用 jQuery 的属性选择器 " [attribute^=value] "， 它的速度比 class 选择器要慢一点。

恩。很必要在客户端做缓存来大大缓解服务器的压力，我做的类似的东西也打算缓存，不过还没具体实现，你这成功的例子可以做为很好的证据了。
不过根据不同的应用，我们还可以加入高频词统计，等到用户用一段时间，就基本可以确定高频词汇了。
ps：我现在也只想到客户端优化，至于服务器端，前些日子看到淘宝UED的玉伯开发的kissysuggest，当有人问起如何优化服务器端，他也避而不答。。估计服务器端优化很“玄虚”的吧。呵呵

我想说这样的组件好像有很多，去google一下autoComplete会出来一箩筐。楼主可以考虑试试看。

在前端服务器上加载一个memcache，然后给你的缓存内容自定一个格式，让前端去帮你缓存到内存并输出，可以自定义mime，然后后端不停的统计，并写入到此缓存文件里。这可能是比较简单的办法了，再复杂点的就是自己写个轻量级http服务器端，专门负责处理。

定时更新高词频的统计是有必要的。可以根据高词频的词，对你已有的文字内容进行分析，然后缓存起来，避免实时查询。

搜一下分词器，LZ需要这个。