1
domainname 2011-03-07 22:27:38 +08:00
同意。寻找node也很困难,我有一个社区也有这个问题。但怎么解决这个问题呢?能提供几个方案么?
第一个方案是你说的 tag |
2
Kenyth OP 已经说的很明白了:
1) 你社区的定位,如果是目的非常明确 (如 Google Groups 里面各种 group),则存在这个问题的概率非常小 2) 如果你的板块很有限,则用户可以看到所有,非常有掌控感,也不会存在这个问题 3) 如果1、2 都没有或者在 2 的基础上在醒目位置设置一个 “General” 或者 “杂谈” 板块收集这种帖子,以后管事的可以自己调整到其他板块 4) stackoverflow 的方案,但我不认为这个是完全开放式的 tag 的意思,它有很好的控制机制,垃圾 tag 比较少,你可以自己去上面发个帖子试试看。 |
3
Livid MOD 一个主题对应多个 Node,通过各种 Node 找到同一个主题。
目前 Quora 有这样的架构。 而 V2EX 2 在开始做的时候确实没有在这方面考虑太多。数据结构和发贴之后的归类有一定挑战,GAE 的查询性能可能会让这样的页面生成时间超过 500ms(在大数据量的时候)。当然,可以通过 taskqueue 来做异步处理。但是如果在短时间内对一个主题进行大量的修改,taskqueue 也会有问题,因为如果 taskqueue 很拥挤的话,执行顺序会无法预料。 现在看来: • 节点地图确实应该有 • 节点搜索应该更强大 等 Google SQL Service 出来之后,根据情况我会对多节点问题尝试解决。 |
5
Kenyth OP @Livid GAE 我也有一段时间没碰了,但据我所知,如果把所属的 node id (如 apple)以 List 的形式(100 以内的 size 应该没有明显性能问题,以前 limit 是 1000 还是多少?)存在主题的数据库表里面,则不存在归类的问题。
而且如果把主题按一定规则分布在多个 transaction group (名字不确定是否正确)里面,查询的时候 datastore 也会并行处理,这样显示 node 应该不会有太大压力吧(是你说的 500ms 么?) 至于“在短时间内对一个主题进行大量的修改”,按你的逻辑,应该是连接关系存储在 node 的数据库表里面吧,否则应该不会有什么影响,最多更改所属 node 列表,会需要更新 cache 而已。 以上是我的理解而已,不太确定是否有错误。 |
6
Kenyth OP @linsk 其实据我所知,这种 suggest 功能在 GAE 消耗 quota 的速度最快了。不知道最新的 PUSH API 对这个会不会有帮助,还没研究过。
|
7
linsk 2011-03-07 23:07:57 +08:00
|
9
est 2011-03-07 23:23:35 +08:00
这个机制就是anonymous
|
10
darasion 2011-03-07 23:42:33 +08:00
我觉得干脆把节点当做 博客里边的 “标签” 其实就不错。
|
11
chloerei 2011-03-08 01:32:09 +08:00
|
12
benzhe 2011-03-08 01:51:57 +08:00
支持 @linsk 的方法,不过用到cookie貌似多余了。最近弄了一个聚合站,分类问题通过简单语义分析解决了,虽然部分不是很准确
|
13
Aether 2011-03-10 16:36:35 +08:00
猫扑使用大杂烩来解决这样的问题么?
|