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

V2EX = way to explore

V2EX 是一个关于分享和探索的地方

For Existing Member Sign In

爱意满满的作品展示区。

This topic created in 4969 days ago, the information mentioned may be changed or developed.

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

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

demo地址：

http://ohbooklist.com/redis/

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

Supplement 1 · Dec 28, 2012

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

Supplement 2 · Sep 16, 2013

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

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

Demo

补全

GitHub

26 replies • 1970-01-01 08:00:00 +08:00

tshwangq

Sep 28, 2012

很快

okidogi

Sep 28, 2012

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

CoX

Sep 28, 2012

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

tshwangq

Sep 29, 2012

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

干吗还要搞个301 ...

zl8723

Sep 29, 2012

nice job

virgil

Sep 29, 2012

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

feilaoda

Sep 29, 2012

500!

chairo

Sep 29, 2012

没任何补全……

flylee2011

Sep 29, 2012

500.。。

alai

Sep 29, 2012

不错，试试。

okidogi

Sep 29, 2012

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

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

wezzard

Oct 1, 2012

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

udonmai

Oct 1, 2012

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

harmy

Oct 1, 2012

赞开源的精神！

okidogi

Oct 1, 2012

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

udonmai

Oct 1, 2012

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

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

bruce

Oct 1, 2012

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

okidogi

Oct 1, 2012

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

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

bruce

Oct 10, 2012

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

leecade

Dec 28, 2012

需要前端配合吗

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

https://github.com/leecade/suggest

9hills

Sep 16, 2013

建议添加拼音匹配

okidogi

Sep 16, 2013

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

Livid

MOD

PRO

Sep 17, 2013

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

okidogi

Sep 17, 2013

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

Livid

MOD

PRO

Sep 17, 2013

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

谢谢。

okidogi

Sep 17, 2013

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

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