数据库 关于类似网易评论盖楼的数据库设计

tony · 2012年04月11日 · 最后由 riioch 回复于 2014年12月16日 · 16792 次阅读

关于类似网易评论盖楼的数据库设计 或者reddit那种方式,对评论进行评论 表应该怎么设计?

我的想法是一次性把某主题下所有的评论全部读取处理,做完处理再显示 但要是评论很多,一次性全部取出来耗资源,大家有没有更优化的设计想法?

共收到 13 条回复

其中一个方案是 google "MPTT"

Trees in MongoDB http://www.mongodb.org/display/DOCS/Trees+in+MongoDB

不单是说 mongodb,还说了其他设计思路

有好几种设计模型,各有优点,需要兼顾增删改查不同操作的效率。提供几个关键词供搜索 tree threaded hierarchical 。

另:

  1. reddit 貌似是开源的(记得至少以前的webpy版是开源的),可以看看代码,不过是python的。
  2. 推荐一种方案,基于PATH的。使用一个叫 ancestry 的gem https://github.com/stefankroes/ancestry 。视频 http://railscasts.com/episodes/262-trees-with-ancestry 。如果深度不那么深,推荐一下。每次增删改,只影响一条记录。 Postgres 有 ltree 模块,与这个设计思路应该是一样的。
  3. MongoDB可以直接保存嵌套数据。但不能查找某一个评论。

楼主研究透了,可以分享一下哈~

stackoverflow 上的一个总结(好棒的社区哇) ,不知道复制过来是否合适⋯⋯

What are the Options for Storing Hierarchical Data in a Relational Database?

#2楼 @caryl nested set 不适合comments这种场景,插入代价太高了,每次插入要更新整个表。这种插入多的树结构建议用 ancestry ,不同于 nested set,ancestry把 ancestors 以 path 的形式保存,比如 comment 3 回复的 comment 2, comment 2 又回复的 comment 1, comment 3的ancestry就是 1/2。ancestry的大部分查询都只用一次SQL,虽然desendents要用到 LIKE,但是不是以通配符开头,所以可以利用到 index。唯一限制的是 ancestry 最长是255个字符

想到的方法是,回复model有个parent_id,父节点如果分页量大可能还要查一次内容,相同数据前端再套一次

谢谢楼上各位的回答,长见识了

可以给每个回复搞个 children_id 。

其实,就一个 parent_id 就好了,查询的时候用 WITH RECURSIVE ,传说还是这样效果最好

#10楼 @bhuztez 这样用的是embed方式吧, 会导致单个文档体积膨胀,慎用

有一个mongoid-tree, 实现方式楼主可以参考一下 它是用两组外键 一个parent_id 外加一个parent_ids,后者用来查询间接先祖和子孙节点 , 配合上identity map,使用起来效果还行

楼主现在能否回来分享一下你的方案呢?

需要 登录 后方可回复, 如果你还没有账号请点击这里 注册