[github开源]基于redis的自动补全，有demo有真相

[okidogi]

github开源地址，MIT LICENSE，你想用来干什么都可以：

https://github.com/fengli/autocomplete-redis

demo地址：

http://ohbooklist.com/redis/

这个demo收录了37万条书籍名字，会根据你的输入自动补全。可以试一试。
服务器用的linode东京的服务器，你们看看速度怎么样。

更新：因为服务器的原因，demo地址已经不可用。

重新更新了一个demo，就不重新开帖了，效果见：



新的demo地址： http://readpi.com

[tshwangq]

很快

[okidogi]

@tshwangq 可能还真分地方，你的线路是？

[CoX]

@okidogi 输入一个 “围” 字，显示六遍“围城”？

[tshwangq]

北京联通
301 要120ms
搜索要300ms

干吗还要搞个301 ...

[zl8723]

nice job

[virgil]

不错,下拉选中不了啊...

[feilaoda]

500!

[chairo]

没任何补全……

[flylee2011]

500.。。

[alai]

不错，试试。

[okidogi]

@feilaoda @chairo @ffellaoda 哎，人太多了redis被kill掉了因为内存不够。。。好吧，我只买2g内存的服务器是不对的。

我刚重新启动了下redis-server，目前正常，你们慢慢的试啊，挤坏服务器不是我的错。。。

[wezzard]

長沙電信 很快 要是支持繁簡轉換就好了 都怪當年某人搞出來個簡化字

[udonmai]

读书单和豆瓣原生的豆列有什么区别?

[harmy]

赞开源的精神！

[okidogi]

@CoX 这是围城的多个不同版本，因为没有显示出版社和出版日期，所以看起来没有区别。
@udonmai 简单容易操作，不用你输入豆瓣上这本书的链接，我们可以自动补全之。

[udonmai]

@okidogi 豆列也不用输链接不是么。。。而且我记不住每一本书书名的开头或任意其他部分。。。我要收藏我肯定还得了解这本书，肯定会去诸如豆瓣这样的站点看介绍和评论。。所以这么一来楼主这个需求到底是什么？以超强的记忆力从自己的大脑中生成一份很棒的书单？自动补全不可能百分百准确和完整。

可能我说多了，楼主不要生气～仅仅作为个人的项目然后开源是大好事～但是作为一款产品的时候，也许需要考虑的更多。

[bruce]

你该选个更加优化的结构。

[okidogi]

@bruce "不要过早优化"。 我觉得现在的响应速度还可以，知乎的自动补全我觉得速度也不会比这个快。当然跟quora没法比，他们的自动补全是用c++优化过的，prefix-matching。而且在这种情况下，瓶颈不在服务器端的速度，而是在网络传输的速度。

@udonmai 我们的远景比简单的书单要大的多，现在只是最初期alpha的对一两个功能进行测试，至于站点是用来做什么的还没有浮出来呢，敬请期待 ;-)

[bruce]

@okidogi "不要过早优化" 是针对复杂系统而言，这么个简单不能再简单的需求，不用提优化的问题，只有好的方案和不好的方案。

[leecade]

需要前端配合吗

掏一个之前的项目:
http://leecade.github.com/suggest/

https://github.com/leecade/suggest

[9hills]

建议添加拼音匹配

[okidogi]

@9hills 恩。拼音匹配确实很有用，让我去github上开个issue。

[Livid]

目前的每一次搜索需要的耗时是多少毫秒呢？

[okidogi]

@Livid 50ms左右。不过索引的数据不多，只有6000+个书名。

[Livid]

@okidogi 将来我们新的发帖页面在选择节点时，或许可以上一个类似的东西。

谢谢。

[okidogi]

@Livid 也可以考虑索引所有帖子标题试试，替换掉现在的google custom search，用户体验应该很不错。不过可能内存消耗比较大，之前索引了37万本书的名字，1G多的内存就没了，当然也可以考虑只索引一部分有用的帖子。

节点可能应用的场景不太一样，节点不需要分词，不需要将一句话分成很多段来索引，也可能不需要ranking，只用一个redis里边的hash估计就行了。 ;-)