1
SakagamiJun 2011-06-12 22:47:26 +08:00
和我想法有相似的地方w
|
2
tioover 2011-06-12 22:52:06 +08:00
我正在做类似的东西w
|
3
SakagamiJun 2011-06-12 22:56:21 +08:00
@tioover 快住手!不准比我先做出来(揍
|
4
tioover 2011-06-12 23:00:24 +08:00
|
5
lychee OP |
6
chloerei 2011-06-12 23:09:34 +08:00
XD 做出来给你看……
群组可不要,关注必须有,这是现阶段的心得。有了关注,就有了feed。各方面可以参考下github的watch |
7
tioover 2011-06-12 23:17:18 +08:00
@lychee 或许可以把人视为特殊节点把wiki视为特殊条目这样
条目: 类型 内容&标题&附件等数据 作者 评论 相关条目 所属节点(可以多个) 节点 类型 名称&扩展数据(比如说自我介绍,节点简介) |
8
tioover 2011-06-12 23:20:16 +08:00
= =原来不能空格啊
|
9
chloerei 2011-06-12 23:23:59 +08:00
用mongodb解决文档的多变模式
用redis维护feed类队列 稍微放松数据的一致性,解放思维 |
10
chloerei 2011-06-12 23:26:49 +08:00
我好像过早进入技术细节了。
一切皆有可能 |
11
lychee OP |
12
Rice 2011-06-12 23:41:21 +08:00
糟糕,你的想法已经和我的有很多类同点了,比如说那个WIKI。干脆我们一直做好了。
|
13
chloerei 2011-06-12 23:49:39 +08:00
@lychee 现在SNS应用的解决方案就是:内存。
比如一条status,引用了topic,reply,user,replier……而且这些数据是不定的,那么关系型数据库是查询不了的。 用关系型和非关系型的解决方案都是把行数据放到内存里。status单独取出来,status.topic, status.reply, status.user, status.replier都是从内存里取。 其实“队列”另一个角度看就是“索引” |
14
caomu 2011-06-12 23:50:09 +08:00
这东西,很感兴趣,有过类似幻想,不过完全技术白,所以期待以上各位联合起来尽快实现,很想看到那样自由的社区呢!
|
15
lychee OP @Rice 一点也不奇怪 这些都不是什么颠覆性的概念 早就有网站应用了 v2ex啊 豆瓣啊 quora啊 stackoverflow啊 twitter啊 什么的好多网站 都是从他们身上撷取的智慧
只不过我们在想着给他们重新整合罢了 |
16
chloerei 2011-06-12 23:57:41 +08:00
补充,上面提的status也是从内存取的,只有内存里没有才从数据库取,然后存到内存缓存
然后系统的后端实际是各类id的队列和以id为key的对象缓存,加上3%的数据库读操作。 |
17
fengluo 2011-06-13 00:03:36 +08:00
我已经在做社区,jinja2+tornado+mongodb 节点、topic、user这三个主要元素跟lz想法相近。有考虑过知识沉淀的这部分,wiki这个还真没想过⋯⋯我比较注重社区topic的过滤,算法排序,推荐。
每个人心中都有个社区,可是真正做起来的话,还是千差万别的。大概是因为不熟悉mongodb这样的nosql数据库⋯⋯过程中我已经改了几次数据库设计了⋯⋯ |
18
lychee OP @chloerei = = 对内存数据库 队列什么的了解不深 的确如果大部分都缓存到内存 效率就会很高了 但是 我在想 这样一个东西 大概像是bbs 2.0 适合小而精的圈子 而不是大而全 像你所说的那样的话 搭建这样一个站点是不是成本太高了点...
|
19
lychee OP @fengluo 大家的想法都不约而同的相似呢 期待大家的作品
的确 主贴中忘记说的一点就是 根据一个人在社区内的活动记录 分析 挖掘出这个人的兴趣 并且据此帮助其发现可能喜欢的节点 人 (=3= 当然也可以精准推送广告) |
20
fengluo 2011-06-13 00:25:30 +08:00
@lychee 我设计社区的时候想的是~我们还需要另一个社区么?国外的facebook、twitter,国内的豆瓣、人人、新浪微博⋯⋯社区很多,却又似乎不是我们想要的那种社区。所以我的社区设计思路是基于twitter的元素重构社区。
直白的说,我设计的社区的topic就是twitter中tweet。用户通过twitter验证注册社区,所有发帖、推荐、收藏这些社区元素跟twitter对应。利用tweet中的hashtag来做节点分类。同时每个用户也可以用hashtag来订阅、过滤话题。在主时间线我利用算法将信息噪音迅速沉下去,根据用户行为将有价值的帖子尽量留住。 |
21
chloerei 2011-06-13 00:28:34 +08:00
@lychee 单单用数据库也能做,很多时候会用表单模拟另外一个东西。类似where().desc()的查询就是每次重复生成一个队列。
最近在做一个订阅列表,一开始想省事用mongodb储存,后来发现mongodb对列表的支持只能从列表尾部插入,而且不能限制列表长度,如果在应用层中实现想要的效果(比如一个timeline)会费很大劲,于是就加上redis了。 当然做着做着,发现部署的门槛是高了。不过我想就算stackoverflow开源,也不如让人们直接泡在他的网站上好。 |
22
fengluo 2011-06-13 00:35:29 +08:00
@chloerei 在学习mongodb的时候发现,很多人也只是把它作为一个补充而已。mongodb和redis混搭这种场景,也被经常提起过。可能得社区真正跑起来的时候,才知道问题所在。
facebook也开源的,却不会有第二个facebook出现啊⋯⋯估计我的代码不好意思开源,见不了人的。我想法是快速开发上线,然后再慢慢修改了~ |
23
reus 2011-06-13 00:51:03 +08:00
关系比较多的话可以考虑用graph database
如此一来,用户,节点,主题,wiki,其实都可以简化成图中的一个结点,差别只在结点的属性。 结点间的关系,比如某主题的作者,所属节点,相关主题,某用户的wiki,它的所有评论,都可以用边来表达。用图来表达这个模型是最好的了 http://en.wikipedia.org/wiki/Graph_database |
25
chloerei 2011-06-13 09:04:41 +08:00
@fengluo 关系数据库把太多责任赋予了数据库,熟悉关系数据库的人经常会用SQL的思维写出很苦涩的逻辑。该让数据库还原它“储存”的基本职责了。
|
26
reus 2011-06-13 09:06:44 +08:00
发觉很多都是用java写的,难不成都是受neo4j影响吗……
https://github.com/stevedekorte/vertexdb 比较了一圈只发现它比较合个人口味,不过似乎已经很久没commit了…… |
27
lychee OP |
28
caomu 2012-03-02 20:36:16 +08:00
看到 云风的《主题论坛的一些想法》 http://www.v2ex.com/t/28407 http://blog.codingnow.com/2012/02/forum.html 想起这个讨论,不知道楼上各位怎么样了。
确实,像 reddit 和 StackOverflow 那样的社区,条理更加清晰,信息流动更加方便,同时数据挖掘的潜力也非常高。但是,究竟一般的上网用户会喜欢/习惯这种设计吗?在中国,大多数人去weibo去qzone去人人去贴吧,在美国大多数人去FB去各种论坛去irc去4chan(不过后两者相对也比较“高级”),而 reddit 和 StackOverflow ,更像是 geeks 的聚集地,依照geek的喜欢建造,也基本只有geek喜欢,那些去贴吧灌水,去李毅吧看/发一些肾上腺激素的帖子的大多数网民,会进驻吗?当然,像V2EX一样,可能忠实用户会认为,正应该小众,只吸引geek刚刚好。小众和一定技术水平的要求,是优点也是缺点。当然,我是非常非常希望出现这样子的社区的,因为有价值的信息的顺畅流通,是一件令人非常愉悦的事情。 |
29
jmy 2012-03-03 16:48:40 +08:00
这样的社会 有没有考虑易用性呢? 让用户的使用门槛降低的
|