V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
lychee
V2EX  ›  随想

关于主题社区的一点点设想

  •  
  •   lychee · 2011-06-12 22:22:08 +08:00 · 5601 次点击
    这是一个创建于 4912 天前的主题,其中的信息可能已经有所发展或是发生改变。
    从早期的bbs(比较有代表性的就是discuz论坛系统,千千万万的网站通过它搭建了自己的论坛),

    到现在的豆瓣、微博、各种问答社区、图片社区、基于地理位置的社区。

    各种各样的社区,各种各样的形式,其都是为了分享内容而存在。

    “有人的地方就有江湖”

    这句话在互联网时代或许就该改成

    “有人的地方就有社区”

    所以说,社区是永恒不变的主题,也是互联网的精神所在。

    因为社区如此重要,所以如何构建一个优秀的社区系统,该构建一个什么样的社区就是我现在在想的东西。

    目前脑袋中的雏形是这样的:

    社区中的几个基本元素

    人 ———— 当然就是注册会员

    节点 ———— 这个我也不知道应该准确的叫什么,节点是一个词,而这个词代表了某件事物。

    主题 ———— 这个好懂,就像一篇帖子,任何人都可以发布。但是我希望它可以承载多种类型的内容,不仅仅是有标题有正文的文章,可以是没有标题,只有一段话的一条推、甚至可以是没有标题、没有正文、而只有图片、音频或者视频的多媒体内容。或者你全部可以填上。希望可以自由的组合内容,而并没有哪一部分是必须的。

    wiki ———— 无须讨论的、知识性的东西,当然也是由所有人撰写。


    各个元素之间的关系

    人和节点下面可以都有无限多的主题和wiki。

    主题和wiki可以从属于多个节点。

    主题的作者只有一个,wiki只保存历史编撰者。



    人下面有一个默认wiki 这就是个人资料。

    当然,人的wiki只能自己来编写,所以也可以拿来当blog写。

    而人下面的主题则像是个留言板。




    节点下面也有一个默认wiki,这就是关于此节点所代表事物的介绍。

    例如有个 “咖啡” 节点

    那么默认wiki就是 “什么是咖啡”
    还可以有 “咖啡有哪几种口味” 之类的wiki,等等等等,需要注意的是,传统论坛某些帖子加精的概念,在这里则是 将它整理至wiki。

    节点下面的主题当然就是所有有关此节点的讨论。



    各元素之间可以发生任意关联
    例如
    某人 喝过了 咖啡(节点) 或者 想品尝 咖啡(节点) {-3- 像豆瓣吧}

    某人 关注 某主题

    某主题 引用了 咖啡有哪几种口味(wiki)




    除了以上这些 我还想引入一个时间的维度

    主题最后回复的时间如果超过了一个设定的值 例如一个月或三个月 会自动关闭

    可以查看上周、上上周、上上上周、上个月... 最热门的前一百个主题是什么




    其他的就是根据元素之间的关系进行聚合和过滤
    最平常的 显示某节点下的主题
    显示某人发表的主题
    只显示某人关注节点的主题
    某主题有新回复会通知所有关注者
    等等等等....



    大概就是这么多了 自己认为这四种基本元素可以自给自足形成一个内容社区 不需要引入其他的东西 (群组什么的,觉得水分太大,容易滋生无意义的主题,节点完全够用)


    各位觉得这有可能性么

    这有程序上实现的可能性么 (如此灵活的系统 架构设计起来很伤脑筋)
    29 条回复    1970-01-01 08:00:00 +08:00
    SakagamiJun
        1
    SakagamiJun  
       2011-06-12 22:47:26 +08:00
    和我想法有相似的地方w
    tioover
        2
    tioover  
       2011-06-12 22:52:06 +08:00
    我正在做类似的东西w
    SakagamiJun
        3
    SakagamiJun  
       2011-06-12 22:56:21 +08:00
    @tioover 快住手!不准比我先做出来(揍
    tioover
        4
    tioover  
       2011-06-12 23:00:24 +08:00
    @SakagamiJun 已经有个很不堪的半成品了啦,打算暑假重写
    http://stack.googlecode.com
    和楼主思路不太一样就是了
    lychee
        5
    lychee  
    OP
       2011-06-12 23:02:50 +08:00
    @tioover @SakagamiJun

    - - 这个东西 想要完全理清思路 并且转换到程序架构上很伤脑筋

    我编码了一半 突然脑袋不清楚了。。

    ORZ 所以写出来 各位讨论下吧
    chloerei
        6
    chloerei  
       2011-06-12 23:09:34 +08:00
    XD 做出来给你看……

    群组可不要,关注必须有,这是现阶段的心得。有了关注,就有了feed。各方面可以参考下github的watch
    tioover
        7
    tioover  
       2011-06-12 23:17:18 +08:00
    @lychee 或许可以把人视为特殊节点把wiki视为特殊条目这样
    条目:
    类型
    内容&标题&附件等数据
    作者
    评论
    相关条目
    所属节点(可以多个)
    节点
    类型
    名称&扩展数据(比如说自我介绍,节点简介)
    tioover
        8
    tioover  
       2011-06-12 23:20:16 +08:00
    = =原来不能空格啊
    chloerei
        9
    chloerei  
       2011-06-12 23:23:59 +08:00
    用mongodb解决文档的多变模式
    用redis维护feed类队列
    稍微放松数据的一致性,解放思维
    chloerei
        10
    chloerei  
       2011-06-12 23:26:49 +08:00
    我好像过早进入技术细节了。

    一切皆有可能
    lychee
        11
    lychee  
    OP
       2011-06-12 23:39:46 +08:00
    @tioover 不是不能空格 v2ex不转义空格 所以html里空格再多也显示一个

    @chloerei 没关系啊 - - 不就是在讨论程序上的可行性么

    mongodb里面引用 用的太多性能会急剧下降么 毕竟这个雏形里面关系很多 这是关系型数据库的强项

    队列就随意了 主要还是主数据库的设计问题

    我在想 是否可以让原始数据尽量保持简单 而把索引性质的东西单独存放 就是让程序分析原始数据生成二次索引
    Rice
        12
    Rice  
       2011-06-12 23:41:21 +08:00
    糟糕,你的想法已经和我的有很多类同点了,比如说那个WIKI。干脆我们一直做好了。
    chloerei
        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都是从内存里取。

    其实“队列”另一个角度看就是“索引”
    caomu
        14
    caomu  
       2011-06-12 23:50:09 +08:00
    这东西,很感兴趣,有过类似幻想,不过完全技术白,所以期待以上各位联合起来尽快实现,很想看到那样自由的社区呢!
    lychee
        15
    lychee  
    OP
       2011-06-12 23:52:15 +08:00
    @Rice 一点也不奇怪 这些都不是什么颠覆性的概念 早就有网站应用了 v2ex啊 豆瓣啊 quora啊 stackoverflow啊 twitter啊 什么的好多网站 都是从他们身上撷取的智慧

    只不过我们在想着给他们重新整合罢了
    chloerei
        16
    chloerei  
       2011-06-12 23:57:41 +08:00
    补充,上面提的status也是从内存取的,只有内存里没有才从数据库取,然后存到内存缓存

    然后系统的后端实际是各类id的队列和以id为key的对象缓存,加上3%的数据库读操作。
    fengluo
        17
    fengluo  
       2011-06-13 00:03:36 +08:00
    我已经在做社区,jinja2+tornado+mongodb 节点、topic、user这三个主要元素跟lz想法相近。有考虑过知识沉淀的这部分,wiki这个还真没想过⋯⋯我比较注重社区topic的过滤,算法排序,推荐。
    每个人心中都有个社区,可是真正做起来的话,还是千差万别的。大概是因为不熟悉mongodb这样的nosql数据库⋯⋯过程中我已经改了几次数据库设计了⋯⋯
    lychee
        18
    lychee  
    OP
       2011-06-13 00:08:38 +08:00
    @chloerei = = 对内存数据库 队列什么的了解不深 的确如果大部分都缓存到内存 效率就会很高了 但是 我在想 这样一个东西 大概像是bbs 2.0 适合小而精的圈子 而不是大而全 像你所说的那样的话 搭建这样一个站点是不是成本太高了点...
    lychee
        19
    lychee  
    OP
       2011-06-13 00:16:07 +08:00
    @fengluo 大家的想法都不约而同的相似呢 期待大家的作品

    的确 主贴中忘记说的一点就是 根据一个人在社区内的活动记录 分析 挖掘出这个人的兴趣 并且据此帮助其发现可能喜欢的节点 人 (=3= 当然也可以精准推送广告)
    fengluo
        20
    fengluo  
       2011-06-13 00:25:30 +08:00
    @lychee 我设计社区的时候想的是~我们还需要另一个社区么?国外的facebook、twitter,国内的豆瓣、人人、新浪微博⋯⋯社区很多,却又似乎不是我们想要的那种社区。所以我的社区设计思路是基于twitter的元素重构社区。
    直白的说,我设计的社区的topic就是twitter中tweet。用户通过twitter验证注册社区,所有发帖、推荐、收藏这些社区元素跟twitter对应。利用tweet中的hashtag来做节点分类。同时每个用户也可以用hashtag来订阅、过滤话题。在主时间线我利用算法将信息噪音迅速沉下去,根据用户行为将有价值的帖子尽量留住。
    chloerei
        21
    chloerei  
       2011-06-13 00:28:34 +08:00
    @lychee 单单用数据库也能做,很多时候会用表单模拟另外一个东西。类似where().desc()的查询就是每次重复生成一个队列。

    最近在做一个订阅列表,一开始想省事用mongodb储存,后来发现mongodb对列表的支持只能从列表尾部插入,而且不能限制列表长度,如果在应用层中实现想要的效果(比如一个timeline)会费很大劲,于是就加上redis了。

    当然做着做着,发现部署的门槛是高了。不过我想就算stackoverflow开源,也不如让人们直接泡在他的网站上好。
    fengluo
        22
    fengluo  
       2011-06-13 00:35:29 +08:00
    @chloerei 在学习mongodb的时候发现,很多人也只是把它作为一个补充而已。mongodb和redis混搭这种场景,也被经常提起过。可能得社区真正跑起来的时候,才知道问题所在。

    facebook也开源的,却不会有第二个facebook出现啊⋯⋯估计我的代码不好意思开源,见不了人的。我想法是快速开发上线,然后再慢慢修改了~
    reus
        23
    reus  
       2011-06-13 00:51:03 +08:00
    关系比较多的话可以考虑用graph database
    如此一来,用户,节点,主题,wiki,其实都可以简化成图中的一个结点,差别只在结点的属性。
    结点间的关系,比如某主题的作者,所属节点,相关主题,某用户的wiki,它的所有评论,都可以用边来表达。用图来表达这个模型是最好的了
    http://en.wikipedia.org/wiki/Graph_database
    chloerei
        24
    chloerei  
       2011-06-13 09:03:24 +08:00
    @reus 哟,这个屌
    chloerei
        25
    chloerei  
       2011-06-13 09:04:41 +08:00
    @fengluo 关系数据库把太多责任赋予了数据库,熟悉关系数据库的人经常会用SQL的思维写出很苦涩的逻辑。该让数据库还原它“储存”的基本职责了。
    reus
        26
    reus  
       2011-06-13 09:06:44 +08:00
    发觉很多都是用java写的,难不成都是受neo4j影响吗……
    https://github.com/stevedekorte/vertexdb
    比较了一圈只发现它比较合个人口味,不过似乎已经很久没commit了……
    lychee
        27
    lychee  
    OP
       2011-06-13 14:41:35 +08:00
    @reus 貌似你这样抽象过头了 其实我觉得四种元素不多不少刚好 还有 评论是否可以也看作是一个主题?

    @chloerei 同意 数据库应该还原存储的本质

    我想 现在的数据库设计中 关系和数据混在一起 那么是否可以将关系剥离成独立的一层?

    这样的话查询数据库的流程就是这样的

    从某一点构建关系树

    用实际数据填充 当然 根据其在树中的位置和角色 填充前会做一些处理

    完成
    caomu
        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刚刚好。小众和一定技术水平的要求,是优点也是缺点。当然,我是非常非常希望出现这样子的社区的,因为有价值的信息的顺畅流通,是一件令人非常愉悦的事情。
    jmy
        29
    jmy  
       2012-03-03 16:48:40 +08:00
    这样的社会 有没有考虑易用性呢? 让用户的使用门槛降低的
    关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   实用小工具   ·   1496 人在线   最高记录 6679   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 31ms · UTC 17:13 · PVG 01:13 · LAX 09:13 · JFK 12:13
    Developed with CodeLauncher
    ♥ Do have faith in what you're doing.