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

V2EX = way to explore

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

现在注册

已注册用户请登录

爱意满满的作品展示区。

这是一个创建于 4432 天前的主题，其中的信息可能已经有所发展或是发生改变。

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

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

demo地址：

http://ohbooklist.com/redis/

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

第 1 条附言 · 2012-12-28 21:17:39 +08:00

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

第 2 条附言 · 2013-09-16 19:37:52 +08:00

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

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

Demo

补全

GitHub

26 条回复 • 1970-01-01 08:00:00 +08:00

tshwangq

2012-09-28 21:57:26 +08:00

很快

okidogi

2012-09-28 22:34:04 +08:00

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

CoX

2012-09-28 23:23:58 +08:00

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

tshwangq

2012-09-29 00:11:01 +08:00

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

干吗还要搞个301 ...

zl8723

2012-09-29 01:19:58 +08:00

nice job

virgil

2012-09-29 08:12:53 +08:00

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

feilaoda

2012-09-29 09:42:32 +08:00

500!

chairo

2012-09-29 09:57:14 +08:00

没任何补全……

flylee2011

2012-09-29 10:00:58 +08:00

500.。。

alai

2012-09-29 10:42:04 +08:00

不错，试试。

okidogi

2012-09-29 16:46:40 +08:00

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

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

wezzard

2012-10-01 14:28:32 +08:00

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

udonmai

2012-10-01 14:57:26 +08:00

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

harmy

2012-10-01 15:09:28 +08:00

赞开源的精神！

okidogi

2012-10-01 18:56:33 +08:00

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

udonmai

2012-10-01 20:37:49 +08:00

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

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

bruce

2012-10-01 21:22:34 +08:00

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

okidogi

2012-10-01 23:44:15 +08:00

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

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

bruce

2012-10-10 17:38:21 +08:00

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

leecade

2012-12-28 23:43:01 +08:00

需要前端配合吗

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

https://github.com/leecade/suggest

9hills

2013-09-16 19:49:09 +08:00

建议添加拼音匹配

okidogi

2013-09-16 19:53:50 +08:00

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

Livid

MOD

2013-09-17 13:20:03 +08:00

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

okidogi

2013-09-17 16:54:33 +08:00

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

Livid

MOD

2013-09-17 16:55:40 +08:00

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

谢谢。

okidogi

2013-09-17 17:03:54 +08:00

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

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